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

[Grant Taylor]

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,

Fair.

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

Fair.

> 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...
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/c1e566d4/attachment.bin>