[dns-operations] need ideas for selective proxying to defeat the economic poison pill built into DOH

Grant Taylor gtaylor at tnetconsulting.net
Thu May 16 16:35:12 UTC 2019

On 5/15/19 11:46 PM, Paul Vixie wrote:
> this is the most interesting idea i've heard, and i'm thinking hard about it.


> the second most interesting idea i've heard is dnsfire:
> 	https://github.com/wupeka/dnsfire

dnsfire seems to be a more complete implementation of what I was trying 
to describe.

I do have some questions / thoughts about how dnsfire is working (based 
on my quick read of the page you linked to).

  - Why patch BIND?
     - I would try to sniff the DNS reply going back to clients from BIND.
     - There are likely other options to get the information, NFQUEUE, etc.
  - Why is the timeout set to 0 for the ipset?
     - I would set it to something small 30 / 60 / 90 seconds, and allow 
SPI to handle the bulk of the traffic.
  - Change the iptables rule to actually REJECT traffic (with ICMP 
administratively denied) that is not explicitly allowed via the ipset(s).
  - Why call an external command to manage the ipset(s)
  - Contemplate using recent list(s) instead of ipset(s).
     - dnsfire could append lines to a /proc interface directly:
        - echo "+addr" > /proc/net/xt_recent/recent_list_name

> the holy grail is, listeners who don't support DOH (the /dns-query URI) 
> should be rewarded by not having their traffic decrypted at my network 
> edge, and i never have to force a TLS downgrade on my clients. this 
> requires some kind of selective proxying. i don't think that's 
> simple. does anyone?


Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190516/8693ec90/attachment.bin>

More information about the dns-operations mailing list