Resumo

  • O draft-ietf-dnsop-delegation-mgmt-via-ddns-02 propõe que o filho envie ao pai alterações exatas de NS, glue ou DS por DNS UPDATE assinado com SIG(0), usando DSYNC para localizar o receptor.
  • O pedido inicial de bootstrap é autoassinado. Ele prova posse da chave privada oferecida, não autorização para governar o filho. O receptor deve registrar a chave como known e só torná-la trusted após uma validação separada.
  • Um recibo de transição de autoridade deve ligar chave anterior, método de bootstrap, evidência independente, decisão de política, aceitação e publicação no pai. Essa é uma recomendação deste artigo, não um requisito do DNSOP.

O pedido de bootstrap tem aparência de uma troca completa: ele apresenta uma chave pública e traz uma assinatura válida feita pela chave privada correspondente. Mas a circularidade é evidente. Qualquer agente consegue criar um par de chaves e demonstrar que controla a metade secreta. O que não consegue demonstrar sozinho é que o titular do domínio, o operador DNS autorizado ou a estrutura registral lhe delegou poder.

A revisão 02 de Automating DNS Delegation Management via DDNS foi publicada em 17 de junho de 2026. Trata-se de um Internet-Draft ativo do grupo DNSOP, sujeito a mudança, substituição ou expiração. O cabeçalho renderizado diz Standards Track; o resumo do Datatracker não informa um status RFC pretendido. Não é um RFC, nem sua publicação comprova adoção por qualquer registro.

O problema operacional é concreto. Informações de delegação deveriam permanecer sincronizadas entre filho e pai: NS, eventuais registros de glue e DS. Uma divergência pode deixar o domínio funcionando por um caminho remanescente e esconder a perda de redundância. Quando esse último caminho falha, o efeito pode parecer súbito embora a preparação para a falha seja antiga.

Scanners de CDS e CSYNC permitem que o pai procure sinais nos filhos, mas trazem custo e atraso. A proposta faz o filho, que já conhece sua própria alteração, calcular o delta e enviá-lo por DNS UPDATE seguro. Um registro DSYNC anuncia onde o pai aceita esse tipo de mensagem. A solução reduz varredura e também pode atender filhos não assinados.

A eficiência transfere trabalho para quem detecta primeiro a mudança. Ela não transfere automaticamente autoridade.

A assinatura protege a mensagem; o bootstrap institui o signatário

DNS UPDATE não é só um aviso. Ele carrega exatamente os registros que o remetente deseja adicionar ou remover. SIG(0) protege a transação e permite verificar a posse de uma chave privada em relação a uma chave pública já aceita.

Na primeira interação, porém, essa aceitação é o objeto da decisão. O rascunho distingue força criptográfica e modelo de confiança. Um algoritmo SIG(0) pode ser tão resistente quanto um algoritmo DNSSEC, mas sua chave não vem necessariamente encadeada a uma âncora. Ela é confiada de forma individual depois do bootstrap.

Por isso, o UPDATE Receiver deve funcionar como ponto de política. Pode ser separado do servidor primário, operado pelo pai ou por um terceiro, como um registrador. Deve limitar nomes e tipos de registro, executar as verificações aplicáveis a CDS e CSYNC, manter auditoria e entregar a mudança aprovada ao sistema de provisionamento. Verificar uma assinatura não obriga o pai a publicar.

A regra comum exige que um UPDATE de child.parent. seja assinado por uma chave confiável com esse mesmo nome. Isso evita que a chave de um filho modifique outro. Se o receptor aceitar uma chave de registrador capaz de agir por muitos filhos, assume o dever de autorizar cada alteração por outro meio. Uma credencial mais ampla economiza integração e aumenta o raio de comprometimento.

Known conserva a dúvida necessária

O bootstrap autoassinado pode pedir a remoção do conjunto de chaves anterior e a inclusão da nova. Se a assinatura confere, o receptor aprendeu uma chave: estado known. Ainda precisa validar por uma rota aceita para chegar a trusted.

A chave antiga não pode ser removida antes do sucesso da substituta. Se a validação falhar, a nova permanece fora do conjunto confiável e a antiga continua válida. Essa ordem impede que uma proposta falsa cause dano antes mesmo de ser rejeitada. Sem ela, bastaria enviar uma chave qualquer para desalojar a autoridade legítima.

O estado intermediário precisa sobreviver no banco, na interface e no log. “Recebida”, “em validação”, “validação falhou”, “confiável” e “revogada” são condições diferentes. Um único campo de chave ativa apaga a decisão que interessa ao auditor.

Cada método reconhece um tipo de autoridade

Em um filho assinado, a chave SIG(0) pode ser publicada no ápice e validada por DNSSEC. Se o filho não é assinado, mas um servidor autoritativo está em zona assinada, o operador desse servidor pode republicar a chave sob um nome específico. O pai ganha uma cadeia verificável, ao custo de uma coordenação com o provedor DNS que permanece fora do escopo detalhado.

Para o filho inteiramente não assinado, o método unsigned compara o KEY obtido de vários pontos da rede, em momentos distintos e, quando possível, por transportes diferentes. A consistência reduz a chance de uma interceptação passageira. Não identifica o registrante. O próprio texto diz que autentica o operador atual dos servidores autoritativos, não o titular, e é o método automático mais fraco.

O modo manual pode recorrer a portal, formulário ou canal fora da banda. “Manual” tampouco define garantia. O valor depende de qual papel foi verificado, contra qual registro, com que desafio, recuperação e aprovação de exceção.

Antes de escolher o método, o pai deveria nomear o principal: titular, operador DNS, administrador da conta ou controlador da zona assinada. Esses papéis podem coincidir, mas não são equivalentes por definição.

A lista de métodos pode sofrer downgrade

No alvo DSYNC, um SVCB pode anunciar at-apex, at-ns, unsigned e manual no parâmetro bootstrap. O filho descobre o que o receptor suporta e escolhe uma opção possível.

Se o anúncio não for protegido, um atacante pode esconder a via forte e induzir a escolha da fraca. Por isso o rascunho recomenda assinatura DNSSEC do SVCB onde houver suporte e preferência pela alternativa mais forte que o filho consiga cumprir.

O registro de auditoria precisa guardar o conjunto anunciado, a validação desse anúncio, as capacidades do filho e a regra de escolha. Anotar apenas “bootstrap unsigned concluído” não revela se houve manipulação anterior da escolha.

Aceito ainda não significa publicado

Depois que a chave se torna confiável, cada UPDATE passa por escopo, correção e política. A resposta NOERROR confirma recebimento e aceitação. A formulação do rascunho diz que a alteração deve ser esperada na zona pai futuramente. Existe, portanto, um intervalo de provisionamento.

Em migração de servidores, encerrar a infraestrutura antiga logo após a resposta pode causar indisponibilidade se o pai ainda publica o NS anterior. Em DNSSEC, supor que o DS já está visível pode provocar falha de validação. O controle deve observar quatro marcos: chave conhecida, chave confiável, UPDATE aceito e RRsets publicados.

Os erros também pedem distinção. BADKEY pode indicar chave desconhecida. Uma chave conhecida pode estar aguardando validação ou ter falhado. Um pedido assinado corretamente pode ser recusado por política. Um pedido aceito pode ficar preso no provisionamento. Cada caso tem responsável e reparo próprios.

Há ainda autenticação na volta. O filho precisa confiar na chave do Receiver para automatizar respostas sobre estado da chave. Sem isso, uma resposta forjada pode disparar rebootstrap desnecessário. Não autoriza uma mutação, mas cria perturbação.

Um recibo para a passagem de poder

Proponho um recibo de transição de autoridade para cada bootstrap e rebootstrap. Não é uma exigência técnica nova do IETF. É uma forma de preservar por que o receptor alterou o estado de uma credencial.

O recibo identifica pai, filho, Receiver, resposta DSYNC e sua validação, versões de software e política, impressões das chaves antiga e proposta, resumo do UPDATE autoassinado e janela temporal. Registra todos os métodos anunciados, quais o filho poderia usar e por que um deles foi selecionado.

Na rota DNSSEC, conserva nomes consultados, cadeia, horário e resultado. Em unsigned, lista pontos de observação realmente independentes, tempos, transportes, respostas completas e teste de consistência. No manual, referencia sessão autenticada, papel conferido, desafio, aprovador, recuperação e exceções sem expor dados pessoais.

Os eventos known, início da validação, falha, trusted, substituição e revogação têm atores e horários próprios. A continuidade da chave anterior até o sucesso fica demonstrada. O UPDATE operacional liga chave, delta NS/glue/DS, verificações, política, resposta e tarefa de provisionamento. A última etapa registra quando o estado apareceu nos servidores autoritativos do pai.

O protocolo pode acelerar a convergência sem fingir que autoridade nasce da matemática. A chave prova que alguém a segura. O recibo mostra por que esse alguém passou a mandar.

Fontes

  1. Automação da gestão de delegações DNS via DDNS — revisão 02
  2. Registro do rascunho no Datatracker
  3. Histórico do rascunho
  4. Documentos do DNSOP
  5. Grupo de trabalho DNSOP
  6. RFC 9859 — Notificações DNS generalizadas
  7. RFC 2136 — Atualizações dinâmicas no DNS
  8. RFC 2931 — Assinaturas de requisição e transação DNS
  9. RFC 3007 — Atualização dinâmica segura
  10. RFC 8078 — Gestão de DS pelo pai via CDS/CDNSKEY
  11. RFC 7477 — Sincronização de filho para pai
  12. The Policy Mirror