Resumo

  • A revisão 14 do rascunho DNSOP considera contínua uma delegação quando o pai ainda encaminha ao mesmo ponto e o conjunto NS atual compartilha pelo menos um nome com o conjunto guardado. Se havia DS nos dois estados, também é necessário pelo menos um signatário delegado comum.
  • Um conjunto NS inteiramente novo, um conjunto DS inteiramente novo ou a mudança entre ausência e presença de DS representa mudança de autoridade. O cache deixa de usar os dados naquele ponto e abaixo dele; revalidação estrita e oportunista distribuem disponibilidade e confiança de maneiras diferentes.
  • A interseção resolve uma decisão do cache, não autentica a migração. Um recibo de transição deveria unir sobreposição planejada, estados do pai e do filho, referência do registro, três TTLs, data de retirada e responsável pela reversão. É uma proposta de Daniel Kade, não texto da IETF.

A delegação DNS clássica é publicada em dois lugares. A zona pai entrega a referência NS, o glue necessário e, quando há DNSSEC, o DS. A zona filha publica no ápice seu próprio conjunto NS autoritativo. A RFC 1034 espera consistência entre os dois lados do corte, mas o protocolo não oferece uma operação atômica que altere pai e filho juntos.

Isso produz divergências sem que o domínio pare de funcionar. Um TLD pode fixar TTL longo, enquanto o filho quer mudar rápido com TTL curto. A fila do registrador e a operação do provedor avançam em momentos diferentes. Respostas mínimas deixam de incluir o NS do ápice. Como aplicações usuais não perguntam diretamente por ele, o resolvedor pode nunca aprender a versão autoritativa do filho.

Publicado em 2 de setembro de 2026, o Delegation Revalidation by DNS Resolvers revisão 14 propõe um comportamento opcional e previsível. O Datatracker o classifica como Internet-Draft ativo do DNSOP, no Standards Track, com status pretendido Proposed Standard, aguardando avanço dos chairs. Expira em 6 de março de 2027. Não é RFC nem obrigação de ativação.

O mecanismo faz três movimentos. Ao cruzar uma referência, pergunta diretamente ao filho pelo NS do ápice e prefere a resposta autoritativa à cópia não autoritativa do pai, conforme a ordenação da RFC 2181. Busca dados A e AAAA autoritativos para os nomes. Mais tarde, retorna ao pai para descobrir se a delegação ainda existe e se a autoridade preserva continuidade suficiente.

A regra não conta votos

O cache guarda os nomes delegados pelo pai e os TTLs do NS e, quando observado, do DS. Na revalidação, o pai deve continuar retornando uma referência para o mesmo ponto. O conjunto NS novo precisa ter ao menos um nome em comum com a fotografia anterior.

Quando os dois estados contêm DS, a interseção deve incluir ainda um signatário delegado. A ressalva é indispensável: conservar um NS não compensa uma troca completa da cadeia de assinatura. Passar de DS vazio a presente, ou de presente a vazio, também é mudança de autoridade.

Não há maioria. Quatro nomes antigos podem virar um antigo e três novos. Um rollover pode manter um signatário anterior enquanto introduz outro. A escolha permite migrações graduais sem tratar cada alteração como ruptura total.

Já a ausência de referência, a mudança do corte, ou conjuntos NS ou DS totalmente novos obrigam outra resposta. Os dados guardados naquele ponto e abaixo não podem mais ser usados. O software pode apagá-los de imediato ou tornar uma geração anterior inalcançável; para a próxima consulta, devem ter desaparecido.

Esse teste é propositalmente estreito. Ele não sabe se o nome comum pertence ao fornecedor que está saindo, a um anycast compartilhado, a um serviço do registrador ou a um ativo esquecido. Não prova titularidade, autorização humana, saúde do servidor ou ausência de comprometimento. Sua função é proteger a lógica do cache.

O filho tem dado mais forte; o pai pode revogar

O NS do ápice é autoritativo porque o filho responde por ele. O NS do pai é referência. A revisão 14 manda uma consulta específica ao filho, em paralelo à resolução que encontrou o corte, para que a informação melhor possa entrar no cache.

Se a consulta funciona, as próximas perguntas preferem os nomes do filho. Se falha ou recebe NODATA, o pai continua como caminho de maior classificação disponível. No modo oportunista, a resposta do usuário pode ter sido entregue antes do fim dessa verificação.

Preferir o filho não significa deixá-lo renovar o próprio mandato para sempre. O pai pode remover a delegação ou entregá-la a outro operador. Se o resolvedor só atualizar o NS do filho, um servidor antigo pode continuar alimentando o cache depois da redelegação. A visita periódica ao pai limita esse domínio fantasma.

