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

[Witold Krecicki]

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:
>>
>>     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.
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
calling system()

>  - 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 :)

-- 
Witold Kręcicki