Resumo

  • O DS usado pelos validadores pertence à zona pai. CDS/CDNSKEY descreve o estado desejado pelo filho. Quando já existe um DS válido, a cadeia atual autentica a rotação de chaves; na primeira habilitação, essa cadeia ainda não existe.
  • A RFC 9615 autentica a ativação inicial por cópias iguais sob as zonas seguras de todos os servidores de nomes fora do domínio filho. O procedimento prova concordância operacional dos provedores listados, não propriedade do domínio ou aprovação humana.
  • Política de admissão, resumo criptográfico, publicação no pai, escoamento de TTL e validação final continuam separados. O registro de algoritmo zero pede a remoção de todo o DS e exige um controle destrutivo próprio.

A solicitação que chegou antes da âncora

Uma empresa contrata um novo DNS autoritativo. O provedor gera chaves, assina a zona e publica CDS e CDNSKEY no ápice. Todas as instâncias autoritativas devolvem o mesmo conteúdo. O serviço anuncia que a ativação de DNSSEC está pronta, mas o domínio pai ainda não publicou DS.

O filho não pode criar a confiança apenas assinando a si mesmo. Um atacante também consegue produzir uma chave, um DNSKEY e uma assinatura internamente coerentes. O validador precisa do DS no pai para saber qual chave do filho está ligada à confiança que já possui.

O provedor comprova posse da chave privada e controle das respostas. O registrante normalmente decide quem opera o domínio. O registrador autentica uma conta. O registro ou outro agente parental tem acesso à alteração do DS. Esses fatos podem alinhar-se sem serem equivalentes.

A automação resolve um gargalo real. Copiar manualmente um resumo criptográfico a cada troca de KSK ou CSK cria erro e atraso. CDS/CDNSKEY reduz essa transferência humana, mas a economia operacional só é segura quando cada mudança ainda conserva a origem do mandato e a prova de execução.

Um desejo publicado no filho, um ato executado no pai

O DS efetivo fica na zona pai e aponta para uma DNSKEY do filho por meio do identificador da chave, do algoritmo, do tipo de resumo e do próprio resumo criptográfico. CDS tem os mesmos campos do DS, com outro tipo. CDNSKEY fornece a chave pública para o agente parental calcular o DS.

A RFC 7344 dá ao conjunto o sentido de substituição: ele mostra como o filho gostaria que o DS ficasse. O consumidor calcula o delta e o transforma em mudanças no sistema parental. Não é uma atualização direta feita pelo filho nem uma transferência da autoridade da zona pai.

Ausência de CDS e CDNSKEY significa não mudar. Depois de sincronizar, o operador filho pode retirar os sinais. Uma consulta vazia, falha de coleta ou limpeza normal não autoriza apagar o DS.

O pai pode preferir CDS ou calcular a partir de CDNSKEY. Também pode limitar os tipos de resumo aceitos. Por isso o DS gerado pode diferir do CDS nessa seleção e ainda representar a mesma chave. Essa política local é uma decisão visível, não uma correção silenciosa.

O filho escolhe o material que deseja representar. O agente parental autentica e admite. O pai publica. O resolvedor valida. A uniformidade do formato permite automatizar a passagem; não reúne os quatro verbos.

O DS atual autoriza uma transição limitada

Se um DS já corresponde a uma chave atual, o novo CDS/CDNSKEY pode ser validado pela cadeia existente. O sinal no ápice precisa estar assinado por uma chave representada tanto no DNSKEY corrente quanto no DS, e a aplicação da mudança não pode quebrar a continuidade.

O ponto seguro anterior funciona como ponte. Mesmo assim, o agente parental busca o RRset atual, valida, compara e impede que observações antigas substituam as novas. Inception de RRSIG e serial SOA ajudam a ordenar, mas o consumidor precisa guardar o estado que aceitou.

Depois da publicação, os caches continuam com DS, DNSKEY e RRSIG de tempos diferentes. A chave nova deve estar em todas as autoridades antes de ser referenciada. A antiga permanece enquanto um resolvedor ainda puder possuir o DS correspondente. Uma resposta HTTP bem-sucedida não encerra esses relógios.

O guia atual do BIND mostra o limite entre os lados. O software publica CDS/CDNSKEY, consulta parental-agents e pausa a rotação até que todos mostrem o DS esperado. Quando o pai não consome os registros, o operador ainda envia a informação manualmente. A preparação do filho não obriga a capacidade parental.

O primeiro vínculo usa a confiança do operador

