Estou curioso para saber quais são os efeitos reais do servidor raiz Lpublicando DURZ hojevai ser. Na lista de discussão do nanog,alguém disseé importante avaliar os efeitos sistêmicos dos servidores de nomes raiz que publicam zonas assinadas, mesmo quando não usam DNSSEC. Enquanto isso, as informações publicadas pelo próprio RIPE sobre as alterações no servidor raiz K dizem que hánão há problema se seus resolvedores não usarem DNSSEC. Alguém pode esclarecer isso? O DNSSEC parece ser uma teia confusa e emaranhada.
Se não ativar o DNSSEC em meus resolvedores, tenho algo com que me preocupar com as próximas alterações nos servidores raiz?
Responder1
Vocêpoderiaveja algo, mas até certo ponto isso depende de qual software 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 executa validação de DNSSEC.
Nessas circunstâncias, os servidores raiz podem enviar de volta registros DNSSEC adicionais quepoderiacausar problemas no caso improvável de você ter equipamentos de rede quebrados e/ou firewalls configurados incorretamente 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 com bugs ou configurações incorretas recomendadas pelo fornecedor. Veja meuRFC 5625para mais detalhes. Observe, porém, que a maioria dos problemas relacionados ao DNSSEC que relato nessa RFC estão relacionados a equipamentos de classe de consumidor e apenas em configurações incomuns.
Observe que se o seu kit tiver problemas com pacotes UDP grandes, a alternativa é usar o TCP. No entanto, alguns profissionais de segurança (equivocados) configuram seus firewalls para desativar o DNS de saída sobre TCP, o que interrompe o substituto. VeresseRascunho da IETF para obter mais informações sobre DNS sobre TCP.
A propósito, para testar a configuração da sua rede em busca de possíveis peculiaridades de DNS, eu recomendo fortemente oexcelente Netalyzrsite do ICSI na UC Berkeley.
Para ser claro, no entanto, a maioria dos especialistas em DNS estánãoesperando problemas significativos devido à 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.
A DURZ é uma tentativa deliberada de implementar gradualmente as respostas maiores que o DNSSEC inevitavelmente produz, para que os raros sites que apresentam problemas de rede possam resolvê-los antes que toda a zona raiz passe para o DNSSEC no verão.
Responder2
Uma explicação do que pode dar errado, em pseudocódigo, para quem prefere linguagens de programação imperativas :-)
-- Pseudo-código (sintaxe mais ou menos parecida com Ada) para mostrar o que acontece com
-- um resolvedor DNS quando a raiz é assinada e as respostas se tornam
-- maior.
- Informações básicas:
-- https://www.dns-oarc.net/oarc/services/replysizetest
- RFC 5625
-- Relatório SSAC nº 35 http://www.icann.org/committees/security/sac035.pdf
--Stephane Bortzmeyer
-- Variáveis usadas:
-- EDNS0: booleano, indica se o resolvedor envia solicitações EDNS0
-- EDNS0_Size: número inteiro positivo, o tamanho do buffer anunciado por EDNS0
-- DO_DNSSEC: booleano, o sinalizador DO indicando suporte DNSSEC pelo resolvedor
-- Min_Response_Size: inteiro, o mínimo (depois de descartar
-- RR desnecessário) tamanho da resposta DNS enviada pela autoridade
-- servidor
-- Clean_path_for_fragments: booleano, indica que fragmentos UDP
-- pode viajar do servidor de nomes oficial para o resolvedor
-- Clean_Path_For_EDNS0: booleano, indica que as respostas do EDNS0
-- (que pode ser maior que 512 bytes) pode viajar do
-- servidor de nomes oficial para o resolvedor
-- Can_TCP: booleano, indica que o resolvedor pode perguntar através do TCP
-- (o que implica um patch TCP limpo e um servidor de nomes autoritativo
-- que aceitam TCP)
-- O código pode ser executado várias vezes para uma solicitação, por
-- instância porque um resolvedor tenta primeiro com UDP e depois tenta novamente
- com TCP.
se UDP, então - protocolo de transporte mais comum para DNS
se EDNS0 então
se EDNS0_Size > MTU então
-- BIND padrão, EDNS0_size = 4096 bytes
se DO_DNSSEC então
-- BIND padrão, mesmo que não esteja configurado para validação
if Min_Response_Size > MTU then -- Não é o caso hoje com o root
se Clean_Path_for_fragments então
OK;
outro
-- Depois de um tempo o BIND mudará para no-EDNS0, recomeçará
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
elsif Min_Response_Size > 512 então
- Nenhuma fragmentação ocorrerá
se Clean_Path_For_EDNS0 então
OK; -- Esse é o caso normal e típico para um BIND
-- resolvedor hoje, com a raiz assinada
outro
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
else -- Não ocorrerá hoje, as respostas da raiz já são> 512
OK;
fim se;
outro
-- Sem DNSSEC, as respostas serão mais curtas, mas algumas
-- as respostas da raiz já são> 512
se Min_Response_Size > MTU então
-- Improvável, sem DNSSEC
se Clean_Path_for_fragments então
OK;
outro
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
elsif Min_Response_Size > 512 então
se Clean_Path_For_EDNS0 então
OK;
outro
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
else -- O caso mais comum hoje, o típico não assinado
-- a resposta é 100-200 bytes
OK;
fim se;
fim se;
elsif EDNS0_Size >= 512 then -- Mas menor que o MTU
se DO_DNSSEC então
se Min_Response_Size > EDNS0_Size então
-- Isso pressupõe que os pacotes DNS com o bit TC definido cheguem
- com segurança, nem sempre é verdade
Retry("Truncamento");
elsif Min_Response_Size >= 512 então
se Clean_Path_for_EDNS0 então
OK;
outro
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
else -- Não ocorrerá com frequência hoje, algumas respostas da raiz já são> 512
OK; -- Nem sempre, algumas middleboxes podem bloquear EDNS0
-- respostas, mesmo com tamanho 512 então
se Clean_Path_For_EDNS0 então
OK;
outro
Retry("As respostas não recebidas podem ser por causa do EDNS0");
fim se;
outro
OK;
fim se;
fim se;
else -- EDNS0 com tamanho 512 then
Retry("Truncamento");
outro
OK;
fim se;
fim se;
senão - TCP
se Can_TCP então
OK; -- Mas maior latência e maior carga em servidores de nomes autorizados
outro
Error("Falha no retorno para TCP"); - Falha completa e total
fim se;
fim se;
Responder3
Outra solução para testar sua configuração, que considero muito mais simples que o Netalyzr, éTeste de tamanho de resposta OARC.