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 < [email protected]> 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
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
