Resumo

  • Uma cópia completa da zona pré-assinada e RRSIGs ainda válidos preservam um estado verificável por tempo limitado. Eles não recuperam a chave privada nem provam que a próxima alteração poderá ser assinada.
  • O papel da chave define a transição: Pre-Publication para ZSK inoperante com KSK disponível; Double-DS para KSK inoperante; Double-DS ajustado, com retenção mais longa, para CSK inoperante.
  • A restauração funcional requer evidências separadas de publicação, prontidão, ativação e retirada, além de propagação do DS no pai, coerência de SOA/NSEC/NSEC3/ZONEMD, carga em cada autoritativo, validação por resolvedores independentes e continuidade de negócio.

A reserva que já estava na zona

Quando o último backup funcional de uma chave privada some, não há comando capaz de deduzir o segredo a partir da DNSKEY pública ou das assinaturas existentes. Ainda assim, o DNS pode continuar parecendo saudável. Uma zona pré-assinada carrega respostas e RRSIGs produzidos antes da perda. Enquanto essas assinaturas não expiram e a cadeia de confiança continua disponível, validadores podem aceitá-las sem que o assinador volte a usar a chave privada.

Essa é uma reserva operacional embutida no estado publicado. Ela compra tempo, não capacidade. Um servidor pode responder corretamente às 10h e a organização ainda ser incapaz de assinar uma mudança às 10h01. Um monitor que observa Secure mede a validade de uma resposta; não testa se a função de assinatura está viva.

O documento que trata diretamente dessa distinção é o draft-ietf-dnsop-dnssec-keyrestore-02. Na data desta verificação, ele é um Internet-Draft ativo do grupo de trabalho DNSOP, revisão 02, atualizado em 10 de agosto de 2026. Não é RFC. É trabalho em andamento, de status pretendido Informational, escrito por Florian Obser e Martin Pels. O escopo pressupõe uma cópia completa da zona assinada e arquiteturas com registros pré-assinados. Assinatura online não é coberta. A zona raiz também fica de fora, pois distribuir uma nova âncora de confiança pode levar mais tempo do que a vida das RRSIGs.

O texto chama uma chave de inoperante quando a parte privada de uma DNSKEY na cadeia de confiança já não consegue assinar. Isso não deve ser confundido com uma chave comprometida que ainda funciona: no segundo caso, existe risco de assinatura adversária e a prioridade de contenção muda. No primeiro, sem backup utilizável, a chave não volta. O objetivo é colocar uma nova chave em condição de assumir a função de assinatura.

O prazo diminui por três lados

A expiração de RRSIG é o limite mais evidente. Mas o tempo utilizável também depende dos TTLs remanescentes e do atraso de propagação entre todas as instâncias autoritativas. Um resolvedor pode ter DNSKEY antigo em cache, outro pode buscar o novo; um nó anycast pode ter carregado a zona, outro não; o DS pode ter sido publicado no pai sem ainda ter atravessado TTLds nos caches.

A terceira ameaça vem de dentro: uma operação precipitada. Excluir a DNSKEY antiga, descartar RRSIGs válidos ou mudar um RRset que a chave perdida não pode assinar encurta a janela. O assinador não deve remover DNSKEYs sem instrução explícita e deveria preservar as assinaturas antigas. Se o software não consegue mantê-las, todas as RRSIGs antigas, salvo a que cobre o antigo RRset DNSKEY, precisam ser recolocadas manualmente antes da publicação.

Também não é o momento de aproveitar a intervenção para mudar de algoritmo. A menos que esse rollover já estivesse em curso, a recuperação deve usar o algoritmo atual. A modernização vem depois, como operação normal. A razão é menos estética do que probatória: cada mudança adicional multiplica combinações de chave, assinatura e cache que precisam ser distinguidas.

Os estados de chave do RFC 7583 tornam essa disciplina mensurável. “Publicada”, “pronta”, “ativa” e “retirada” não são quatro maneiras de dizer “visível”. O RFC 6781, por sua vez, descreve os mecanismos de rollover que lidam com o tempo de propagação. A recuperação escolhe entre eles conforme a chave que deixou de assinar.

Caso 1: a ZSK parou, a KSK ainda assina

Em um desenho com chaves separadas, a perda da ZSK congela inicialmente os dados da zona. Uma mudança exigiria novas assinaturas que a chave antiga já não produz. Como a KSK continua operacional, ela ainda pode autenticar uma alteração no RRset DNSKEY. A saída é Pre-Publication.

