Resumo

  • O ZONEMD vincula o serial SOA a um digest da zona inteira em ordem canônica, incluindo glue e dados ocultos. Assim, uma cópia com transferência concluída e versão aparentemente correta pode ser impedida de entrar em serviço se seu conteúdo divergir.
  • Com DNSSEC, o compromisso pode ser autenticado; sem DNSSEC, ele só detecta alterações acidentais. Ainda são necessárias evidências separadas de aprovação, carga em cada frota, respostas reais e retirada da geração rejeitada.

O pipeline aprovou a nova zona em todas as etapas que costumavam importar. O AXFR terminou. O arquivo foi gravado. O parser não encontrou erro. O serial SOA era o mesmo do change ticket. Mesmo assim, uma RR de glue havia desaparecido entre a construção e o diretório de staging.

Não havia corrupção suficiente para tornar o arquivo ilegível. Havia apenas conteúdo suficiente para criar um defeito seletivo: delegações dependentes daquele endereço poderiam falhar, enquanto os monitores continuavam anunciando a versão correta. A operação sabia qual número estava servindo, mas não qual zona.

O RFC 8976 define o ZONEMD para fechar essa lacuna. O registro no apex carrega um message digest sobre os dados da zona em repouso. O receptor reproduz a ordenação canônica, calcula o valor local e compara com o compromisso publicado. Se uma RR incluída sumir ou mudar, o digest não fecha — ainda que o serial continue igual.

O serial organiza gerações; ele não deriva uma identidade do conteúdo

O campo Serial da SOA vem do RFC 1035. O RFC 1982 explica como comparar números em um espaço finito, inclusive quando a sequência volta a zero. Essa regra permite que secundários decidam localmente se uma geração parece mais nova, sem depender de relógio global.

O número é escolhido pelo publicador. Ele não resulta do conjunto de RRs. Duas construções podem emitir conteúdo diferente com o mesmo serial; um repositório pode entregar bytes errados sem alterar a SOA; um restore pode combinar dados antigos e número atual. Comparar o serial esperado com ele mesmo não revela a diferença.

O RDATA do ZONEMD contém Serial, Scheme, Hash Algorithm e Digest. Repetir o Serial nesse objeto liga o resumo a uma instância específica da zona. A SOA responde qual geração foi nomeada. O ZONEMD responde qual conteúdo canônico completo o publicador comprometeu sob aquele nome. Tratar uma resposta como substituta da outra elimina justamente o controle novo.

Transferência também é outra autoridade. O RFC 1995 define IXFR para mudanças incrementais; o RFC 5936 define AXFR para a zona completa. Eles entregam ou reconstroem um candidato. Não mantêm, depois do armazenamento, cópia, restore, restart e load, uma prova ligada ao objeto inteiro. O ZONEMD acompanha a zona além do canal.

SIMPLE compara DNS, não a aparência de um arquivo

ZONEMD recebeu o RR type 63. O Scheme 1, SIMPLE, é o esquema padronizado e deve ser suportado. SHA-384, Hash Algorithm 1, também é obrigatório e publica todos os 48 octetos. SHA-512, algoritmo 2, deveria ser suportado e usa os 64 octetos completos. O estado dos códigos aparece no registro de parâmetros DNS da IANA.

SIMPLE não aplica hash ao texto literal de um master file. Comentários, espaços e capitalização podem variar sem mudar os dados DNS. As RRs passam para o canonical wire format sem compressão e seguem a ordem do RFC 4034; RRsets com o mesmo owner também são ordenados pelo valor numérico do tipo. Formatações diferentes podem representar o mesmo compromisso; semântica diferente, não.

As regras de inclusão dão alcance ao mecanismo. Todos os registros dentro da zona entram, salvo exceção explícita. Glue entra. Occluded data entra. Duplicatas exatamente iguais entram uma vez. Material fora da zona fica fora. Em zona assinada, registros DNSSEC também participam, exceto o placeholder ZONEMD no apex e a RRSIG que cobrirá o RRset ZONEMD final.

