Resumo

  • A revisão 02 permite que o filho envie alterações exatas de NS, glue e DS ao pai por um DNS UPDATE comum, protegido por SIG(0) e encaminhado ao receptor descoberto via DSYNC.
  • A autoassinatura prova posse da chave privada, não mandato sobre a delegação. O receptor registra a KEY como known e só a promove a trusted depois de validar o método de bootstrap.
  • No novo bootstrap, a chave antiga continua confiável até a substituta ser validada. NOERROR posterior é recibo de aceite, não de publicação autoritativa nem de resolução observada.

O pedido inicial traz duas operações na mesma direção: apagar o conjunto KEY anterior e incluir uma KEY nova. A nova chave assina o próprio pedido. Isso basta para mostrar que o remetente controla a chave privada correspondente. Se bastasse também para autorizar a remoção, qualquer atacante poderia fabricar um par, iniciar a troca e derrubar a credencial válida antes de fracassar na verificação de autoridade.

draft-ietf-dnsop-delegation-mgmt-via-ddns-02 evita essa inversão com dois estados. Ao chegar, a chave é conhecida: pode ser identificada e sua prova de posse pode ser conferida. Ela só se torna confiável depois de um caminho independente, aceito pelo pai, validar o vínculo. A chave anterior não é removida durante a espera. O commit da substituição acontece depois da promoção.

O mecanismo está em debate atual. O DNSOP abriu a última chamada do grupo em 20 de agosto, com término indicado em 7 de setembro. Em 4 de setembro, um chair pediu mais manifestações positivas e comentários construtivos, pois ausência de objeção não bastava. Geoff Huston apoiou a publicação e avaliou o push como mais eficiente do que polling no pai. Johan Stenstam destacou o uso por filhos não assinados e informou sua posição ligada a uma implementação. Michael Richardson afirmou que conseguiria escrever código a partir do texto, mas pediu clareza sobre KEY versus DNSKEY, estados, algoritmos futuros e um diagrama da máquina.

São opiniões pessoais, não consenso, aprovação do IETF ou comprovação de interoperabilidade.

O transporte reaproveita padrões. RFC 2136 define o DNS UPDATE; RFC 2931 e RFC 3007 cobrem a assinatura SIG(0) da transação; RFC 9859 fornece a descoberta DSYNC. O UPDATE Receiver pode existir separado do primário do pai e alimentar um banco ou uma API de provisionamento. Assim, autenticar a mensagem não obriga a editar imediatamente a zona em execução.

O receptor restringe os RRsets, exige em regra uma chave confiável com o mesmo nome do filho e mantém os testes substantivos de CDS/CDNSKEY e CSYNC. Uma autorização alternativa que alcance vários filhos é possível apenas como decisão própria do receptor e amplia a responsabilidade. O remetente propõe a mudança exata; o pai continua decidindo se ela é admissível.

Os caminhos de bootstrap têm forças diferentes. Um filho assinado publica KEY no apex e oferece uma cadeia DNSSEC. Se o filho não é assinado, mas usa nameserver em uma zona assinada, o provedor pode publicar a KEY em um nome especial sob essa zona. O pai também pode validar manualmente.

Sem cadeia assinada, restam observações distribuídas. O receptor consulta o serviço autoritativo de lugares, tempos e transportes diferentes e compara o resultado com a KEY recebida. A diversidade dificulta interceptação, mas não prova titularidade. O rascunho limita o significado: autentica o operador atual dos servidores autoritativos, não o registrante, e não pode ser mais forte que esses servidores.

O tipo do registro precisa permanecer visível. SIG(0) usa KEY, não DNSKEY. DNSKEY pertence às assinaturas de zona DNSSEC; a KEY aqui valida uma transação. Juntar ambas como “chaves DNS” mascara custódia, rotação, resposta a comprometimento e escopo de autorização distintos.

Os retornos não terminam o processo. NOERROR informa que o receptor recebeu e aceitou o UPDATE, esperando-se uma alteração futura nos dados do pai. Não comprova execução do job, nova publicação, expiração de cache ou resolução. REFUSED pode ser política, rate limit ou configuração. BADKEY significa que falta a chave pública necessária, mas sozinho não descreve todos os estados do bootstrap. Sem resposta, nem sequer se sabe qual metade da ida e volta falhou.

Uma trilha defensável guarda descoberta e versão DSYNC, digest e precondições do UPDATE, identidade KEY, método de bootstrap, transições known e trusted, decisão e resposta assinada, transação de provisionamento, serial do pai, RRset autoritativo, visões de resolvers depois dos TTLs e só então o resultado de serviço.

Na linguagem de Heng Lu, cada registro é autoridade apenas sobre a realidade estreita que observou. Chave conhecida não significa autoridade estabelecida. Texto publicado não significa adoção. Pedido aceito não significa estado público. Separar essas camadas permite automatizar sem transformar uma prova válida de posse em poder que ela nunca demonstrou.

Fontes