Resumo

  • ZONEMD compara o conteúdo canônico da zona a um resumo vinculado a um serial SOA; DNSSEC é necessário quando a conclusão precisa incluir autenticidade de origem.
  • A igualdade prova que a cópia recebida é o objeto representado pelo publicador, mas não que os registros eram a decisão certa nem que bloquear o candidato preserva melhor o serviço.

Há um tipo de falha que não deixa nenhum vestígio de corrupção: a publicação autorizada de um endereço errado. O serial avança, o ZONEMD é recalculado, as assinaturas validam e todos os secundários recebem a mesma zona. O mecanismo funcionou. O serviço não. A integridade preservou exatamente o erro criado antes dela.

O RFC 8976 permite verificar uma zona inteira mesmo depois que o canal de distribuição desapareceu. Isso importa porque zonas circulam por AXFR, IXFR, arquivos, repositórios e feeds de política. Autenticar uma sessão não conserva necessariamente uma prova anexada ao arquivo; ZONEMD viaja dentro da própria zona.

O registro significativo fica no ápice, com tipo 63, e contém serial SOA, esquema, algoritmo de hash e digest. O serial do ZONEMD deve coincidir exatamente com o SOA. Essa regra prende a prova a uma versão, não apenas a um nome de zona.

SIMPLE usa a forma canônica no fio e a ordenação de RFC 4034. Comentários, espaços, caixa e ordem do texto deixam de definir identidade. Glue e dados ocultos entram no cálculo; duplicatas idênticas contam uma vez; o ZONEMD provisório no ápice e a assinatura que cobre seu RRset ficam de fora. Um ZONEMD fora do ápice não tem função de verificação nesta especificação.

No registro atual da IANA, SIMPLE é o esquema público 1, SHA-384 é o algoritmo 1 e SHA-512 o 2. Implementações devem suportar SIMPLE/SHA-384. Durante uma transição podem existir pares distintos, e uma correspondência suportada e aceita pela política local basta. O par antigo, porém, deve ser removido depois da migração para não permanecer como caminho mais fraco.

Antes do hash, o verificador decide se DNSSEC é esperado. Usa âncoras locais e o DS validado do pai para estabelecer a expectativa. Se DNSSEC comprovar que ZONEMD existe e a cópia não o trouxer, não há sucesso. SOA e ZONEMD precisam validar; pares duplicados são rejeitados; serial, esquema, algoritmo e comprimento são examinados; somente então a zona é canonizada, resumida e comparada.

Sem DNSSEC, quem altera uma zona também pode recalcular o digest. ZONEMD continua útil para detectar truncamento, corrupção acidental ou divergência entre cópias, mas funciona como checksum. Com DNSSEC, a afirmação pode chegar a uma âncora aceita. O RFC 4033 descreve esse modelo e seus limites. DNSSEC protege RRsets; ZONEMD acrescenta a visão do objeto inteiro.

Nenhum dos dois conhece intenção empresarial. Um MX removido por engano, um endereço de contingência colocado no lugar do principal ou uma regra RPZ excessiva podem ser publicados e assinados corretamente. O resultado confirma quem publicou qual objeto, não se o ticket, o contrato ou o julgamento estavam corretos.

As opções dos produtos deixam a decisão visível. Knot DNS separa zonemd-verify na carga/atualização da geração SHA-384 ou SHA-512; as ações vêm desligadas por padrão e há alerta de custo em zonas grandes. Unbound separa checagem, rejeição por ausência e modo permissivo, que registra falhas sem bloquear a zona. PowerDNS documenta um comando explícito para validar arquivo. Suporte ao protocolo não implica uma política única de indisponibilidade.

O próprio RFC expõe a tensão. Impedir que uma zona incompleta seja usada aumenta resiliência. Ao mesmo tempo, um registro ausente, erro de assinador ou defeito de implementação pode tornar indisponível o restante dos dados corretos. Para o comparador, sabotagem e erro operacional podem produzir a mesma divergência. A implantação gradual — primeiro aviso, depois bloqueio — é uma medida de engenharia, não falta de confiança matemática.

O RFC 5936 oferece uma regra de continuidade para AXFR: receber e conferir o candidato, carregá-lo de forma atômica depois do sucesso e, se houver erro, descartar o candidato mantendo a versão anterior em serviço. ZONEMD melhora a conferência. Não exige apagar a última cópia conhecida como boa.

Essa cópia precisa de limite de idade. Permanecer indefinidamente em estado antigo também causa dano. O consumidor deve definir prazo, gatilho de escalada e responsável pela exceção conforme o tipo de zona. O digest não conhece a tolerância específica do negócio.

A cadeia ainda depende do tempo. SOA e ZONEMD correspondentes precisam ser publicados juntos. Assinar o RRset ZONEMD não pode provocar novo avanço do SOA. Mais tarde, uma assinatura ainda vigente pode deixar de ser verificável se o DS ou a âncora necessária desaparecer após um rollover de KSK.

SIMPLE percorre toda a zona a cada mudança. O RFC o considera inadequado para zonas grandes ou muito dinâmicas quando o cálculo se aproxima do intervalo de atualização; Knot também alerta para CPU e tempo. Um controle que não cabe na janela operacional vira atraso ou exceção permanente.

A auditoria deve separar candidato, identidade canônica, autenticidade DNSSEC, semântica, admissão local, versão carregada e respostas observadas. As ideias de Heng Lu sobre primazia do código em execução, especificação inicial mínima e decisão futura localizada e camadas da realidade ajudam a manter o mecanismo comum estreito: ele valida deterministicamente, enquanto a consequência continua sob responsabilidade local.

A página de erratas do RFC 8976 registra uma correção técnica em exemplo de apêndice cujo SHA-384 privado aparece curto demais. A exigência normativa de 48 octetos permanece. Registrar a exceção, em vez de escondê-la, é parte da higiene de evidência.

Por isso, “digest igual” é o início de uma conclusão, não o fim da governança. A organização precisa saber qual serial, âncora, algoritmo e versão do verificador foram usados; quem isolou ou aceitou o candidato; por quanto tempo o estado anterior sobrevive; e qual zona as respostas autoritativas realmente mostram.