[dns-operations] need ideas for selective proxying to defeat the economic poison pill built into DOH
wpk at isc.org
Thu May 16 18:37:03 UTC 2019
W dniu 16.05.2019 o 18:35, Grant Taylor pisze:
> On 5/15/19 11:46 PM, Paul Vixie wrote:
>> the second most interesting idea i've heard is 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.
Latency - if we add the rule to iptables too late the user experience is
much worse (been there, done that), that's also why it's not using DNSTAP.
> - 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.
It's set to TTL of the record +epsilon (or at least it should be).
> - Change the iptables rule to actually REJECT traffic (with ICMP
> administratively denied) that is not explicitly allowed via the ipset(s).
It's just an example, the code does not touch iptables in any way (just
ipset), it's at operators discretion.
> - Why call an external command to manage the ipset(s)
It's a first PoC, and libipset seemed to be more complicated than just
> - 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
Create a Pull Request :)
More information about the dns-operations