Resumo

  • O filho publica CDS/CDNSKEY para declarar os parâmetros de delegação que deseja. O agente parental precisa autenticar o sinal, consultar todos os endereços dos servidores autoritativos, confirmar que os dois formatos representam as mesmas chaves e preservar uma rota válida de DNSSEC.
  • NOTIFY(CDS) antecipa a leitura, mas não autoriza a alteração. Aceitação, publicação no pai, expiração do cache e observação por validadores são estados distintos e precisam de provas próprias.

A réplica que impediu uma mudança errada

O novo conjunto DNSKEY está assinado. O primário serve CDS e CDNSKEY com as impressões digitais previstas. O sistema de provisionamento informa que a rotação está pronta.

O agente parental interroga a delegação como ela existe para os usuários. Três endereços respondem com os novos dados; um endereço de uma réplica ainda serve o conjunto anterior. A operação é cancelada e o DS vigente permanece intacto.

Este é um cenário analítico, não um caso atribuído a um provedor. A maioria não pode substituir uma intenção inequívoca. Se o pai escolher a resposta aparentemente mais nova, deixa de verificar o que o filho publicou e passa a inventar a vontade do filho.

O episódio também desmonta uma palavra ambígua: “publicado”. Uma mudança no painel não prova todos os servidores; um CDS no filho não prova o DS no pai; o DS no pai não prova que os resolvedores recursivos já abandonaram o valor antigo. Cada etapa precisa de um observador adequado.

O corte de zona não desaparece com automação

No DNSSEC, o pai publica o RRset DS que referencia uma DNSKEY do filho. O filho publica e assina o próprio RRset DNSKEY. Validadores independentes cruzam esse limite para construir a cadeia de confiança.

O RFC 7344 define CDS, em formato de DS, e CDNSKEY, em formato de chave. Eles transportam ao agente parental a configuração desejada pela zona filha. Não fornecem acesso de escrita à zona pai.

O agente parental pode ser registro, registrador, revendedor ou outra entidade autorizada. Seu papel estreito é avaliar e encaminhar uma alteração no vínculo que o pai publicará. Ele não ganha autoridade sobre o modelo de negócios do operador filho. Da mesma forma, a assinatura do filho não elimina a responsabilidade do pai por sua própria zona.

Quando registro e registrador conseguem efetuar mudanças, é preciso declarar precedência, canal responsável e condição de retomada após uma intervenção manual. Dois caminhos automáticos corretos, sem coordenação, podem produzir uma corrida de estados.

A unidade de verificação é o endereço

O RFC 9975 exige que o agente parental obtenha todos os endereços IP de cada hostname de nameserver listado na delegação do pai, usando um resolvedor validador e incluindo glue disponível. Cada endereço deve ser consultado.

Isso cobre hostnames com vários A e AAAA, destinos anycast e arranjos com múltiplos provedores. Consultar um nome uma vez pode esconder justamente a réplica que não convergiu.

A consistência é avaliada entre as respostas recebidas; NODATA também é resposta. Havendo divergência, o agente aborta e não cria, altera nem remove RRsets. Não há votação nem preferência pelo dado “mais recente”.

Ausência de resposta requer outra conduta. Tentativas posteriores, recuo exponencial e um segundo ponto de rede ajudam a distinguir indisponibilidade transitória de um servidor persistentemente inacessível. O registro deve separar silêncio, contradição e falha de validação.

Dois formatos, uma única intenção

Ao processar CDS, o pai recebe dados em formato DS e o filho influencia a escolha do digest. Ao processar CDNSKEY, o pai calcula o DS e pode escolher o digest segundo sua política. Como não há descoberta geral da preferência do pai, o RFC 10026 exige que o operador filho publique ambos quando não conhece essa preferência.

Os dois RRsets precisam apontar para o mesmo conjunto de chaves. Uma diferença não é uma oportunidade para o pai escolher; é um pedido ambíguo que deve ser rejeitado.

As recomendações criptográficas também mudam. Os registros da IANA para algoritmos DNSSEC e digests DS são a referência viva. Uma decisão reproduzível guarda as entradas, o DS calculado e a versão da política aplicada.

Segurança significa continuidade de validação

Mesmo uma solicitação uniforme pode produzir um DS ruim. O RFC 10026 determina que o mantenedor automático confirme que o conjunto resultante permitiria continuar a validação DNSSEC e cancele a alteração se não conseguir.