A RFC 8078 descreveu políticas de primeiro ingresso: UI ou API autenticada, checagens de registro, observação por algum tempo, desafio ou processamento na criação da delegação. Cada uma pode atender um relacionamento, mas não constitui por si só uma validação DNSSEC originada no filho inseguro.

A RFC 9615 cria um caminho dentro do próprio DNS quando existe ao menos um servidor de nomes fora do domínio filho. Para cada nome de host do NS parental, o operador forma um domínio com _signal. Um nome _dsboot dentro desse domínio identifica o filho e publica uma cópia de seu CDS/CDNSKEY.

A zona de sinalização já deve ter uma cadeia DNSSEC válida. Assim, o pai valida a cópia sob o espaço de nomes do operador e a compara com o conteúdo obtido diretamente do ápice ainda inseguro. A autenticação vem de uma autoridade operacional já estabelecida, não da afirmação circular do filho.

O agente parental confirma que não há DS e lê o conjunto NS do pai. Consulta, sem cache, cada servidor autoritativo do filho. Depois valida cada sinal fora do domínio e compara os RRsets por tipo. Falha, ausência ou divergência em qualquer ponto aborta o procedimento.

Se todos os servidores de nomes estiverem dentro do domínio filho, não existe cadeia externa e o método não funciona. Em múltiplos provedores, a exigência também impede uma empresa de habilitar sozinha sua chave enquanto as outras autoridades exibem outro estado. A RFC 8901 exige uma visão comum de CDS/CDNSKEY durante a operação com múltiplos signatários.

Concordância técnica não é título jurídico

O sinal prova que os operadores expostos no NS concordam em assinar para o filho e conhecem o mesmo conjunto de chaves. Não prova quem contratou o serviço, quem detém o domínio nem se a organização aprovou a ação.

A RFC 9615 observa que um operador de DNS pode publicar esses registros sem conhecimento explícito do proprietário e recomenda transparência. Uma habilitação legítima, uma configuração errada e uma conta comprometida podem produzir sinais criptograficamente autênticos. A diferença está fora da assinatura.

A política parental registra qual relação permite ao agente agir, quais transições cada ator pode pedir, quando o titular é avisado e como cancela uma ativação inesperada. DNSSEC fortalece a proveniência da evidência; não resolve a cadeia institucional de mandato.

A minimização de QNAME reduz outro risco. Sem ela, um ancestral do domínio de sinalização pode ver o nome completo e tentar responder sob sua própria autoridade em vez de encaminhar ao corte correto. A minimização reduz exposição, mas não substitui a validação do destino e a igualdade dos sinais.

Algoritmo zero é uma retirada de confiança

As formas exatas CDS 0 0 0 0 e CDNSKEY 0 3 0 0 significam remover todo o DS do pai. O algoritmo zero não é uma opção válida de assinatura. Também não é equivalente a não encontrar registros.

Depois de autenticar e admitir o pedido, o pai remove DS. O filho espera o TTL parental antes de parar de assinar. Apagar DNSKEY primeiro deixa resolvedores com uma referência antiga para uma chave ausente e transforma a zona em inválida.

Os estados documentados pela Cloudflare ilustram uma sequência concreta: durante a desativação, a zona continua assinada e serve o sinal zero até a retirada do DS; só depois o material DNSSEC desaparece. Os nomes são específicos do produto, mas os tempos distintos existem em qualquer implementação correta.

Voltar ao estado inseguro reduz proteção e pode eliminar o caminho autenticado de recuperação. Por isso a remoção precisa de aviso, aprovação própria, janela de TTL e plano de reentrada. O sistema nunca deve interpretar silêncio como esse ato destrutivo.

A evidência termina no resolvedor

Antes da mudança, preservam-se NS e DS parentais, respostas de todas as autoridades, nomes de sinal, cadeias de validação, igualdade, atualidade, estado contra repetição, decisão sobre o resumo criptográfico, autoridade da conta e diferença proposta.

Depois, observa-se o DS em todos os servidores do pai, espera-se a janela de cache, confirma-se a chave em todos os filhos e testa-se com validadores de redes independentes. Um painel verde mostra que uma aplicação aceitou a solicitação. Um DS mostra estado autoritativo. A cadeia validada mostra consequência em uma rota real.

Abortos também são resultados válidos. Divergência entre operadores, sinal inválido, resumo não suportado ou delegação totalmente interna ao domínio filho explica por que o poder parou. Um sistema responsável registra a recusa com a mesma precisão que o sucesso.

Fontes