Resumo

  • A revisão 05 de DNSSEC automation é um Internet-Draft ativo do DNSOP, não RFC, prova de implantação ou relato de migração.
  • Ela combina o modelo 2 multiassinante com CDS/CDNSKEY e CSYNC para ordenar entrada, saída e rotação de chaves sem concentrar as chaves privadas.
  • Sinal do filho, aceitação do pai, publicação autoritativa e observação pelo resolvedor são estados separados. A espera só pode partir do estado que pretende proteger.
  • Sincronização do conteúdo comum da zona está fora do escopo. Infraestrutura convergente não prova respostas de aplicação equivalentes.

O pedido não assina o resultado

CSYNC oferece ao filho uma forma estruturada de indicar ao pai o NS e, quando necessário, os endereços de glue desejados. No procedimento multiassinante, os participantes compilam um conjunto NS comum e publicam o sinal quando a delegação do pai difere.

Esse registro é evidência da intenção publicada pelo filho. O pai ainda precisa descobrir o sinal, validar as condições aplicáveis, aceitar conforme sua política, alterar sua zona e servir a nova delegação. Uma notificação pode reduzir a demora. Um protocolo de registro pode devolver sucesso. Nenhum deles substitui a resposta autoritativa da zona pai.

Se NS-Wait-Time começa na emissão de CSYNC, o relógio consome tempo antes de existir o estado que deveria propagar. Ao fim, o painel pode dizer que o TTL venceu embora o pai tenha publicado há poucos minutos — ou nem tenha publicado.

O início defensável registra o RRset do pai, o ponto autoritativo consultado, hora, TTL, validação e política. Depois calcula o limite e volta a observar. A automação não deve preencher uma lacuna de observação com a hora do ticket.

Cada espera protege uma exposição

DS-Wait-Time começa depois que o pai publica o DS combinado e protege caches que ainda carregam o vínculo de confiança anterior. CDS/CDNSKEY é o pedido da criança; DS é o estado controlado pelo pai.

DNSKEY-Wait-Time começa quando todos os signatários e suas secundárias publicam a vista pretendida de chaves. O limite inclui o maior TTL DNSKEY e o tempo de publicação. Uma alteração local não confirma o restante do conjunto.

NS-Wait-Time começa após a delegação nova no pai e considera os TTL do pai e dos signatários. Ele protege a possibilidade de consultas continuarem alcançando uma autoridade antiga.

RRSIG-Wait-Time começa quando uma chave deixa de produzir assinaturas. A chave pública precisa permanecer enquanto dados antigos assinados podem estar em cache. Concluir o job de rotação não expira o RRSIG.

Todos são durações, mas não o mesmo controle. Guardar início, objeto e responsável evita que uma barra de progresso esconda qual pré-condição faltou.

Entrar no grupo distribui obrigações

No modelo 2, cada provedor mantém KSK/ZSK ou CSK próprios. Ao entrar, o novo signatário precisa servir uma zona assinada funcional, usar algoritmos compatíveis e distinguir suas chaves das chaves externas. Os demais adicionam a chave pública de assinatura de dados à própria vista DNSKEY.

O grupo calcula CDS/CDNSKEY para todos os KSK/CSK e espera o pai publicar o DS combinado. Só então consolida NS, sinaliza a projeção parental e protege o novo caminho. Um signatário correto não prova o grupo correto; todos devem mostrar a mesma intenção.

O inventário deve atribuir origem a cada chave e NS. Sem isso, a saída futura não consegue separar material local, estrangeiro e órfão. A entrada também precisa registrar quem paga o período de sobreposição, quem pode impedir o avanço e qual evidência libera cada participante.

Sair exige preservar o que ainda pode validar

Para retirar um signatário, os participantes restantes removem seu NS, o pai publica a delegação reduzida e o grupo espera a exposição NS. Depois o antigo provedor pode parar de responder. A seguir, o grupo prepara CDS/CDNSKEY sem sua chave, espera a exposição das assinaturas antigas e só então remove o DNSKEY estrangeiro.

Há duas superfícies: alcance ao servidor e validade de dados já assinados. NS-Wait-Time e RRSIG-Wait-Time não são alternativas. Uma data contratual que desliga ambos de uma vez pode quebrar o procedimento.

O recibo de saída identifica a última geração servida, a última assinatura por chave, a publicação parental sem o NS, o limite de cada cache e a observação final sem a chave. Encerrar a conta comercial não fornece esses fatos.

As chaves podem concordar e os dados discordar

O documento exclui a sincronização de conteúdo geral da zona. Ele coordena registros de infraestrutura; não define como dados de aplicação chegam a todos os provedores.

Assim, autoridades podem publicar DNSKEY idênticos e devolver A, MX ou negações diferentes. As respostas podem validar corretamente. DNSSEC autentica a resposta recebida, mas não escolhe qual geração exprime a intenção mais recente do proprietário.

O plano precisa de um segundo recibo: transferência autorizada, geração ou SOA esperado, comparação de conteúdo, política de assinatura e consultas a cada autoridade. “Grupo formado” e “zona convergente” devem permanecer estados distintos.

Centralização e descentralização mudam o erro

Um controlador central calcula os intervalos e altera todos os signatários. Produz um diário comum, mas concentra credenciais e interpretação. Uma observação obsoleta avança todo o grupo.

No modelo descentralizado, cada signatário recebe dados e cumpre as restrições. Participantes podem, porém, ter TTL, membresia ou observações do pai diferentes. Um cálculo local correto com entrada antiga ainda gera uma decisão coletiva insegura.

O “mecanismo de confiança” usado para modificar DNSKEY, CDS/CDNSKEY, CSYNC e NS não é detalhado pela proposta. Precisa de principal, escopo por zona e tipo, aprovação, rotação e revogação. Canal autenticado não é autorização genérica.

O status do documento limita a linguagem pública

Na data congelada, Datatracker mostra a revisão 05 ativa no DNSOP e aguardando autorização da presidência. A ficha indica destino Informational, enquanto o cabeçalho diz Standards Track. O texto expira em 6 de janeiro de 2027.

A divergência deve ser preservada, não resolvida em favor do rótulo mais forte. Nada disso comprova RFC, suporte, adoção ou interoperabilidade. Nenhuma fonte prova provedor, zona, transição, incidente ou desempenho nomeados. O caso inicial é analítico.

Um diário mantém a cadeia observável

Cada linha deve registrar zona, geração do grupo, participante, objeto, hash esperado e visto, autoridade consultada, TTL, hora, validação, política, instante mínimo da próxima ação e principal aprovador. Intenção do filho, decisão do pai, publicação, horizonte de cache, observação do resolvedor e resultado da aplicação ficam separados.

Desconhecido não vira sucesso. Sem hora de publicação das secundárias, o início DNSKEY é incerto. Sem resposta da zona pai, a confirmação de processo não inicia NS ou DS. Sem integração do plano de dados, o estado final deve dizer conteúdo não verificado.

A promessa sustentável é modesta: ordenar ações e impor esperas mínimas para uma transição DNSSEC multiassinante. Estado global de caches, conteúdo e serviço requer seus próprios observadores.

Fontes