No instante Tpub, a nova ZSK é acrescentada ao DNSKEY. A ZSK antiga, embora inoperante, continua publicada, e todas as RRSIGs antigas são preservadas. Em regra, o SOA não muda só para introduzir a chave. Os secundários precisam ser forçados a carregar o novo estado quando o fluxo normal não o detecta.

A observação da nova ZSK não autoriza seu uso imediato. Primeiro decorre Ipub = Dprp + TTLkey: o atraso de propagação para todas as instâncias autoritativas (Dprp) mais o TTL do DNSKEY (TTLkey). A chave está pronta em Trdy = Tpub + Ipub. Só então os dados podem mudar e receber assinaturas da nova ZSK.

Depois da ativação, as RRSIGs antigas podem sair, mas a ZSK antiga permanece no DNSKEY durante Iret = Dsgn + Dprp + TTLsig. Esse intervalo soma o atraso de assinatura, a propagação autoritativa e o TTL máximo das assinaturas. Uma alternativa Double-Signature seria mais lenta nessa emergência, porque a zona teria de permanecer imóvel por Dsgn + Dprp + max(TTLkey, TTLsig) antes de liberar os dados.

O ponto crítico é a origem do relógio: ele começa na publicação comprovada em todas as superfícies relevantes, não na gravação de um arquivo no primário. Por isso, recibos por instância e observações DNS fazem parte do procedimento, não são documentação posterior.

Caso 2: a KSK parou e o pai precisa abrir a ponte

Uma KSK inoperante não consegue assinar a inclusão de uma nova KSK no DNSKEY. O filho não tem como criar sozinho uma cadeia confiável para a substituta. Só Double-DS resolve. Se a ZSK também estiver inoperante, recupera-se primeiro a função KSK; a ZSK continua preservada até que a âncora nova esteja utilizável.

O novo DS é enviado ao pai em Tsbm. Há um atraso de registro Dreg até ele aparecer em Tpub. A aceitação pelo registrador ou registro é um evento administrativo; não é prova de publicação DNS. Depois de observar o DS nos autoritativos do pai, ainda se espera IpubP = DprpP + TTLds, cobrindo a propagação entre as instâncias do pai e o TTL do DS. A nova KSK fica pronta em Trdy = Tpub + IpubP.

Na ativação, a nova KSK entra no DNSKEY do filho e assina esse RRset. A KSK antiga pode sair dali; a ZSK continua. Se a ZSK estiver igualmente perdida, preserva-se o SOA, força-se a carga nos secundários e só então começa sua recuperação por Pre-Publication. O DS antigo deve permanecer no pai após a ativação por Iret = DprpC + TTLkey, protegendo resolvedores que ainda têm o DNSKEY antigo do filho. O primeiro instante de retirada é Trem = Tact + Iret.

CDS e CDNSKEY são úteis para automatizar a manutenção normal de DS, conforme o RFC 8078 e os mecanismos mais recentes do RFC 10026. Porém, eles não criam confiança por decreto durante a perda. Um CDS/CDNSKEY recém-inserido pode não ser validável se ZSK ou CSK não assina; a inclusão do novo tipo também muda o bitmap NSEC/NSEC3 do ápice, impossível de reassinar com a chave perdida. Uma atualização manual e autenticada no pai pode ser indispensável.

Caso 3: a CSK parou e os dois relógios viram um só risco

A CSK cobre tanto o DNSKEY quanto os dados da zona. Quando ela para, somam-se a dependência do DS pai e a incapacidade de assinar os dados. O caminho possível é um Double-DS ajustado. Publica-se o novo DS no pai, espera-se Dreg e depois IpubP = DprpP + TTLds antes da ativação no filho.

Na ativação, a nova CSK entra no DNSKEY e o assina. A CSK antiga e todas as RRSIGs antigas continuam publicadas. O SOA não deve ser alterado de modo inseguro, e todos os secundários devem carregar o estado. A retirada exige Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Somente em Trem = Tact + Iret o DS antigo, a CSK antiga e as assinaturas antigas podem sair juntos, permitindo retomar alterações normais.

Esse “juntos” é uma proteção contra caches cruzados. Alguns resolvedores terão DS novo e DNSKEY antigo; outros, combinações inversas dentro dos limites de TTL. Manter os dois caminhos durante o máximo relevante reduz a chance de que uma combinação legítima fique sem assinatura verificável.

O SOA preservado muda a forma de distribuir a zona

