Resumo

  • A revisão 02 de Automating DNS Delegation Management via DDNS é um Internet-Draft ativo do DNSOP, não um RFC nem prova de adoção.
  • O filho descobre um UPDATE Receiver com DSYNC e assina a solicitação com SIG(0), mas a autoassinatura só prova posse; o pai decide como a chave se torna confiável e qual escopo ela recebe.
  • Mesmo depois da autenticação e das verificações de política, NOERROR comprova recebimento e aceitação. O texto deixa a publicação na zona pai para algum momento futuro.
  • Uma retirada segura depende de recibos distintos para intenção, bootstrap, autorização, aceitação, provisionamento, publicação autoritativa, exposição em cache e efeito na aplicação.

O primeiro recibo não é de autoridade

No bootstrap inicial, o filho envia uma KEY em uma atualização autoassinada. Se a assinatura valida, o receptor sabe que o remetente controla a chave privada apresentada. Esse fato não identifica automaticamente o titular nem concede poder sobre a delegação.

Por isso a chave entra como conhecida, não como confiável. A promoção exige validação por um método aceito pelo pai: KEY no ápice de uma zona filha assinada, publicação sob o nome de um nameserver em zona assinada, ou verificação manual. Cada método cria uma origem de confiança diferente.

O caminho não assinado é o mais fraco. Ele autentica o operador atual dos servidores autoritativos, não o registrante. Em uma disputa, terceirização ou comprometimento do provedor, essa diferença define quem o sistema tratou como autoridade.

O recibo deve guardar método anunciado, método escolhido, estado DNSSEC, observações, aprovação manual e instante da promoção. Uma linha “SIG(0) válido” apaga o passo em que o pai converteu posse técnica em autorização operacional.

Trocar a chave sem destruir a última boa

No rebootstrap, a nova solicitação pode pedir a remoção do conjunto KEY anterior. O receptor não pode executar essa exclusão antes de validar a substituta. Caso contrário, uma candidata autoassinada e inválida poderia expulsar a chave legítima sem jamais obter confiança.

Essa regra revela o verdadeiro objeto de segurança: a continuidade da autoridade válida. Validar duas assinaturas isoladamente não basta; a ordem entre adicionar, validar, promover e remover precisa ser preservada.

BADKEY informa que o receptor não dispõe da chave necessária. Sozinho, o código não separa uma chave conhecida ainda em validação de uma chave cuja validação falhou. Os Extended DNS Errors propostos acrescentam estado, mas a decisão só é auditável quando ligada ao histórico do bootstrap.

Uma operação de emergência deve conseguir responder qual chave ainda era confiável, qual candidata foi apresentada, quem autorizou o método e por que a substituição avançou. Sem isso, recuperação vira nova atribuição de poder no escuro.

DSYNC descobre o caminho, não concede o comando

O DSYNC de RFC 9859 indica o endpoint usado para sincronização. A descoberta reduz configuração bilateral e evita varredura desnecessária. Ainda assim, encontrar o receptor não autentica cada resposta nem autoriza qualquer filho a alterar qualquer nome.

A regra padrão exige uma chave SIG(0) confiável cujo nome seja exatamente o nome do filho. Assim, a chave de um filho não muda a delegação de outro. Se o pai aceita uma chave de registrador com alcance amplo, assume a obrigação de autorizar cada mudança por controles adicionais.

Depois da assinatura e do escopo, o receptor executa as verificações que um scanner CDS/CDNSKEY ou CSYNC faria. Política, trilha de auditoria, rate limit e integração com o sistema de provisionamento continuam sob responsabilidade do pai.

O ganho de escala vem de o filho anunciar a mudança quando ela ocorre, em vez de o pai consultar milhões de zonas periodicamente. É deslocamento de trabalho, não transferência do poder final de publicação.

NOERROR ainda fala do futuro

A formulação da revisão 02 é direta: NOERROR confirma que a atualização foi recebida e aceita; a mudança deve ser publicada nos dados do pai em algum momento futuro. O futuro é parte da semântica.

O Receiver pode gravar uma base, chamar uma API ou alimentar um gerador. O primário precisa carregar uma geração, e os secundários precisam recebê-la. Um deles pode continuar servindo o conjunto antigo. Depois, caches recursivos podem manter respostas anteriores dentro do TTL.

Assim, fechar o ticket no NOERROR transforma aceitação em fato público. Em uma troca de NS, essa compressão pode desligar o provedor antigo enquanto parte da autoridade pai ainda o anuncia. Em uma troca de DS, pode eliminar a recuperação antes de a cadeia pública estabilizar.

O recibo seguinte vem da observação autoritativa. Ele nomeia o servidor, endereço, horário, RRset, TTL, validação e geração. Respostas diferentes significam publicação parcial. A equipe deve conservar a rota antiga e investigar a distribuição, não escolher a resposta mais conveniente.

A resposta do pai também precisa ser autenticada

Assinar a solicitação não torna a resposta autêntica. O UPDATE Receiver pode manter sua própria chave SIG(0), assinar respostas e publicar a chave. O filho precisa validá-la pela DNSSEC do pai ou por bootstrap manual.

Sem essa confiança inversa, uma resposta forjada pode afirmar que a chave do filho é desconhecida e acionar rebootstrap desnecessário. O atacante não consegue autorizar a mutação no pai, mas pode causar interrupção, rotação e tempestade operacional.

O registro precisa conter presença da assinatura, impressão da chave do Receiver, caminho de confiança, RCODE, EDE e geração da solicitação. “Recebi uma resposta” é mais fraco do que “o receptor esperado emitiu esta declaração autenticada”.

Mesmo a segunda frase permanece limitada. Autenticidade prova autoria da resposta; não amplia NOERROR até a zona publicada.

Silêncio não significa ausência de efeito

Quando não há resposta, a solicitação pode ter se perdido, a resposta pode ter se perdido depois da aceitação ou o serviço pode estar indisponível. O remetente não sabe qual estado ocorreu.

O texto recomenda timeout mínimo, backoff exponencial e até cinco tentativas por atualização como padrão. Isso limita carga. Não certifica que nenhuma alteração aconteceu.

Cada tentativa deve carregar uma geração de intenção. Uma solicitação antiga não pode reaparecer depois de uma decisão nova e restaurar glue ou NS obsoletos. Os tempos de validade do SIG(0) limitam replay, mas não escolhem a intenção vigente entre mensagens legítimas.

Antes de reenviar, observe a autoridade pai. Se ela já corresponde ao estado desejado, a resposta perdida não deve produzir outra mutação. Se as autoridades discordam, o problema é de publicação ou transferência e precisa ser tratado como tal.

Publicação, cache e aplicação são planos diferentes

Uma mudança no primário não prova que todos os secundários a servem. Convergência autoritativa não prova que cada resolver abandonou a resposta antiga. Uma resposta DNS correta não prova que o serviço de aplicação funciona.

Para o cache, o operador registra o TTL do estado anterior e calcula uma exposição máxima a partir de um início observado. Isso permite uma inferência limitada; não enumera todos os caches. Amostras independentes mostram resultados representativos sem prometer universalidade.

Para a aplicação, sondas podem demonstrar continuidade ou falha. Devem aparecer ao lado do DNS, não substituir o DNS. Um serviço pode funcionar por rota antiga enquanto a mudança ainda não foi publicada, ou falhar depois de uma delegação correta por motivo não relacionado.

A retirada do caminho antigo só ocorre quando os recibos necessários fecham. Uma data comercial não altera a realidade do pai. A liderança precisa nomear quem pode estender a sobreposição e assumir custo quando o estado técnico não está pronto.

O estado do documento limita o artigo

No congelamento, a revisão 02 era datada de 17 de junho de 2026, atualizada no Datatracker em 25 de setembro e expirava em 19 de dezembro. O estado de grupo era Waiting for WG Chair Go-Ahead Other - see Comment Log; o estado IESG era I-D Exists.

O Datatracker não mostrava intended RFC status; o cabeçalho dizia Standards Track. A divergência fica registrada. Valores pedidos à IANA e exemplos permanecem propostas, não alocações finais.

Nenhuma fonte prova implantação por registro, registrador, TLD ou operador específico. A abertura é construída para mostrar a fronteira de autoridade. Não é relato de incidente.

Um grafo de recibos é mais útil que “concluído”

O grafo começa com intenção, geração anterior, RRsets desejados e aprovador. Acrescenta DSYNC, confiança nas duas chaves, escopo de nome, verificações, política e resposta. Depois continua com job, geração do pai, secundários, consultas autoritativas, horizonte de cache, resolvers e aplicação.

Cada aresta tem dono, horário, entradas, saída e hash. Desconhecido não vira sucesso por padrão. A equipe pode então suspender retirada, evitar replay, preservar a última chave boa e encaminhar a falha ao proprietário correto.

A afirmação final é propositalmente estreita: SIG(0) pode autenticar uma solicitação limitada e NOERROR pode comprovar aceitação pelo Receiver. A publicação no pai precisa ser vista no pai.

Fontes