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?
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.
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;Another solution to test your setup, which I find much simpler than Netalyzr, is OARC reply size test.