Essa cobertura não substitui DNSSEC. DNSSEC autentica RRsets e provas usadas na validação de respostas. O artefato completo distribuído inclui dados de delegação e glue que não têm a mesma proteção de um RRset autoritativo comum do child. ZONEMD compromete a zona como um todo para servidores autoritativos, repositórios e outros consumidores de cópia integral.

O desenho cobra uma passagem completa. Uma RR alterada exige novo cálculo SIMPLE sobre a zona inteira. O RFC 8976 avisa que isso pode ser inadequado para zonas grandes ou altamente dinâmicas. A pergunta correta não é se o produto tem suporte, mas se geração e verificação cabem com folga no intervalo de update e no tempo de propagação, inclusive durante falha e replay.

A ordem de publicação evita que a assinatura mova o próprio alvo

Em uma zona DNSSEC, acrescentar ZONEMD depois da assinatura mudaria os bitmaps de tipo em NSEC ou NSEC3. O fluxo remove registros ZONEMD antigos e as assinaturas correspondentes, insere um placeholder no apex antes de assinar e permite que as provas de inexistência já reconheçam a presença do tipo.

Depois da assinatura, o digest SIMPLE é calculado sobre a sequência canônica. O placeholder do apex não participa, nem a RRSIG que depois cobrirá o RRset final. O publicador substitui o valor provisório pelo digest e cria ou atualiza essa assinatura.

Gerar a assinatura de ZONEMD não pode incrementar novamente o Serial. A SOA e o ZONEMD correspondentes precisam ser publicados juntos. Caso contrário, o ato de autenticar o compromisso mudaria a versão a que ele deveria se referir.

Por isso, copiar a sequência hexadecimal de uma consulta não forma uma trilha suficiente. O recibo de publicação associa snapshot fonte, política aprovada, releases de builder e signer, Serial, Scheme, algoritmo, digest, contexto das chaves DNSSEC e horário da troca atômica. Só essa cadeia permite descobrir se a divergência nasceu na origem, na construção, na assinatura ou na distribuição.

Antes do digest, o verificador define qual segurança deveria existir

A zona contendo ZONEMD não informa sozinha se o valor deve ser autenticado. O receptor primeiro determina se DNSSEC é esperado, usando trust anchors locais e, quando necessário, a cadeia DS validada no parent. O RFC 4035 fornece o contexto dessa validação.

Quando assinaturas são esperadas, o verificador confirma a existência do RRset ZONEMD e valida as assinaturas de SOA e ZONEMD. Uma prova DNSSEC de ausência significa que a verificação do digest não pode ocorrer. Se a prova diz que o RRset deveria existir, mas a cópia não o contém, não há sucesso. Falha de assinatura também não pode ser rebaixada silenciosamente a checksum só porque o valor calculado coincide.

Depois vêm os controles de estrutura. Em um RRset com vários ZONEMD, cada par Scheme/Hash Algorithm deve ser único. A política local pode ignorar um par que considera inaceitável. Para cada candidato permitido, o Serial precisa ser exatamente igual ao da SOA, Scheme e algoritmo devem ser suportados, o tamanho válido e o digest local igual ao recebido.

Durante transição, a correspondência de um par aceito é suficiente. Isso torna obrigatória a remoção do método antigo: a segurança de vários digests fica limitada pelo algoritmo mais fraco ainda aceito. Migração precisa de condição de saída, não apenas de uma etapa de adição.

O resultado deve registrar motivo. ZONEMD esperado e ausente, chain DNSSEC indisponível, serial divergente, par duplicado, algoritmo rejeitado, tamanho inválido e content mismatch pertencem a domínios diferentes. Um único status vermelho não diz se o próximo passo seguro é repetir, isolar, reverter ou escalar.

Sem DNSSEC, um adversário altera a zona e refaz o resumo

Em zona não assinada, o ZONEMD funciona como checksum. Ele encontra truncamento, erro de transmissão ou corrupção acidental enquanto o digest original permanece. Quem consegue mudar maliciosamente a zona também consegue recalcular o valor e substituir o registro. Não há proteção real contra esse atacante.

