Resumo

  • O RFC 9975 delimita a coleta pela delegação publicada no pai: todos os nomes NS e todos os endereços obtidos para eles precisam entrar na rodada de consultas.
  • NODATA é uma resposta autoritativa e pode contradizer uma chave ou mudança; ausência de resposta exige novas tentativas, recuo e, quando útil, outra perspectiva de rede.
  • Se os estados relevantes divergem, a operação inteira é abortada sem criar, apagar ou alterar registros do pai. Concordância não substitui autorização, identidade nem a validação DNSSEC do estado resultante.

Há uma diferença decisiva entre encontrar uma resposta e possuir uma decisão. Um resolvedor normalmente para quando obtém dados utilizáveis. Um agente parental que pretende trocar DS, NS ou glue está prestes a converter uma observação do filho em estado durável numa camada superior do namespace.

Imagine que uma instância ofereça uma nova CDNSKEY e outra devolva NODATA. As duas respostas podem validar. As duas máquinas podem estar funcionando. O que falta não é autenticidade de pacote, mas uma solicitação compartilhada pelo serviço que a delegação apresenta ao mundo.

Publicado em maio de 2026, com Peter Thomassen como autor único, o RFC 9975 chama o requisito de “consistência plausível”. Ele não promete observar todas as instâncias por toda a eternidade. Exige uma coleta definida e reproduzível antes de automatizar CDS/CDNSKEY ou CSYNC, e um resultado conservador quando a coleta encontra contradição.

O conjunto de consulta vem da delegação existente

O agente parental parte dos nomes NS da delegação do filho na zona pai. Para cada nome, obtém todos os endereços IP por meio de um resolvedor validador, incluindo os dados de glue disponíveis. Só então envia a consulta pertinente diretamente a cada endereço.

Essa ordem impede que a própria solicitação escolha quem vai confirmá-la. Uma lista controlada pelo sinal poderia omitir o provedor que ainda publica o estado anterior. A delegação atual não prova titularidade ou intenção humana, mas registra qual serviço autoritativo o pai já anunciou à Internet.

Consultar o nome NS uma vez através de recursão também não basta. Um nome pode resolver para vários endereços, e eles podem alcançar instâncias e caminhos distintos. Anycast introduz outra limitação: o mesmo endereço pode levar a equipamentos diferentes conforme o ponto de observação. Por isso o RFC admite uma segunda localização de rede diante de falta de resposta.

O método não elimina incerteza topológica; ele a torna explícita. O registro da decisão deve mostrar qual delegação definiu o escopo, quais endereços foram descobertos, de onde vieram e quais realmente responderam naquela rodada.

NODATA é uma observação, silêncio é uma lacuna

NODATA significa que o servidor respondeu autoritativamente, mas não publicou o tipo consultado. O RFC 9975 o inclui expressamente nas respostas a comparar. Uma visão com uma chave CDS e outra com NODATA não formam, juntas, uma solicitação comum.

Descartar NODATA daria uma vantagem estrutural ao movimento: apenas os servidores que querem mudança contariam, enquanto uma resposta válida pela manutenção do estado seria apagada da amostra.

Nenhuma resposta é outra coisa. Perda, rota, filtro ou falha de serviço podem ter impedido a observação. O agente deve repetir a consulta antes de classificar o endereço como permanentemente inacessível. O documento oferece 5, 10, 20 e 40 minutos de recuo exponencial como exemplo, deixando o cronograma exato para a política local. Um segundo ponto de rede pode separar falha do servidor de falha do trajeto.

Não é uma espera infinita. A obrigação é declarar o critério que reduz o conjunto de testemunhas. Prazo, número de perspectivas, escalonamento e responsável precisam constar. Ausência de evidência não pode virar evidência positiva por conveniência.

Discordância mantém o pai exatamente como estava

Ao encontrar inconsistência, o agente não escolhe maioria, maior serial ou menor latência. Ele aborta. Não cria os registros previstos, não remove os que seriam retirados e não modifica o conjunto existente.

O estado anterior não é proclamado verdadeiro para sempre. Ele é o estado que o pai já publica e cuja exposição é conhecida. Escolher uma entre duas visões conflitantes pode interromper resolução ou validação. Preservá-lo permite que o filho conclua a replicação, corrija uma separação entre provedores ou use um procedimento autenticado fora de banda.

Uma nova tentativa refaz as consultas como uma nova rodada; não combina apenas respostas favoráveis de momentos diferentes. Há ainda uma otimização segura: se uma resposta já confirma o status quo, certas consultas pendentes de decisão podem ser retiradas. Qualquer resposta restante só confirmaria não mudar ou produziria inconsistência, que também bloqueia a escrita. A coleta para relatórios pode continuar.

A atomicidade também proíbe aplicar apenas a parte aparentemente segura de um CSYNC contraditório. O objeto da decisão é a operação projetada inteira, não um conjunto de alterações separadas por conveniência.

CDS e CDNSKEY exigem o mesmo conjunto de chaves

Consistência plausível não é igualdade byte a byte. Para CDS/CDNSKEY, cada chave elegível referenciada em qualquer resposta deve aparecer nas demais respostas relevantes. Presença em um servidor e ausência em outro constitui inconsistência.

