Resumo

  • O draft-ietf-dnsop-dnssec-keyrestore-02 trata do caso em que uma chave privada fica inoperante, sem backup utilizável, enquanto uma zona pré-assinada completa e assinaturas ainda válidas permanecem disponíveis.
  • A restauração segura depende de relógios distintos: validade de RRSIG, propagação de DNSKEY, publicação do DS no pai, carregamento dos secundários e expiração dos caches. Nenhum signatário encerra tudo sozinho.
  • Um recibo dos relógios de recuperação deveria atribuir autoridade, cálculo e evidência a cada transição. Essa é uma proposta de Daniel Kade, não uma exigência da IETF.

Uma consulta bem-sucedida pode ser a fotografia de um sistema que perdeu a capacidade de avançar. Enquanto DNSKEY e RRSIG antigos formam uma combinação válida, o usuário recebe resposta normal. Se o operador precisar trocar um endereço, retirar um serviço comprometido ou corrigir o roteamento de e-mail, a ausência da chave privada passa a bloquear a próxima versão da zona.

A revisão 02 de DNSSEC Key Restore foi publicada em 10 de agosto de 2026. Trata-se de um Internet-Draft ativo do grupo DNSOP, com intenção Informational no documento renderizado. Continua sujeito a mudança, substituição ou expiração; não é RFC, BCP nem promessa operacional da RIPE NCC, afiliação dos autores. O escopo abrange zonas pré-assinadas. Assinatura online e zona raiz ficam de fora.

O rascunho também limita a palavra “restauração”. Sem cópia útil, a chave privada perdida não reaparece. O que se restaura é a função de assinatura, com novo material, preservando as chaves públicas e assinaturas antigas até que deixem de ser necessárias à validação.

A chave falhou; o estado publicado ainda não

Uma chave privada inoperable é aquela que não consegue mais assinar. Falha de hardware, desastre, erro humano e ação maliciosa podem produzir o estado. Uma chave comprometida que ainda assina é outra categoria. Nesse caso existe risco de uso pelo adversário; na inoperância, o primeiro problema é a continuidade. O diagnóstico orienta quais exceções são aceitáveis.

No instante da falha, a zona pode continuar corretamente assinada e servida. RRSIG frequentemente têm validade restante de dias, mas essa frequência não cria SLA. O prazo real depende das datas de cada assinatura, dos RRsets publicados e das combinações guardadas por validadores. A menor margem observada, e não a duração padrão configurada, governa o incidente.

O perigo da pressa é remover material ainda necessário. O software não deve apagar a DNSKEY pública só porque não encontra a parte privada. As assinaturas antigas devem permanecer; uma ferramenta que as remova pode obrigar o operador a recolocá-las manualmente. A chave não produz mais futuro, mas ainda autentica o presente.

Na perda de ZSK, propagação e TTL determinam o passo

Se a ZSK falha e a KSK permanece operante, uma nova ZSK pode ser inserida no conjunto DNSKEY, assinado pela KSK existente. A aparição no primário não torna a nova chave pronta. É necessário esperar a propagação autoritativa e o TTL de DNSKEY: Ipub = Dprp + TTLkey.

Depois a nova ZSK assina a zona. A antiga continua publicada durante a conclusão da assinatura, a propagação e a saída dos RRSIG velhos dos caches. O rascunho representa esse período como Iret = Dsgn + Dprp + TTLsig. Falha, publicação, prontidão, ativação e remoção segura são eventos diferentes.

As atas da IETF 126 registram que perder apenas a ZSK não elimina a continuidade. A observação não significa que a operação esteja normal. A zona pode continuar validando enquanto permanece incapaz de aceitar mudanças com segurança.

Na perda de KSK, o pai entra no caminho crítico

Uma KSK substituta precisa de um DS na zona-pai. A sequência Double-DS começa com o envio do novo DS, passa pelo registro e publicação no pai, espera a propagação e o TTL do DS e só então ativa a nova KSK no filho.

A publicação segue Tpub = Tsbm + Dreg. A prontidão acrescenta IpubP = DprpP + TTLds. RFC 7583 já observa que o cronograma de KSK com participação do pai não está inteiramente sob controle do gerente da zona. Um protocolo local mais rápido não reduz o tempo do registro nem esvazia o cache de um resolvedor.

“Recebido”, “aceito” e “publicado” precisam ficar em campos separados. A presença do DS em uma instância tampouco prova que todos os autoritativos e caches atravessaram o horizonte seguro.

