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

[Anand Buddhdev]

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.

Regards,

Anand Buddhdev,
DNS Services Manager, RIPE NCC