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

[Witold Krecicki]

W dniu 17.05.2019 o 04:55, Grant Taylor pisze:
> 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?
Just as Mukund stated - client (usually - browser) will send the SYN
before the hole in the firewall is punched and the connection will be
dropped/rejected. Yes, the browser will retransmit, it will eventually
work, but it will be way slower and the overall UX of this would be bad
and annoying.

>> 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.)
I don't have any numbers, just my own 'user experience' when I tested it
- the pages loaded much slower - and the reason was that virtually all
connections were retried (as seen in firewall logs). Keep in mind that
BIND9 sends DNSTAP packet only after it sends response to client - so
it's almost impossible for the firewall to open before the client tries
to connect.

>> 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.)
Client cache DNS responses (systemd-resolved) - opening firewall only
for a short time will make this caching useless, and, once again, create
a bad UX. There's an option for upper cap on TTL of records in
dnsfire-ipsetd.
My goal was to block non-local resolvers without any impact on the users
of local 'approved' resolver.

>> 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.
That's why it's using ipset and not iptables.

>> 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?
Yes, or you could open up an issue on Github.

-- 
Witold Krecicki