[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?
ACK
--
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