Resumo

  • A revisão 01 de dry-run DNSSEC cria um estado intermediário: o resolvedor compatível valida a zona assinada e relata anomalias, porém, se o resultado for bogus, entrega ao cliente comum a resposta insegura que existiria sem o DS de ensaio.
  • O relatório NOERROR proposto comprova a presença de um participante que obteve sucesso. Não fornece o total de resolvedores silenciosos nem de clientes atrás deles; os relatórios da RFC 9567 são amortecidos por cache e não autenticam o emissor.
  • Antes de o pai trocar o DS de ensaio pelo DS real, um recibo de graduação deve registrar coorte, testes de cliente, estado parental, limites do transporte, situação do registro e incertezas. É uma recomendação de Daniel Kade, não uma obrigação do IETF.

O passo mais severo de uma implantação DNSSEC não fica apenas na zona filha. Enquanto o pai não publica um DS, é possível examinar assinaturas sem formar uma cadeia pública de confiança. Depois da publicação, um defeito que parecia local pode virar SERVFAIL em resolvedores validadores e alcançar usuários por caches que o operador da zona não controla.

O grupo DNSOP trabalha em um degrau entre preparação e imposição. A revisão 01 de dry-run DNSSEC, publicada em 21 de junho de 2026, é um Internet-Draft ativo de grupo de trabalho e declara intenção de Standards Track. Ainda não é RFC, padrão aprovado nem evidência de implantação por qualquer provedor. Seus códigos EDE e EDNS continuam a definir.

A proposta explora a regra da RFC 6840 para algoritmos de digest DS desconhecidos. O validador desconsidera um DS autenticado cujo algoritmo não consegue usar. Sem outro caminho de autenticação suportado, trata o filho como não assinado. O rascunho associa valores de ensaio pelo bit mais significativo e exige que o RRset do pai contenha somente DS desse tipo; misturá-los com DS comuns faz o mecanismo perder a distinção pretendida.

Dois grupos passam a observar a mesma delegação de formas diferentes. Um resolvedor sem suporte ignora o algoritmo estranho, resolve a zona de modo inseguro e não envia telemetria de ensaio. Um resolvedor compatível reconhece a indicação, valida a zona e pode relatar o resultado. Se tudo estiver correto, pode marcar os dados como autênticos. Se a validação for bogus, preserva o diagnóstico, mas não entrega ao cliente normal a falha DNSSEC: retorna a resposta insegura disponível na ausência do DS de ensaio.

Esse fail-open não é proteção parcial. O rascunho diz que a delegação ainda não deve ser considerada assinada e alerta que o retorno inseguro suspende a garantia de integridade, permitindo que respostas forjadas afetem a zona. O ensaio compra visibilidade sobre rotas reais ao preço de ainda não aplicar a segurança. Por isso é transição, não destino operacional.

Ver a falha não é aplicá-la

Os Extended DNS Errors da RFC 8914 classificam a causa do problema. A RFC 9567 define o canal de DNS Error Reporting: o resolvedor cria uma consulta para o domínio de um agente de monitoramento anunciado pelo servidor autoritativo, incorporando ao nome o QNAME defeituoso, o QTYPE e o código EDE.

O relato prova que um caminho implantado, com seu validador e seu cache, encontrou uma anomalia. É mais informativo que um teste isolado porque inclui condições da operação. Mesmo assim, sua afirmação válida é estreita: algum caminho de relatório observou um erro específico em certo momento.

A RFC 9567 não autentica a identidade do resolvedor perante o agente. TCP e DNS Cookies dificultam falsificação do endereço, mas não transformam a origem aparente em identidade institucional. Relatórios UDP e seus dados podem ser forjados. O sistema também pode expor falhas internas do resolvedor, como âncoras de confiança antigas, razão pela qual a minimização do nome consultado é uma proteção importante de privacidade.

O cache reduz deliberadamente repetições. Um nome construído além do limite não é enviado; um agente inacessível também não recebe sinal. Assim, a contagem do painel é moldada por amortecimento, transporte e implementação. Não equivale ao número bruto de consultas, resolvedores independentes ou pessoas afetadas.

NOERROR confirma presença, não representatividade

Um gráfico vazio pode indicar uma zona correta. Também pode indicar que nenhum resolvedor compatível chegou, que nenhum deles recebeu consulta, que o relatório foi amortecido, que o agente estava indisponível ou que o software não implementou o mecanismo.

A revisão 01 propõe o NOERROR para reduzir essa ambiguidade. Depois de validar a zona com sucesso, um participante envia um sinal positivo formado no ápice da zona. O cache limita sua frequência. O operador ganha evidência de que pelo menos um observador compatível esteve presente e concluiu uma verificação.

O que permanece ausente é o denominador externo. Resolvedores incompatíveis ficam mudos por projeto ao tratar o filho como não assinado. Compatíveis sem tráfego também não aparecem. Um NOERROR não enumera todos os clientes que usam aquele resolvedor, nem suas rotas futuras ou os demais estados do cache. A razão entre êxitos e erros descreve apenas a coorte observada.

O rascunho cita relatórios DMARC, o sentinela da âncora da raiz da RFC 8509 e a sinalização de âncoras da RFC 8145. Esses precedentes mostram o valor de observadores atuais e bem posicionados, mesmo quando poucos. Não demonstram que a amostra representa automaticamente toda a internet.

