6

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?

4
  • 1
    To summary Alnitak's excellent but very detailed answer: even if you did not enable DNSSEC you have, not to worry, but to check.
    – bortzmeyer
    Jan 26, 2010 at 10:22
  • The statement by the RIPE-NCC that you quote is WRONG.
    – bortzmeyer
    Jan 26, 2010 at 10:23
  • @bortzmeyer: Is the statement by RIPE-NCC incorrect, or is my interpretation of it what is incorrect?
    – brent
    Jan 26, 2010 at 15:43
  • The statement by RIPE-NCC. Since they know the DNS, I assume they were simply too hasty in writing.
    – bortzmeyer
    Jan 26, 2010 at 21:18

3 Answers 3

10

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.

0
3

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;
1

Another solution to test your setup, which I find much simpler than Netalyzr, is OARC reply size test.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .