Resumo

  • draft-ietf-dnsop-ns-revalidation-14 permite elevar a credibilidade do NS autoritativo no ápice do filho, mas exige uma consulta posterior ao pai; sem ela, o antigo filho poderia renovar indefinidamente uma autoridade que a delegação já retirou.
  • A conclusão operacional depende de uma cadeia: referral parental, sobreposição de NS e DS, menor TTL de sustentação, descarte dos descendentes do cache e nova resolução. Uma resposta bem-sucedida não substitui essa cadeia.

A mudança que o cache não viu

O registro publicou novos servidores. O novo operador carregou a zona. A equipe de migração encerrou a janela. Mesmo assim, um resolvedor recursivo continuou consultando o provedor anterior. Seus servidores ainda tinham dados, ainda respondiam e ainda marcavam as respostas como autoritativas.

Não era necessário que houvesse pane, invasão ou pacote malformado. Bastava que o cache renovasse a visão do filho sem voltar ao pai. A operação antiga permanecia funcional enquanto a autoridade que a introduzira já havia mudado.

A revisão 14 de draft-ietf-dnsop-ns-revalidation, de 2 de setembro de 2026, descreve um algoritmo opcional para impedir que essa assimetria dure para sempre. O texto é um Internet-Draft ativo do DNSOP, destinado a Proposed Standard, com estado I-D Exists e aguardando autorização dos presidentes do grupo. Não é RFC nem comprovação de adoção em um resolvedor específico.

Seu ponto decisivo é outro: o bit autoritativo pertence à resposta do filho. A delegação atual pertence à cadeia que começa no pai. As duas afirmações precisam de recibos diferentes.

Duas listas na mesma fronteira

Uma delegação tradicional mantém um conjunto NS no pai e outro no ápice do filho. RFC 1034 recomenda que os administradores mantenham ambos consistentes, mas o protocolo não oferece uma atualização atômica entre as zonas.

Pelas regras de credibilidade do RFC 2181, o conjunto do filho é autoritativo e supera o conjunto não autoritativo do referral parental. Essa preferência é útil. O filho conhece sua infraestrutura e pode usar TTL menor para trocar servidores mais rapidamente do que o TTL fixo de um TLD permitiria.

Por isso, a revisão 14 recomenda que o resolvedor consulte explicitamente o NS do ápice ao descobrir uma fronteira e o prefira no cache. Também recomenda consultar novamente endereços A e AAAA recebidos como glue ou dados adicionais de menor credibilidade. Em uma delegação segura, a consulta NS pode ocorrer junto da consulta DNSKEY.

O ganho de credibilidade responde quais servidores o filho declara. Ele não autoriza o filho a comprovar que o pai ainda o escolhe. Se o próprio filho pudesse renovar essa segunda afirmação, a remoção feita pelo pai jamais venceria um cache ativo.

O menor TTL limita todos

O resolvedor deve revalidar no máximo ao final do menor TTL entre o NS delegante do pai, o DS do pai quando existir e o NS do ápice filho.

Cada duração limita uma relação. O TTL do NS parental limita a confiança na rota da delegação. O TTL do DS limita a relação com o signatário delegado. O TTL do NS filho limita a atualidade da topologia declarada pelo próprio filho. Escolher o menor impede que uma camada estenda o poder concedido por outra.

O texto recomenda um piso razoável para o resolvedor não ser forçado a executar trabalho contínuo por zonas com TTL extremamente curto. Esse piso protege disponibilidade e capacidade. Não demonstra que a autoridade permaneceu estável no tempo adicional. O registro precisa mostrar valores originais, piso local, horário de aquisição e prazo efetivamente aplicado.

Uma única coluna “expira em” apaga a procedência do prazo. Durante uma investigação, faz diferença saber se venceu a delegação, o vínculo de assinatura ou a declaração do filho.

Sobreposição é continuidade limitada

No ponto de revalidação, o pai precisa continuar devolvendo um referral para o mesmo corte. O novo conjunto NS parental deve compartilhar ao menos um nome de servidor com o conjunto guardado. Quando havia e continua havendo DS, deve existir ao menos um signatário delegado em comum.

Ausência de referral, mudança do corte, NS totalmente novo ou DS totalmente novo significam mudança de hierarquia ou autoridade. A passagem de DS vazio para não vazio, ou de não vazio para vazio, também conta como mudança.

Essa regra permite migração gradual. Um servidor ou signatário comum pode preservar continuidade enquanto outros são trocados. Porém, a interseção não prova igualdade integral. Não diz que endereços, chaves, conteúdo ou resultado de aplicação são os mesmos.

Também não resolve propriedade jurídica. O resolvedor decide apenas se a evidência parental atual ainda sustenta o uso do cache anterior. Contratos e disputas pertencem a outra superfície de autoridade.

Uma mudança superior invalida resultados inferiores

Quando muda a forma da hierarquia ou a autoridade, dados em cache naquele ponto e abaixo dele não podem continuar em uso. A implementação pode apagar diretamente, marcar uma geração antiga ou recolher de modo preguiçoso. Para a consulta, o efeito deve ser equivalente à remoção.

O alcance inclui endereços, correio, descoberta de serviços, respostas negativas e delegações mais profundas. Trocar só o ponteiro do pai, mantendo conclusões descendentes, preservaria dados cuja base de autoridade deixou de existir.

Daí a vantagem de revalidar da raiz para baixo. Uma alteração superior pode dispensar todas as verificações inferiores. RFC 8020 mostra como um NXDOMAIN pode valer para nomes abaixo de um ponto. Aqui a dependência aparece pelo outro lado: se o suporte superior mudou, os bytes inferiores ainda armazenados perderam sua justificativa anterior.

Persistência física no cache não é permissão lógica de uso.

O modo estrito tem preço de disponibilidade

No modo estrito, o resolvedor pode atrasar a resposta disparadora até confirmar que o servidor possui nome e endereço obtidos autoritativamente. Quando a infraestrutura é assinada e a validação funciona, isso dificulta redirecionamento e observação por um intermediário.

Sem fallback para dados de menor classificação, uma configuração NS quebrada ou um servidor que processa incorretamente consultas explícitas ao ápice pode produzir falha dura. A revisão 14 recomenda limitar essa elevação estrita à raiz e às zonas diretamente delegadas por ela.

No modo oportunista, a resposta pode sair antes da consulta de validação. O resolvedor pode recorrer ao referral do pai. Se o filho não responder corretamente ao NS explícito, o algoritmo deve ser abandonado para aquela zona. Há mais tolerância, mas não a mesma proteção.

Um painel que mostra apenas “revalidação: ligada” não registra essa escolha. É preciso separar respostas retidas, respostas emitidas antes da prova, fallback, falha dura e o momento em que uma nova geração de cache entrou em vigor.

DNSSEC não cobre todo o caminho de infraestrutura

Conjuntos NS de referral, glue e endereços adicionais A e AAAA geralmente não carregam assinaturas DNSSEC. Quem altera um endereço não assinado pode levar o resolvedor a um servidor hostil, que passa a observar consultas e interferir em referrals não assinados abaixo dele.

RFC 5452 fortalece a associação de transações e a entropia para reduzir respostas forjadas. A revalidação trata de outra pergunta: depois da transação, a infraestrutura seguida continua confiável e sustentada pelo pai?

Uma assinatura DNSSEC válida responde dentro do seu escopo. Não comprova que a consulta parental ocorreu a tempo, que a decisão foi aplicada, que todos os descendentes foram invalidados nem que a aplicação chegou ao serviço correto.

Diagnóstico não é efeito

O rascunho pede à IANA um código Extended DNS Error para divergência do NS de referral. RFC 8914 permite expor motivo mais específico. Isso ajuda a localizar a decisão do resolvedor, mas não altera a zona parental, não repara o filho e não sincroniza outros caches.

O EDE só se torna evidência forte quando ligado à resposta exata do pai, aos conjuntos comparados, aos TTL, ao modo, à geração invalidada e à resolução posterior. Isolado, é apenas um rótulo de sintoma.

RFC 9471 delimita a necessidade de glue em referrals. Um endereço necessário para alcançar um servidor ainda não prova delegação atual; um servidor alcançável ainda não prova entrega do serviço.

Apêndice de implementação não é censo

A revisão 14 registra que Unbound suporta revalidação oportunista por harden-referral-path, desativado por padrão, e que implementa a lógica da seção 7 desde a versão 1.4.17. Registra também revalidação da resposta de priming da raiz no Knot Resolver. Para o modo estrito, não conhece implementação além de protótipos e ferramentas dos autores.

Esses dados demonstram história de código, não configuração de uma instância, padrão de uma distribuição atual, adoção, taxa de sucesso ou interoperabilidade. Capacidade documentada e comportamento observado são estados diferentes. A operação precisa de versão, configuração, consultas, temporizadores e transições reais do cache.

O recibo de uma delegação realmente atual

Um registro defensável inclui: build e configuração ativa do resolvedor; modo estrito ou oportunista; referral parental inicial com NS, DS, glue e horário; NS autoritativo do filho; endereços recuperados; três TTL e piso local; cadeia desde a raiz; nova resposta do pai; cálculo de interseção NS e DS; transição de DS vazio ou não vazio; geração e escopo invalidados; fallback, falha ou EDE; novo servidor escolhido; e observação independente do serviço.

O DNS continuará distribuído e temporariamente desigual. A disciplina não exige apagar essa realidade. Exige apenas que uma resposta do antigo filho não seja promovida, sem a volta ao pai, a prova de autoridade atual.

Fontes