Resumo

  • A troca DNSSEC percorre vários estados da chave; não cabe no horário de uma cerimônia.
  • Propagação autoritativa, expiração de cache, DS do pai e espera de âncora avançam em relógios diferentes.
  • O material antigo continua necessário enquanto alguma combinação plausível de validação depender dele.
  • Um registro operacional deve governar ativação, retirada e remoção.

Imagine uma cerimônia agendada que termina sem alertas. A nova DNSKEY aparece, o assinador produz assinaturas válidas e o painel registra sucesso. A equipe remove a chave antiga no horário previsto. Pouco depois, um grupo de clientes que usa resolvedores validadores passa a receber SERVFAIL, enquanto sondas próximas aos servidores autoritativos continuam normais.

A criptografia não mudou. O modelo operacional condensou vários relógios no relógio da cerimônia.

RFC 7583 descreve a troca como uma passagem temporal por estados como gerada, publicada, pronta, ativa, retirada, morta e removida. Uma chave pode estar visível sem estar pronta, ativa sem ser utilizável por todos os resolvedores ou retirada enquanto dados em cache ainda dependem dela. Segurança significa manter ao menos um caminho válido pelas combinações mutáveis de DNSKEY, RRSIG e, para KSK, DS.

O primeiro relógio é a propagação autoritativa. Publicar a nova chave no primário não a coloca instantaneamente em todos os servidores. A RFC 7583 inclui a demora de propagação no intervalo anterior ao estado pronto. RFC 6781 aplica a mesma disciplina à pré-publicação de ZSK: inserir a nova DNSKEY, permitir que alcance o conjunto autoritativo e mantê-la por um TTL de DNSKEY antes de assinar dados de produção.

O segundo relógio pertence aos caches. Um validador pode guardar um RRset DNSKEY antigo enquanto obtém uma RRSIG nova, ou manter uma assinatura antiga ao atualizar as chaves. O método precisa preservar combinações compatíveis. Na pré-publicação, a nova chave espera antes do uso e a antiga permanece depois da troca de assinaturas. Na assinatura dupla, as duas gerações se sobrepõem, com respostas maiores em troca de uma janela simples.

O terceiro relógio está na delegação do pai. Uma troca de ZSK pode ficar dentro da zona. Uma troca de KSK normalmente une a DNSKEY da filha ao DS publicado pelo pai. Enviar um DS ao registro não prova publicação no DNS. É preciso observar o novo DS, considerar o TTL do anterior e preservar o caminho existente até que o sucessor esteja estabelecido.

O quarto relógio vale para resolvedores que mantêm âncoras configuradas conforme a RFC 5011. Uma nova chave SEP entra em espera. O resolvedor aguarda o período de incorporação e, depois, recupera e valida outro RRset DNSKEY que ainda contenha a chave. O período é de trinta dias ou até a expiração do TTL original, o que for maior. Na retirada, uma âncora só entra no estado Removed depois das observações previstas de revogação ou ausência; seu estado fica retido por mais trinta dias antes da limpeza do registro interno. Essa retenção pertence ao estado da âncora no resolvedor e não autoriza, de forma genérica, excluir uma DNSKEY da zona. Esse relógio vive no validador e não está sob controle direto da zona.

Não são quatro cópias da mesma contagem regressiva. Cada relógio começa em um evento observado, pertence a um componente e comprova uma transição. “Nova chave publicada” não autoriza a ativação. Uma assinatura válida em uma sonda não autoriza a remoção da antecessora. Um recibo do portal do pai não fecha caches. A passagem de trinta dias não prova a nova recuperação exigida pela RFC 5011.

O objeto de evidência adequado é um registro operacional da troca. Ele identifica zona, método, tags e algoritmos; registra quando cada chave entra em cada estado; conserva observações DNSKEY, RRSIG e DS em pontos nomeados; documenta TTLs, limites de propagação e validade de assinatura; e separa envio, visibilidade nos servidores autoritativos e expiração de cache.

Para populações RFC 5011, o registro acrescenta o ponto de confiança, a primeira observação validada, o fim da espera e a observação posterior que conclui a aceitação. Para todas, preserva resultados por grupos representativos de resolvedores. Também nomeia quem pode avançar cada etapa e qual evidência aciona a reversão.

Assim, a declaração de conclusão fica precisa. “A cerimônia ocorreu” descreve uma ação de gestão. “A nova chave está ativa” descreve compatibilidade segundo o método escolhido. “A chave antiga pode ser removida” afirma que nenhum estado aplicável de cache ou âncora ainda depende dela. As datas podem ser próximas; as afirmações são distintas.

Fontes

RFC 7583 — temporização da troca de chaves DNSSEC; RFC 6781 — práticas operacionais DNSSEC; RFC 5011 — atualização automatizada de âncoras DNSSEC.