What are the effects of the L root server now publishing DURZ?
I'm curious what the actual effects of the L root server publishing DURZ today will be. On the nanog mailing list, someone said it's important to evaluate the systemic effects of root name servers publishing signed zones, even when not using DNSSEC. Meanwhile, RIPE's own published information on their changes to the K root server say there's no issue if your resolvers don't use DNSSEC. Can someone please clear this up? DNSSEC seems to be a messy, tangled web.
If not enabling DNSSEC on my resolvers, do I have anything to worry about with the upcoming changes to the root servers?
Solution 1:
You may see something, but to some extent that depends on which DNS software you're running.
In particular, BIND sets the "DNSSEC OK" (aka DO) bit on upstream queries even when not specifically asking for DNSSEC records or performing DNSSEC validation.
In those circumstances the root servers may send back additional DNSSEC records which may cause problems in the unlikely event that you've got broken network gear and/or misconfigured firewalls in the path.
Those problems mostly relate to packet size. Some kit doesn't like DNS UDP packets that exceed 512 bytes in length, either through buggy firmware or errorenous recommended configurations from the vendor. See my RFC 5625 for more details. Note though that most of the DNSSEC-related problems that I report on in that RFC relate to consumer class gear, and only in unusual configurations.
Do note that if your kit does have problems with large UDP packets, then the fallback is to use TCP. However some (misguided) security people configure their firewalls to disable outbound DNS over TCP, which breaks the fallback. See this IETF draft for more information about DNS over TCP.
By the way, to test your network's configuration for possible DNS quirks, I'd highly recommend the excellent Netalyzr website from ICSI at UC Berkeley.
To be clear, however, most DNS experts are not expecting significant issues because of the introduction of DNSSEC. Several TLDs (including .org and .se) have already been signed and the internet didn't collapse because of it.
The DURZ is a deliberate attempt to gradually phase in the larger responses that DNSSEC inevitably produces so that those rare sites that have network issues may resolve them before the entire root zone goes over to DNSSEC in the summer.
Solution 2:
An explanation of what can go wrong, in pseudo-code, for those who prefer imperative programming languages :-)
-- Pseudo-code (syntax more or less Ada-like) to show what happens to
-- a DNS resolver when the root is signed and the responses become
-- larger.
-- Background information:
-- https://www.dns-oarc.net/oarc/services/replysizetest
-- RFC 5625
-- SSAC report #35 http://www.icann.org/committees/security/sac035.pdf
-- Stephane Bortzmeyer
-- Variables used:
-- EDNS0: boolean, indicates if the resolver sends EDNS0 requests
-- EDNS0_Size: positive integer, the buffer size advertised by EDNS0
-- DO_DNSSEC: boolean, the DO flag indicating DNSSEC support by the resolver
-- Min_Response_Size: integer, the minimum (after dropping
-- unnecessary RR) size of the DNS response sent by the authoritative
-- server
-- Clean_path_for_fragments: boolean, indicates that UDP fragments
-- can travel from the authoritative name server to the resolver
-- Clean_Path_For_EDNS0: boolean, indicates that EDNS0 responses
-- (which may be larger than 512 bytes) can travel from the
-- authoritative name server to the resolver
-- Can_TCP: boolean, indicates that the resolver can ask through TCP
-- (which implies a clean TCP patch and an authoritative name server
-- which accept TCP)
-- The code can be executed several times for one request, for
-- instance because a resolver tries first with UDP, then retries
-- with TCP.
if UDP then -- MOst common transport protocol for DNS
if EDNS0 then
if EDNS0_Size > MTU then
-- BIND default, EDNS0_size = 4096 bytes
if DO_DNSSEC then
-- BIND default, even if not configured for validation
if Min_Response_Size > MTU then -- Not the case today with the root
if Clean_Path_for_fragments then
OK;
else
-- After a while BIND will switch to no-EDNS0, start over
Retry("Responses not received may be because of EDNS0");
end if;
elsif Min_Response_Size > 512 then
-- No fragmentation will occur
if Clean_Path_For_EDNS0 then
OK; -- That's the normal and typical case for a BIND
-- resolver today, with the signed root
else
Retry("Responses not received may be because of EDNS0");
end if;
else -- Won't occur today, responses from the root are already > 512
OK;
end if;
else
-- Without DNSSEC, responses wil be shorter but some
-- responses from the root already are > 512
if Min_Response_Size > MTU then
-- Unlikely, without DNSSEC
if Clean_Path_for_fragments then
OK;
else
Retry("Responses not received may be because of EDNS0");
end if;
elsif Min_Response_Size > 512 then
if Clean_Path_For_EDNS0 then
OK;
else
Retry("Responses not received may be because of EDNS0");
end if;
else -- Most common case today, the typical unsigned
-- answer is 100-200 bytes
OK;
end if;
end if;
elsif EDNS0_Size >= 512 then -- But lower than the MTU
if DO_DNSSEC then
if Min_Response_Size > EDNS0_Size then
-- This assumes that DNS packets with TC bit set arrive
-- safely, not always true
Retry("Truncation");
elsif Min_Response_Size >= 512 then
if Clean_Path_for_EDNS0 then
OK;
else
Retry("Responses not received may be because of EDNS0");
end if;
else -- Won't often occur today, some responses from the root are already > 512
OK; -- Not always, some middleboxes may block EDNS0
-- responses, even with size 512 then
if Clean_Path_For_EDNS0 then
OK;
else
Retry("Responses not received may be because of EDNS0");
end if;
else
OK;
end if;
end if;
else -- EDNS0 with size 512 then
Retry("Truncation");
else
OK;
end if;
end if;
else -- TCP
if Can_TCP then
OK; -- But higher latency and higher load on authoritative name servers
else
Error("Fallback to TCP failed"); -- Complete and total failure
end if;
end if;