[dns-operations] summary of recent vulnerabilities in DNS security.

[Colm MacCárthaigh]

For DNS, we have the option to respond with a TC=1 response, so if I
detected a datagram with suspicious or mismatching TTLs, TC=1 is a decent
workaround. TCP is then much more robust against intermediary spoofing. I
can't force the clients to use DF though.


On Wed, Jan 15, 2014 at 2:08 PM, Hannes Frederic Sowa <
hannes at stressinduktion.org> wrote:

> Hi!
>
> On Wed, Jan 15, 2014 at 01:26:20PM -0800, Colm MacCárthaigh wrote:
> > Unfortunately I can't share data, but I have looked at a lot of it. In
> > general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these
> > days and so as long as the path is stable, the TTLs should be identical.
> If
> > there's some kind of transition mid-datagram, the the TTLs may
> legitimately
> > mismatch, but those events seem to be very rare.
>
> Counterexample: Linux does not use flow-hased steered ECMP. You see the
> effect on end-hosts because of the route lookup caching in the socket
> (as long as it doesn't get invalidated or unconnected).
>
> The problem is that as soon as such a knob is provided people could
> generate DNS-blackholes (until timeout of resolver and retry with TCP,
> maybe this could be sped up with icmp error messages).  Only a couple
> of such non-flow-hased-based routed links would suffice to break the
> internet for a lot of users. I am pretty sure people will enable this
> knob as soon as it is provided and word is spread.
>
> If we want to accept that we could just force DF-bit on all fragments
> and ignore the users behind some specific minimal mtu. Would solve the
> problem more elegantly with same consequences. And error handling with
> DF-bit
> is better specified and handled by the kernel, thus more robust and better
> debugable (in case UDP path mtu discovery is implemented on the OS). ;)
>
> > netfilter would be fine, but it'd be nice to not incur any state cost
> > beyond what the UDP re-assembly engine is keeping already.
>
> netfilter reuses the core reassembly logic (at least in IPv4, not yet
> for IPv6). As soon as netfilter is active, packets will get reassembled
> by netfilter and passed up the network stack without going in "core"
> fragmentation cache again. So the TTLs would be kept in the frag queues
> and further fragments would indicate to hard match the TTL on further
> appends.  So that would be no problem to do. I really doubt it is wise
> to do so.
>
> Greetings,
>
>   Hannes
>
>


-- 
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140115/f12e0ce9/attachment.html>