[dns-operations] No public calendar for the root signing deployment

Mark Andrews marka at isc.org
Mon Dec 14 19:41:02 UTC 2009


In message <4B2667B3.4000409 at ripe.net>, Anand Buddhdev writes:
> On 10/12/2009 16:27, Florian Weimer wrote:
> 
> Hi Florian,
> 
> >> However, for regular testing, this isn't a problem. A resolver,
> >> while resolving the name test.rs.ripe.net should not need to query
> >> for the A record of ns00.rs.ripe.net, so it doesn't break the
> >> test.
> > 
> > It breaks the test for Unbound (and perhaps for BIND as well, when a 
> > query for ns00.rs.ripe.net/IN/A is received at the wrong time).
> 
> Thank you for alerting us to this. We have corrected the reply-size
> tester, so that it correctly responds with its A record.
> 
> >>> I'm also curious about the plans for the DF bit in replies. (IMO,
> >>> the only correct thing to do is to switch it off.)
> >> 
> >> I don't quite understand this. Do you mind explaining it in some
> >> more detail?
> > 
> > Here's a DO=1 priming reply from a K root instance:
> > 
> > 16:16:56.181776 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF],
> > proto UDP (17), length 671) 193.0.14.129.53 > 95.128.213.195.43129:
> > 39638*- 13/0/21 [...] (643)
> > 
> > Here's the same thing from an F root instance:
> > 
> > 16:20:12.188677 IP (tos 0x0, ttl 57, id 60984, offset 0, flags
> > [none], proto UDP (17), length 671) 192.5.5.241.53 >
> > 95.128.213.195.48881: 49215*- 13/0/21 [...] (643)
> > 
> > The key difference is "flags [DF]" vs "flags [none]".  If you set
> > DF, you cannot filter all ICMP traffic to the root server, you must 
> > process type 3, code 4 ("fragmentation needed and DF set") ICMP 
> > mesages.  This requires routing them to the correct node, which is 
> > problematic when any form of load balancing (including anycast is 
> > involved).  This type of ICMP processing may also cause other issues 
> > (e.g., serving DNS over UDP is no longer stateless).
> 
> There's a patch for NSD in the trunk, which will set DF=0. Early in
> 2010, we will upgrade NSD on all K-root instances before we publish a
> signed root zone.

Note: The host OS is NOT RFC compliant and should be upgraded.

RFC 1191: 6.1. Layering
   
   *********************************************************************
		 We do not want the IP layer to simply set the DF bit
   in every packet, since it is possible that a packetization layer,
   perhaps a UDP application outside the kernel, is unable to change its
   datagram size.  Protocols involving intentional fragmentation, while
   inelegant, are sometimes successful (NFS being the primary example),
   and we do not want to break such protocols.
   *********************************************************************

> 
> Regards,
> 
> Anand Buddhdev,
> DNS Services Manager, RIPE NCC
> _______________________________________________
> 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



More information about the dns-operations mailing list