[dns-operations] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC

[Mark Andrews]

In message <4B69AB06.8050305 at hp.com>, Rick Jones writes:
> Joe Abley wrote:
> > On 2010-02-03, at 06:45, Paul Vixie wrote:
> > 
> > 
> >>http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf
> > 
> > 
> > Geoff Huston's recent Bad Idea regarding stateless TCP support for DNS may also be worth reading about, if you haven't already. (I'
> m not suggesting this is equivalent in any sense to the pointed Paul provided above, but it is somewhat relevant to the general topic
>  of how to deal with upswings in TCP transport for DNS).
> > 
> >   http://www.potaroo.net/ispcol/2009-11/stateless.html
> 
> > There is a related issue here, when looking at the use of IPv6 as the
> > transport protocol for the UDP DNS query with ENDS0.
> 
> That should be "network protocol" - UDP and TCP are transports :)
> 
> 
> > Because IPv6 UDP does not support fragmentation in flight, if the 
> > path MTU between the server and the DNS client is less than the IPv6 
> > interface MTU at the server, then the server will emit a large UDP 
> > packet matching the local interface MTU. This will cause the packet
> > to be dropped at the path MTU bottleneck, and an ICMPv6 "packet too
> > big" response sent back to the server. The server has no remembered
> > state of the original query, and cannot reformat its response. The
> > client will not receive any response to its original query, and will
> > time out. In such a case, the client turning to any other server may
> > not help either. If all servers are delivering the same large
> > response via UDP and there is a path MTU blackhole close to the
> > client, then the client may well have a problem!

This issue was identified over a decade ago [1] and there is a standards
based solution.  See RFC 3542 and IPV6_USE_MIN_MTU, which was
published May 2003.

If your OS vendor does not implement this option or your nameserver
vendor does not set this option replace the relevent part of your
DNS solution.
 
[1] https://datatracker.ietf.org/drafts/draft-ietf-ipngwg-bsd-frag/

> If there is such a "dumbell" (Wide at the ends, narrow in the middle) 
> between the client and the server, that will affect the query carried 
> over TCP as well.  Ditto with IPv4.

> 
> rick jones
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org