Wet-Run identifica quem aceitou receber o erro

O retorno inseguro mantém o serviço do cliente comum, mas não testa como uma aplicação reage ao bloqueio real de DNSSEC. A opção EDNS Wet-Run proposta permite que um cliente escolha receber o erro verdadeiro da validação em ensaio. O resolvedor compatível guarda o estado de ensaio junto ao estado normal em cache e devolve a opção quando apresenta a falha. O resolvedor sem suporte ignora o pedido.

Esse opt-in testa uma combinação explícita de aplicativo, rede e resolvedor. Não cobre quem não participou. Também não pode ser substituído por um NOERROR gerado no lado do resolvedor. Chamar ambos de um único “teste aprovado” apagaria o caminho exercitado e o consentimento para sentir a falha.

Respostas negativas introduzem outra superfície. A RFC 8198 permite sintetizar uma resposta com provas NSEC ou NSEC3 já validadas em cache. A eficiência pode esconder uma prova negativa quebrada na autoridade. O rascunho orienta o resolvedor a suspender a síntese, consultar o autoritativo de forma explícita, comparar os resultados e informar a divergência com um EDE proposto.

O pai controla a graduação

A assinatura do filho não instala o modo. O pai precisa aceitar e publicar o DS especial. Se a interface recebe DS, o filho fornece o valor de ensaio. Se o pai gera DS a partir de DNSKEY, necessita de uma opção de modo ou de lógica que interprete um CDS acompanhado. CDNSKEY sozinho não transporta a distinção proposta; o texto recomenda publicar CDS e CDNSKEY.

Graduar significa substituir no pai todo o conjunto de DS de ensaio pelo conjunto real. A solicitação, a aceitação, a publicação observada e a expiração dos estados antigos em cache são fatos separados. Um único horário de “mudança” não comprova todos eles.

A troca também muda o contrato com o resolvedor. Durante o ensaio, o resultado bogus vira telemetria e resposta insegura ao usuário comum. Com um DS real suportado, o mesmo defeito pode interromper a resolução. O limiar do painel, portanto, não é mera preferência de monitoramento: participa da autorização para que uma população externa passe a impor as afirmações criptográficas do filho.

O sinal ainda precisa de espaço no registro

A revisão 01 propõe usar o bit mais significativo do algoritmo de digest DS e pede à IANA que reconheça 128–255 para Dry-run DNSSEC. O registro atual não mostra essa atribuição. Atualizado em 13 de janeiro de 2026, lista 128–252 como Reserved, 253–254 como Private Use e 255 como Unassigned, com referência à RFC 9904.

Se a especificação avançar, haverá necessidade de reconciliação explícita. O estado atual não significa rejeição pela IANA: uma ação pedida em Internet-Draft só se torna atribuição ao fim do processo apropriado. Até lá, o bloco inteiro não pode ser descrito como espaço público já concedido.

A RFC 9904 também separa recomendações de uso e de implementação. Software capaz e operação ativa não são o mesmo fato. Da mesma forma, suportar o ensaio, observar esta zona e carregar tráfego de clientes importantes exigem provas distintas.

Um recibo de graduação verificável

O recibo começa por artefatos precisos: impressão digital da zona assinada, conjunto DNSKEY, DS de ensaio proposto, submissão ao pai, aceitação e publicação observada. Registra separadamente a janela de observação, os pontos autoritativos consultados e o horizonte dos caches.

Depois descreve a coorte, sem chamá-la de censo. Quais resolvedores tiveram identidade corroborada por evidência independente? Quais eram apenas origens com maior confiança por TCP ou Cookie? Quantos NOERROR e erros sobreviveram ao amortecimento? Quais nomes, tipos e códigos apareceram, e como cada correção foi testada e encerrada? A agregação protege a privacidade sem apagar a estrutura da evidência.

Testes de cliente ficam em seção própria: Wet-Run por rede, resolvedor e classe de aplicativo; comparação com retorno comum; respostas positivas e negativas; consultas explícitas NSEC/NSEC3; prazos de cache; populações inalcançáveis. O retrato vigente do registro IANA acompanha a decisão, com códigos experimentais rotulados como não atribuídos.

Por fim, o recibo nomeia quem pode autorizar o DS real, qual evidência mínima e quais incógnitas essa pessoa aceita, quem responde pela reversão e como ela foi ensaiada. Submissão, aceitação, publicação observada e validação posterior têm horários distintos.

O documento não prova todos os resolvedores. Seu objetivo é impedir que uma amostra escolhida seja rebatizada de “internet” no registro decisório. Evidência limitada ainda pode justificar ação, desde que o responsável pelas consequências consiga enxergar a fronteira aceita.

Fontes

  1. dry-run DNSSEC — revisão 01
  2. Registro de dry-run DNSSEC no Datatracker
  3. Histórico do documento
  4. Documentos ativos do DNSOP
  5. Carta do DNSOP
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — notas de implementação DNSSEC
  9. RFC 8198 — uso agressivo do cache validado
  10. RFC 8509 — sentinela da âncora da raiz
  11. RFC 8145 — sinalização de conhecimento de âncora
  12. RFC 9904 — atualização de recomendações criptográficas
  13. Registro IANA de algoritmos de digest DS