Quais são os efeitos do servidor raiz L agora publicando o DURZ?

Question

Estou curioso para saber quais são os efeitos reais do servidor raiz L publishing DURZ hoje será. Na lista de discussão do nanog, alguém disse que é importante avaliar os efeitos sistêmicos dos servidores de nomes-raiz publicando zonas assinadas, mesmo quando não estiver usando o DNSSEC. Enquanto isso, as informações publicadas do próprio RIPE sobre suas alterações no servidor-raiz do K dizem que não há problema em se seus resolvedores não usam DNSSEC . Alguém pode por favor esclarecer isso? O DNSSEC parece ser uma teia bagunçada e emaranhada.

Se não habilitar o DNSSEC em meus resolvedores, tenho algo com que se preocupar com as próximas alterações nos servidores-raiz?

    

Answer 1

Você pode ver algo, mas até certo ponto isso depende de qual software de DNS você está executando.

Em particular, o BIND define o bit "DNSSEC OK" (também conhecido como DO ) em consultas upstream, mesmo quando não solicita especificamente registros DNSSEC ou realiza a validação DNSSEC.

Nessas circunstâncias, os servidores-raiz podem enviar de volta registros DNSSEC adicionais, que podem causar problemas no caso improvável de você ter equipamentos de rede quebrados e / ou firewalls mal configurados no caminho.

Esses problemas estão relacionados principalmente ao tamanho do pacote. Alguns kits não gostam de pacotes DNS UDP que excedam 512 bytes de comprimento, seja por meio de firmware defeituoso ou de configurações recomendadas com erro do fornecedor. Veja meu RFC 5625 para mais detalhes. Note, no entanto, que a maioria dos problemas relacionados ao DNSSEC que reporto nesse RFC se relacionam com equipamentos da classe do consumidor, e apenas em configurações incomuns.

Observe que, se o seu kit tiver problemas com grandes pacotes UDP, o substituto será usar o TCP. No entanto, algumas pessoas de segurança (mal orientadas) configuram seus firewalls para desabilitar o DNS de saída sobre TCP, o que interrompe o fallback. Consulte este esboço da IETF para obter mais informações sobre o DNS sobre TCP.

A propósito, para testar a configuração da sua rede quanto a possíveis peculiaridades do DNS, eu recomendo o excelente Site Netalyzr da ICSI na UC Berkeley.

No entanto, para ser claro, a maioria dos especialistas em DNS não está esperando problemas significativos por causa da introdução do DNSSEC. Vários TLDs (incluindo .org e .se) já foram assinados e a internet não entrou em colapso por causa disso.

O DURZ é uma tentativa deliberada de gradualmente introduzir as respostas maiores que o DNSSEC inevitavelmente produz para que os sites raros que têm problemas de rede possam resolvê-los antes que toda a zona de raiz passe para o DNSSEC no verão.

    

Answer 2

Uma explicação do que pode dar errado, em pseudo-código, para aqueles que preferem linguagens de programação imperativas: -)

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

    

Answer 3

Outra solução para testar sua configuração, que eu acho muito mais simples que o Netalyzr, é teste de tamanho de resposta do OARC .