As direções de glue têm proveniência própria. Elas podem ser necessárias para alcançar o filho, embora não sejam autoritativas. Um RRset completo, assinado e seguro pode subir de classificação; nos demais casos, consultas adicionais são necessárias. Se todas as direções melhores estiverem inalcançáveis, a implementação pode usar o glue inferior como último recurso.

Esse fallback salva disponibilidade e complica a auditoria. Uma coleta de NS não diz qual endereço respondeu, qual nível venceu nem se a validação terminou antes do serviço.

Estrito e oportunista compram resultados diferentes

No modo estrito, o resolvedor pode atrasar a consulta original até confirmar um servidor cujo nome e endereço foram obtidos de forma autoritativa. Ganha proteção contra redirecionamento e observação no caminho. Perde a saída de emergência: dados ruins no filho podem causar falha dura.

Por isso o texto recomenda limitar a elevação estrita à raiz e às zonas delegadas diretamente por ela. Em níveis inferiores ainda há servidores que tratam mal perguntas explícitas pelo NS do ápice.

No modo oportunista, a resolução avança e o aprendizado serve ao futuro. Diante de um filho incompatível, o resolvedor abandona o algoritmo para aquela zona e volta ao pai. O serviço é mais tolerante, mas a proteção não é equivalente.

Uma política séria informa profundidade, modo, fallback e escopo da limpeza. “Revalidação ligada” não basta para prever o impacto de uma transição defeituosa.

O menor TTL encontra um piso local

O prazo máximo é o menor entre TTL do NS do pai, TTL do DS do pai, quando existe, e TTL do NS do filho. O relógio do pai limita a sobrevivência de uma delegação removida. O do filho pede nova observação do conjunto operacional.

O rascunho também recomenda que o resolvedor imponha um piso mínimo razoável para evitar trabalho computacional forçado por TTLs minúsculos. Não há um valor universal. Assim, o TTL mais curto publicado por um operador não promete revogação simultânea em todos os caches.

Falhas precisam de cache negativo conforme a RFC 9520, evitando repetição agressiva. Reconsultar NS e endereços pode elevar bastante o tráfego autoritativo. Limites de trabalho por consulta integram a defesa contra abuso.

Diferença observada não é culpa decidida

Se o NS do ápice diverge da referência, o resolvedor pode reportar aos canais RFC 9567 do pai e do filho. A revisão 14 propõe um Extended DNS Error específico, ainda marcado como TBD.

A diferença pode ser etapa planejada, atraso de fila ou efeito de TTL. Não implica falha. O relatório diz o que um resolvedor viu e quando; não autentica o pedido no registrador nem decide se a sobreposição foi intencional.

Mesmo uma resposta perfeita não encerra a governança. Um servidor antigo pode servir corretamente sem que alguém ainda responda por sua permanência.

Um recibo para a ponte temporária

Ao migrar de A para B, manter um NS de A e um signatário anterior pode reduzir risco. Para o cache, a autoridade é contínua. Para a operação, a ponte precisa de finalidade e vencimento.

O recibo separa estado antigo, estado alvo e intervalo autorizado. Registra NS e glue do pai, DS, NS do ápice filho e endereços autoritativos. Identifica os nomes e signatários que devem permanecer comuns e a condição que os retira.

Em seguida, liga a mudança observável à referência de registrador ou registro, ao fornecedor anterior, ao novo, a quem aprova a remoção final e a quem pode reverter. Não substitui autenticação nem armazena segredos; aponta para o processo que a fez.

Os três TTLs, o menor disparador e a hipótese sobre pisos dos resolvedores ficam em linhas distintas. Parar de aceitar configuração, apagar o NS no pai, desligar resposta autoritativa e deixar de receber tráfego são quatro momentos diferentes.

O acompanhamento testa caminhos estritos e oportunistas. Se o objetivo é trocar tudo de uma vez, prevê a invalidação abaixo do corte e o pico de consultas. O fechamento exige convergência de pai e filho, retirada da sobreposição, silêncio autoritativo do sistema antigo e fim formal da janela de rollback.

O resolvedor não lê esse recibo, e a IETF não o exige. Ele existe para completar o que a comparação de conjuntos não pretende fazer: provar que a continuidade foi autorizada, limitada e encerrada.

Fontes

  1. Revalidação de delegações por resolvedores DNS — revisão 14
  2. Registro Datatracker do rascunho
  3. Histórico da revalidação de delegações
  4. Documentos ativos do DNSOP
  5. Carta do DNSOP
  6. RFC 1034 — Conceitos e instalações de nomes de domínio
  7. RFC 2181 — Esclarecimentos da especificação DNS
  8. RFC 9520 — Cache negativo de falhas de resolução
  9. RFC 9567 — Relato de erros DNS
  10. Delegação extensível para DNS — revisão 11