Ao recuperar ZSK ou CSK, mudar o SOA apenas para anunciar o novo DNSKEY cria um registro que a chave antiga não pode assinar. Respostas de RRsets existentes ainda podem validar, enquanto provas de inexistência para tipos ausentes ficam Bogus. O problema aparece no bitmap NSEC ou NSEC3, não necessariamente na consulta positiva usada pelo monitor habitual.

Manter o SOA evita essa quebra, mas também pode impedir que secundários baseados no serial percebam a nova versão. Operadores talvez precisem forçar IXFR, AXFR ou recarga. Os padrões de notificação e transferência dos RFC 1996 e RFC 9103 organizam o transporte, mas uma notificação enviada, uma transferência iniciada ou um serial igual não prova que cada secundário está servindo conteúdo idêntico.

A troca do RRset DNSKEY também invalida qualquer ZONEMD publicado. O digest deve ser regenerado, assinado e combinado na ordem correta com NSEC/NSEC3, como estabelece o RFC 8976. Um ZONEMD válido reforça a evidência de integridade do conteúdo segundo seu esquema; não substitui a validação da cadeia DNSSEC ou testes de serviço ao vivo.

O Internet-Draft registra que os procedimentos foram verificados com Knot DNS, mas também descreve passos manuais e observa que o caminho testado não oferece suporte à geração manual de um novo digest ZONEMD. Isso demonstra uma experiência de implementação, não adoção universal. Em infraestrutura heterogênea, cada recurso — retenção de RRSIG, recarga sem serial novo, geração de ZONEMD — precisa ser comprovado no ambiente real.

Um resultado, um limite de inferência

Os RFC 4034, RFC 4035 e RFC 9364 explicam registros e validação. Eles não transformam uma consulta em censo. DNSKEY antiga e RRSIG válida em um autoritativo provam que aquele servidor oferece um estado antigo verificável naquele instante. Não provam posse da chave privada, capacidade de assinar novamente nem igualdade entre servidores.

Uma DNSKEY nova vista em um servidor prova publicação naquele ponto. Um DS aceito prova, no máximo, o ato administrativo. Uma nova RRSIG válida prova a relação de um RRset com uma chave e uma assinatura, não a cobertura de toda a zona. Um SOA igual é indício de versão, não prova criptográfica de conteúdo. Uma resposta NSEC/NSEC3 válida verifica uma negação específica. ZONEMD só vale para o conteúdo novo se for regenerado e sua assinatura validar.

Um resolvedor recursivo que responde Secure representa seu caminho e seu cache naquele instante. É preciso combinar operadores independentes, vários pontos de observação, caches quentes e frios, consultas positivas e negativas e repetições antes e depois da janela de retirada. Limpar um cache e obter sucesso não demonstra convergência global. Uma requisição HTTP, TLS ou de negócio bem-sucedida confirma um caminho aplicativo; não confirma todos os clientes validadores nem todos os autoritativos.

O dossiê mínimo da função restaurada

Antes da primeira mudança, preserva-se uma captura imutável da última zona assinada válida, com inventário de DNSKEY, DS, início e expiração de RRSIG, SOA, NSEC/NSEC3 e ZONEMD. Durante a transição, cada instância autoritativa observável deve mostrar a retenção do estado antigo e a chegada do novo, inclusive backends anycast e unicast. Recibos de transferência ou carga cobrem todos os secundários.

No pai, a documentação separa solicitação, aceitação, publicação em cada instância e passagem do TTL do DS. No filho, separa publicação da chave, prontidão, ativação, nova assinatura de todos os RRsets, propagação e retirada. As verificações comparam conteúdo, SOA, negativas e ZONEMD. Pontos de espera impedem a retirada enquanto qualquer observação ainda depende do caminho antigo.

Resolvedores de organizações independentes devem validar de redes diferentes ao longo de todo o solapamento. Testes de aplicação nas mesmas janelas verificam continuidade para usuários, sem substituir a camada criptográfica. A operação só pode afirmar “função restaurada” quando o novo caminho assina, todas as superfícies publicam o estado previsto, os caches tiveram tempo de ultrapassar os TTLs e a experiência de serviço continuou observável.

Não existe inventário global de caches. As equações fornecem limites conservadores sob hipóteses de TTL e propagação que precisam ser verdadeiras. Um autoritativo desconhecido, um TTL maior que o registrado ou um atraso variável no pai aumenta a incerteza. A evidência correta não promete onisciência; mostra que a organização mediu cada superfície controlável, esperou as cotas adequadas e não destruiu o único estado que ainda permitia validar.

Fontes