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

Florian Weimer fweimer at bfk.de
Thu Dec 10 15:27:48 UTC 2009


* Anand Buddhdev:

> 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).

>> 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).

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



More information about the dns-operations mailing list