Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
In the fall of 2009, the organizations responsible for generating the root zone, ICANN, Verisign, and the US Department of Commerce, announced that they had come to a agreement on how to sign the root zone with DNSSEC (DNS Security Extensions) A website has been created by ICANN and Verisign to provide information about the change and a rollout timeline.
First, a signed root zone aka “DURZ” (Deliberately Unvalidatable Root Zone) - which cannot be used for validation purposes - will be deployed across all of the root servers in a phased rollout from January-May 2010. If all goes well, the fully validated root zone will be put into production on the 1st of July, 2010.
As one of the twelve Root Server Operators, ISC has created this blog post to answer some common questions regarding a signed root zone and what the community can do to prepare for the change. In addition, ISC will be describing what we are doing to prepare F.ROOT-SERVERS.NET to handle a signed root.
Why do we need to sign the root zone?
DNSSEC has been developed by the Internet Engineering Task Force (IETF) so that a digital signature (RRSIG) can be applied to DNS Resource Record Set (RRSet) so that a client can verify that these records are authentic. Since DNS is a hierarchal naming system, a signed root zone means that a DNSSEC-aware client can look up a domain in say the .ORG namespace (which is one of many TLDs that have already signed their zones with DNSSEC) and can follow a completely signed (and verified) delegation path.
What are some possible side effects of a signed root zone?
The big change is that DNS responses from the root servers for ‘.’ will become larger, as they will contain the answer in the form of a RRset and its signature (RRSIG).
Before DNSSEC, most DNS packets were over UDP and smaller than 512 bytes, which was enshrined in the early DNS-related RFCs. Since most DNS responses with signed RRsets (containing the paired RRSet and RRSIG) will exceed that 512 byte limit, the IETF developed the EDNS0 extension (RFC 2671) to allow a client to request a response larger that 512 bytes (up to 4096 bytes) over UDP via IP fragments. EDNS0 is now widely supported by many device and appliance vendors (as well as DNS server applications like BIND).
However there are many devices & appliances in the wild that are still configured by default to only accept DNS packets smaller than 512 bytes or that don’t allow for IP fragments. In some cases the clients may try a smaller buffer size until they can get the response thru; in other cases, clients would then just fall back to TCP.
Is there any way I can test to see if my nameserver supports EDNS0?
You can check using the Reply Size Test Server developed by DNS-OARC to check and see if your resolver can accept EDNS0 packets and that your firewall (if there is one) is accepting IP fragments.
Note that if the results are smaller than you expect and if you are running a modern DNS software package (like BIND 9.5.0 or later), then the problem may lie behind a intermediary firewall, NAT device or router between your name server and the test server. Please fix any issues you see now or you will likely experience degraded performance from the root servers once the signed root is fully rolled out.
What is ISC doing to prepare F.ROOT-SERVERS.NET (F-Root) to support a signed root?
ISC has been a long-standing supporter of DNSSEC, including extensive contributions to the protocol by our engineers, and has been operating F-Root in a DNSSEC-ready state for several years now by running a DNSSEC aware DNS server, etc.
F-Root is scheduled to load the signed root zone (“DURZ”) the week of the 12th of April, 2010.
By then ISC will have standardized all F-Root servers to be running BIND 9.6.2, which is the first BIND release to have full support for the SHA-2 DNSSEC algorithm which will be used to sign the root zone. Note that this step is not strictly needed since the root servers are serving the content and not doing validation.
ISC will also be adjusting its monitoring across F-Root so that we are now tracking both UDP and TCP queries, as we expect a increase in TCP traffic to the root servers once the root zone is signed. We will upload any significant data events during the six-month rollout of the signed root zone to the DNS-OARC PCAP repository so that it’s available to researchers for further analysis.