[dns-operations] need ideas for selective proxying to defeat the economic poison pill built into DOH
gtaylor at tnetconsulting.net
Fri May 17 02:55:20 UTC 2019
I've got to say, that Witold's responses seem perfectly reasonable for a
project of this type still in development.
On 5/16/19 12:37 PM, Witold Krecicki wrote:
> Latency - if we add the rule to iptables too late the user experience
> is much worse (been there, done that),
Would you please elaborate on "too late". Do you mean too many other
rules that get processed before the rule for dnsfire?
> that's also why it's not using DNSTAP.
Have you tested DNSTAP and found it to have higher latency than what
you're currently doing? If so, please provide some rough back of the
envelope numbers. (I'm curious, not doubting you.)
> It's set to TTL of the record +epsilon (or at least it should be).
Hum. I don't think I like the idea of the TTL of the temporary white
list being set to the TTL of the DNS RR. This could be hours / days /
weeks / months. I'd think that such a DNS firewall would only want to
allow something for seconds / minutes at most. Especially when IPTables
SPI can allow ongoing / established traffic. (Remember that you just
need to allow things long enough for a connection to become ESTABLISHED
or whatever your SPI is filtering on.)
> It's just an example,
> the code does not touch iptables in any way (just ipset), it's at
> operators discretion.
Good. I like that. At least I don't like it when something other than
me touches my IPTables rule sets. I'm cool with a specific chain and /
or ipset and / or recent list.
I suspect that a specific ipset and / or recent list will be faster than
atomic updates to IPTables entire binary blob.
> It's a first PoC, and libipset seemed to be more complicated than
> just calling system()
> Create a Pull Request :)
I'll look into that.
Can I email you directly to ask more specific questions about dnsfire?
Or is there a better location?
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the dns-operations