Quando uma CSK fica inoperante, a dependência é dupla. A mesma chave atendia o conjunto DNSKEY e os dados da zona. O novo DS precisa atravessar o pai, e a assinatura da zona precisa ser reconstruída. O intervalo de retirada inclui o tempo de assinatura, a propagação no filho e o maior valor entre os TTL de DNSKEY e RRSIG.

A exceção manual reabre a questão de mandato

CDS e CDNSKEY permitem automatizar a manutenção do DS em situação saudável. Com ZSK ou CSK inoperante, os novos registros que solicitariam a mudança não podem receber a autenticação habitual. A revisão 02 leva o caso para uma atualização manual no pai.

Esse desvio precisa de mais evidência, não de menos. O provedor DNS pode controlar a conta operacional; o registrador, a relação com o cliente; o registro ou operador do pai, a escrita final. É necessário provar quem fala pelo filho, quem conferiu a nova chave, quem autorizou a exceção e quem observou o DS efetivamente publicado.

Os servidores secundários formam outra fronteira. Para evitar alterar um SOA que a chave antiga não consegue assinar novamente, o operador pode manter o SOA intacto ao introduzir a DNSKEY. Sem a mudança, o fluxo normal de IXFR ou AXFR talvez não carregue a nova zona. Cada secundário pode exigir carga forçada. Uma resposta correta do primário não representa toda a infraestrutura autoritativa.

A mudança de DNSKEY também invalida o digest ZONEMD existente. Um novo digest precisa ser calculado e assinado. A seção sobre Knot DNS informa que o procedimento testado não suporta a geração manual desse novo digest. É uma restrição concreta do exemplo, não prova de cobertura entre fornecedores.

Na IETF 126, participantes pediram comparação mais detalhada entre TTL e expiração das assinaturas, além de evidência de implementação. O apresentador relatou funcionamento com Knot DNS; o chair solicitou uma seção de implementação. O registro sustenta experiência limitada, não adoção generalizada.

O recibo dos relógios

O recibo proposto começa com a classificação do incidente, a função da chave e a expiração mais próxima entre as assinaturas realmente servidas. Em seguida demonstra que DNSKEY e RRSIG antigos foram preservados, registra a nova chave em cada instância autoritativa e expõe os valores de propagação e TTL usados no cálculo.

Nos casos de KSK e CSK, envio ao pai, autenticação, aceitação, publicação observada e fim do horizonte de cache ocupam etapas distintas. Nos secundários, o documento lista cada carga forçada e o conteúdo visto depois dela. Para ZONEMD, informa o novo digest ou a autoridade que aprovou uma exceção temporária.

A nova assinatura concluída não encerra automaticamente o caso. O recibo guarda uma amostra de RRsets recém-assinados, calcula a primeira hora segura para retirar DNSKEY, DS e RRSIG antigos e registra a remoção efetiva à parte. Toda ação manual tem responsável e caminho de correção.

Não se publica segredo: chave privada, configuração de HSM e dados pessoais continuam protegidos. Hashes de artefatos, key tags, horários, versões de política, RRsets observados e papéis institucionais permitem auditoria sem expor o ambiente criptográfico.

Também não se promete observar todos os caches. TTLs oferecem limites conservadores; sondas em vários pontos oferecem amostras. Manter Dprp, TTLkey, TTLds, TTLsig e Dsgn permite revisar a decisão. Um painel verde sem as entradas não permite.

O rascunho entrega um caminho técnico para usar assinaturas sobreviventes sem transformar voluntariamente a zona em insegura ou bogus. Não entrega tempo universal de recuperação, SLA do pai, censo de resolvers nem formato de auditoria. O resultado de governança é que a validade restante constitui um orçamento compartilhado. Cada ator precisa responder pelo relógio que consegue mover e pela prova entregue ao próximo.

Fontes

  1. DNSSEC Key Restore — revisão 02
  2. Registro do documento no Datatracker
  3. Histórico do documento
  4. Atas de DNSOP na IETF 126
  5. Documentos ativos do DNSOP
  6. Carta do DNSOP
  7. RFC 9364: DNS Security Extensions
  8. RFC 7583: tempos de rotação de chaves DNSSEC
  9. RFC 8078: manutenção de DS por CDS/CDNSKEY
  10. RFC 8976: digest de zonas DNS
  11. RFC 9499: terminologia DNS