DNSSEC torna detectáveis remoção e alteração do compromisso e autentica SOA/ZONEMD até uma trust anchor. Ainda assim, autentica apenas que o publicador autorizado comprometeu aquele conteúdo. Um processo autorizado pode assinar uma delegação errada com consistência perfeita. O digest não prova propriedade, intenção legítima, aprovação do ticket, segurança da aplicação nem adoção em toda a frota.

TSIG protege outra fronteira. O RFC 8945 autentica transações DNS com segredo compartilhado e é útil para pares AXFR/IXFR. Depois que o conteúdo é gravado, movido, restaurado ou recarregado, o MAC da transação antiga não continua preso à zona completa. ZONEMD oferece uma verificação repetível do objeto após o fim do canal.

Até a autenticação assinada tem prazo. Mudança de trust anchor ou retirada de DS pode impedir validação retrospectiva, mesmo quando a RRSIG parece dentro de sua janela. Um arquivo probatório durável preserva também o contexto de confiança usado na decisão de ativação.

Bloquear conteúdo errado também pode bloquear serviço correto

Um servidor pode verificar o candidato em staging e recusar o load quando o digest não fecha. Esse é o ganho concreto: uma cópia corrompida não vira estado autoritativo.

O mesmo controle cria fragilidade de disponibilidade. Bug de publicação, divergência de canonicalização e alteração intencional podem aparecer como o mesmo mismatch. O hard fail torna indisponíveis também as RRs corretas da zona. Se provedores diferentes reagem de maneira distinta, usuários podem enxergar gerações diferentes conforme o ponto de rede.

Por isso o RFC 8976 admite adoção gradual: aviso primeiro, erro depois de experiência suficiente. O RZERC003 da ICANN tratou a introdução na root zone como coordenação entre Root Zone Maintainer, operadores, implementadores e usuários de cópias locais. A lição não é copiar uma política da raiz, e sim reconhecer que enforcement altera vários domínios de falha.

Uma política madura separa três destinos. Candidato verificado fica elegível para ativação. Candidato divergente entra em quarentena enquanto a geração anterior, já verificada, continua por prazo definido. Evidência inconclusiva — como falha na cadeia de confiança, não diferença de conteúdo — exige decisão fail-open ou fail-closed atribuída e temporária.

Manter a geração anterior conserva integridade conhecida e acumula staleness. Refresh, expire, ritmo de mudança e impacto definem o orçamento. Rollback não pode ser apenas um ponteiro antigo: o objeto precisa estar disponível, passar por verificação independente, carregar e aparecer em respostas reais.

O recibo só termina quando a geração aparece na rede

Serviço autoritativo pode atravessar provedores e muitos sites anycast, cenário do RFC 8901. Sucesso em uma máquina de staging não prova load em toda a frota. Uma API de reload não prova o que o processo responde. Uma consulta a um catchment não cobre os demais.

O recibo de ativação liga cinco etapas. Na origem, source snapshot, Serial e digest assinado. No transporte ou repositório, identidade do objeto, tamanho, hash local e eventos de custódia. No verificador, expectativa DNSSEC, trust anchors, par aceito, valor calculado e motivo. Na ativação, gerações antiga e nova, decisão e resultado do load. Em runtime, consultas de SOA, ZONEMD e RRs incluídas no alcance de frota exigido.

Canários não devem consultar apenas SOA, pois repetiriam o ponto cego do serial. Eles incluem nomes sensíveis à delegação, glue selecionado, RRsets assinados e respostas negativas, registrando identidade autoritativa e rede de observação. Uma root hyperlocal conforme RFC 8806 precisa de recibo próprio para cópia e refresh; o estado da raiz pública não prova a instância local.

O fechamento exige evidência negativa. Depois da reversão, o digest rejeitado deve desaparecer da elegibilidade de staging, dos processos ativos e das respostas amostradas. Encontrar a geração correta em alguns pontos não exclui um nó esquecido ainda servindo a errada.

Fontes