Pelo menos uma chave referenciada pelo novo DS deve validar a assinatura do RRset DNSKEY filho com combinações aceitáveis. A sobreposição de chaves durante a rotação existe para que resolvedores com o DS antigo e resolvedores com o novo encontrem uma rota válida.

Esse teste define o mandato legítimo do lado parental: proteger a interoperabilidade do vínculo que será publicado. Requisitos locais adicionais podem existir, mas precisam ser explícitos e versionados. Uma recusa opaca não melhora a cadeia e impede o filho de corrigir a causa.

A primazia do código em execução mantém a ordem correta. Um padrão publicado ou uma caixa “habilitado” não cria adoção. A mudança só se torna real quando implementações compatíveis validam o pedido, o pai publica e os validadores em operação conseguem seguir o novo caminho.

Bootstrap não pode se autenticar sozinho

Uma delegação já segura autentica atualizações futuras por sua cadeia existente. Na ativação inicial, o pai ainda não possui DS. A assinatura no ápice filho não pode criar, por circularidade, o elo ausente.

O RFC 9615 define sinais autenticados em zonas de sinalização assinadas pelo operador DNS. O agente parental valida essas zonas, encontra a informação _dsboot relativa ao filho e usa essa base para autenticar CDS/CDNSKEY de uma delegação ainda insegura.

Existem limites, como nomes excessivamente longos e delegações com apenas nameservers dentro do próprio domínio. Portanto, “suporte a automação” deve ser dividido em bootstrap autenticado, manutenção de delegação segura e canal convencional.

O RFC 8078 também define remoção explícita: CDS com algoritmo 0, tipo de digest 0 e digest 00. Ausência de CDS não é pedido de desativação. Pode ser atraso, erro ou visão diferente; silêncio não autoriza uma operação irreversível.

A notificação apenas toca a campainha

Varredura periódica pode ser lenta. O RFC 9859 permite que o pai anuncie, por DSYNC, um endpoint de notificações. O filho envia NOTIFY(CDS) depois de publicar novos CDS/CDNSKEY.

O aviso pede que o pai leia agora. Ele não contém os dados autorizadores da alteração. O agente ainda busca as respostas autoritativas, valida, compara todas as direções, calcula o DS e verifica continuidade.

Uma notificação perdida aumenta latência e pode ser recuperada por reconciliação periódica. Uma notificação repetida deve ser idempotente. Uma falsa não altera nada se os RRsets autoritativos continuarem iguais.

Métricas úteis separam descoberta do destino, entrega do aviso, início da coleta, consistência, decisão, publicação e validação. “Aviso recebido” nunca deve aparecer como “DS atualizado”.

O cache inicia outra transição

Aceitação pode ficar numa fila antes de a zona pai ser gerada. A prova de publicação é o DS observado nos servidores autoritativos do pai, junto com versão da zona, TTL e horário.

Resolvedores recursivos mantêm o DS anterior até seu TTL. Durante a mudança, pontos distintos podem ver estados diferentes. A rotação segura preserva ao menos uma rota válida para ambos.

O RFC 10026 recomenda reduzir temporariamente o TTL do novo DS para cerca de cinco a quinze minutos, facilitando rollback, e restaurar o valor normal somente depois que o RRset anterior teve tempo de expirar. O novo TTL curto não reescreve caches antigos.

Por isso, a verificação externa deve cobrir o horizonte do TTL anterior e usar redes distintas. Cada amostra registra DS visto, DNSKEY usada e resultado de validação. Um sucesso comprova um caminho naquele instante, não a convergência global.

Automação precisa de uma saída independente

Manutenção de chave é operação normal. Um bloqueio comum de atualização no registrador ou registro não deve, sozinho, suspender a manutenção DS autenticada, pois normalmente protege o portal e não a autoridade do próprio intermediário.

Ainda assim, o RFC 10026 exige outro canal de manutenção. Chaves podem ser perdidas, um provedor pode não colaborar e migrações podem produzir solicitantes concorrentes. O caminho alternativo deve ser autenticado fora do mecanismo quebrado e produzir uma trilha equivalente.

Uma ação manual pode pausar a automação para estabelecer novo estado-base. Ela não deve criar suspensão permanente sem condição de retomada.

Fontes