[Yeti DNS Discuss] ipv6 root name service discussed (gih blog)

[Paul Vixie]

Otmar Lendl wrote:
> 
> ...
> 
> In the TCP case, the incoming ICMPv6 PTBs can be sanity-checked.
> 
> In the UDP case, it's not that simple. Check if the source port is still
> an assigned port? That's pretty thin, and in the case of a DNS server
> trivially true.

the last rdns server i had a personal hand in was not bind, but rather,
some now-dead proprietary software (called "robodns" for those who may
remember it.) one of its unusual features was to open ICMP and ICMPv6
sockets and parse unreachables. the primary purpose was to speed up
retry or failure given that my UDP sockets weren't "connected" and so
the 4-tuple parsed by the kernel would not identify any path by which i
could get an "errno" of EHOSTUNREACH from any socket-related call. i did
not want to have to wait for a timeout if i knew that the far end had
not in fact heard me.

while this was primarily of use on the upstream path, it would be very
easy to implement fragmentation awareness. i now wish i had done this,
since i could have kept all state in user mode (no kernel routes) and
just used setsockopt() to set my MTU whenever i was again talking to a
host who had sent a V6 PTB or V4 MF in recent memory.

there's no reason other DNS servers (those still existing, for example)
couldn't work that way. my concern is that this isn't just a DNS
problem, it's all wide-area UDP protocols. doing the work in user mode
rather than kernel mode means duplicating this logic in every UDP app
and service. at a minimum, HTTP/2-UDP ("QUIC") needs to know about this
and require it.

> ...
> 
> Who takes this concern to those authors? IMHO they should discuss this
> in rfc1981bis.

hopefully geoff will carry on in that way.

note that akira kato has found some fragmentation-related ICMPv6 TCP
problems, about which he spoke at the yeti workshop in seoul last month.
he has found IPv6 implementations which do not reduce MSS upon hearing
PTB. it's a separate, but possibly confusingly related, matter. any
discussion of the UDP problem should explicitly differentiate it from
kato's TCP observations, to ensure that noone combines these issues upon
hearing both.

-- 
P Vixie