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

[Hannes Frederic Sowa]

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