O pedido de remover todo o conjunto DS precisa ser comum da mesma forma. Uma resposta de exclusão total não pode coexistir com uma atualização diferente ou NODATA e ser reinterpretada como uma transição. Os tipos de resumo incluídos na análise obedecem aos limites definidos; a política local do pai pode escolher formatos permitidos, mas não redefinir quais chaves foram coerentemente referenciadas pelo filho.

O RFC 10026, de Steve Sheng e Thomassen, publicado como Best Current Practice em julho de 2026, acrescenta um teste independente. O conjunto DS resultante precisa conservar um caminho DNSSEC válido. Todos os servidores podem concordar com uma mudança tecnicamente ruim. Coerência da intenção e continuidade da validação são comprovantes diferentes.

CSYNC compara o resultado da regra

CSYNC admite diferenças normais de replicação. O indicador immediate e o bitmap de tipos devem ser iguais entre respostas recebidas. Os seriais SOA podem divergir; cada serial do CSYNC é examinado contra o SOA obtido do mesmo servidor. O resultado da avaliação — a atualização é permitida ou não — precisa coincidir.

Quando CSYNC identifica conjuntos a sincronizar, como NS ou endereços, os RDATA relevantes devem ser iguais, inclusive quando todos os conjuntos são vazios. As regras próprias do mecanismo, entre elas a ordem de alterações de servidores de nomes e glue, continuam válidas.

“Perguntar a todos” é, portanto, só a geometria da coleta. A implementação precisa de um comparador por família de registro, capaz de separar diferença permitida, estado transitório e contradição que torna a mudança indecidível.

A notificação chama o inspetor, não aprova a obra

Thomassen também é coautor do RFC 9859, que permite ao filho avisar sobre uma alteração relacionada a CDS. O pai pode começar a inspeção sem esperar a próxima varredura periódica.

O aviso não pula nenhuma verificação. O receptor inicia as mesmas consultas DNS e controles que um temporizador iniciaria. Entrega da notificação, cobertura dos endereços, consistência, validação do DS projetado, publicação no pai e visibilidade depois dos caches são recibos separados.

Juntá-los num único sinal verde de “automação concluída” faz a mensagem mais recente parecer prova de todas as etapas. A notificação reduz a latência de descoberta; não amplia a autoridade da solicitação.

Consistência não comprova quem podia mandar

Um valor igual em todos os servidores não identifica o titular, não demonstra quem instruiu o operador DNS e não descarta uma conta comprometida. Uma cadeia DNSSEC já existente pode autenticar parte da manutenção. O primeiro estabelecimento precisa de soluções como o RFC 9615, pois ainda não há DS no pai. Controles de registro, registrador e registrante continuam fora da comparação.

Uma escrita bem-sucedida no pai tampouco significa que todos os resolvedores enxergam o novo estado. Caches preservam DS e delegação anteriores até o TTL expirar. Avançar cedo demais na rotação pode causar falha depois de uma publicação correta. Por isso o RFC 10026 trata tempo, validação, reversão e relatório como tarefas próprias.

Se os operadores do filho não conseguem publicar uma visão comum, o RFC 9975 preserva um caminho autenticado fora de banda. Não é uma brecha; é outra fonte de autoridade. Uma disputa entre provedores não pode ser resolvida tecnicamente dando o comando ao primeiro servidor alcançável.

Autoria registra contribuição, não domínio operacional

O RFC Editor identifica Peter Thomassen como único autor do RFC 9975. Seu perfil público no IETF o descreve, no período revisado, como fundador e diretor de tecnologia da deSEC, diretor-gerente da SSE, presidente do Domain Connect e secretário do DNSOP. Ele também coassinou os RFCs 9615, 9859 e 10026.

Esses dados estabelecem uma contribuição documentada à sequência de padrões. Não significam que Thomassen opere todos os agentes parentais, controle registros ou registradores, certifique implementações ou tenha causado um incidente. O texto especifica comportamento mínimo; somente a evidência implantada mostra quais endereços foram consultados e se o pai realmente ficou parado diante do conflito.

É a mesma separação do mecanismo: o nome do autor comprova contribuição, não poder sobre todo código; o nome de um servidor numa delegação indica fonte de evidência, não licença unilateral para reescrever o pai.

A saída correta é um recibo de decisão

O sistema deve guardar a delegação que definiu o escopo, endereços e origem do glue, horários e pontos de observação, cada resposta relevante ou NODATA, validação, comparações, tentativas, recuo e eventual exclusão por inacessibilidade permanente.

Depois registra a diferença projetada no pai, o teste de validação contínua, a decisão de abortar, preservar ou aplicar e o estado observado após publicação. Segredos de autenticação não pertencem ao recibo; fatos necessários para reproduzir a decisão, sim.

A especificação mínima é compartilhada: nenhum subconjunto inconsistente produz inferência capaz de mudar a delegação. Janelas de repetição, perspectivas alternativas, canais de relato e escolhas permitidas de resumo podem ser locais. O código em execução precisa demonstrar que o limite existe fora do documento.

Fontes