Resumo

  • A RFC 5155 permite que delegações não assinadas elegíveis sejam omitidas da cadeia NSEC3 quando o registro que cobre o intervalo tem a flag Opt-Out.
  • Esse registro não afirma se as delegações inseguras cobertas existem ou não; ele autentica uma negação de alcance mais estreito.
  • Uma delegação segura depende de um RRset DS assinado e de uma cadeia validada, não apenas de uma assinatura NSEC3 válida perto do hash consultado.
  • O registro operacional deve preservar os estados seguro, inseguro, bogus e indeterminado, em vez de condensá-los em “DNSSEC aprovado”.

Imagine um rastreamento de resolvedor no qual todas as RRSIG são validadas, os intervalos NSEC3 se encaixam e o resultado aparece em verde. Mais tarde, uma exportação de auditoria traduz essa linha para “delegação filha protegida”. Mas o nome consultado está em um intervalo Opt-Out. A prova era autêntica; a conclusão ultrapassou o que ela dizia.

O exemplo é hipotético e não atribui falha a nenhum registro ou operador. A questão é de escopo: validade criptográfica não amplia a afirmação que o registro assinado realmente contém.

O que o Opt-Out muda

A RFC 5155 define NSEC3 como uma forma com hash de negação autenticada de existência. Em vez de expor nomes de proprietário em ordem legível, a zona assina registros que formam uma cadeia ordenada pelos hashes.

Em zonas com grande volume de delegações, manter um NSEC3 e uma assinatura para cada filha não assinada pode custar caro. O Opt-Out permite excluir os nomes de delegações inseguras que atendem às condições. Um registro com a flag ativa pode abranger zero ou várias dessas delegações, permitindo incluí-las ou removê-las sem reconstruir aquela parte da cadeia.

Essa economia operacional muda o significado da prova. A RFC 5155 determina que um NSEC3 Opt-Out não afirma a existência nem a inexistência das delegações inseguras que pode cobrir. Ele ainda autentica afirmações sobre outros dados autoritativos no intervalo, mas a filha sem assinatura fica deliberadamente fora do inventário criptográfico completo.

Uma prova válida pode terminar em “inseguro”

A evidência do lado da zona pai no ponto de delegação é decisiva. A RFC 5155 distingue a delegação segura — um RRset NS acompanhado de RRset DS assinado — da delegação insegura, que tem NS, mas não DS. É o DS que liga os dados autenticados do pai à DNSKEY da filha.

Validar a RRSIG do NSEC3 prova que o pai assinou aquela afirmação NSEC3. Isso não cria um DS para a filha coberta, nem a flag Opt-Out afirma sozinha que uma delegação específica existe. A RFC 7129 explicita a consequência: os registros Opt-Out não podem provar ou negar a existência das delegações inseguras que cobrem, e essas delegações não recebem a segurança criptográfica do DNSSEC.

Por isso, o resolvedor precisa fazer mais do que aprovar uma primitiva criptográfica. Ele deve identificar o ponto de delegação, localizar o DS ou autenticar sua ausência, avaliar a prova NSEC3 aplicável e continuar a validação quando houver cadeia. Seguro, inseguro, bogus e indeterminado são conclusões diferentes.

Manter o escopo junto do resultado

A evidência deve identificar consulta, código de resposta, zona e ponto de delegação. Para NSEC3, convém preservar algoritmo de hash, iterações, salt, hash do proprietário, próximo hash, bitmap de tipos e flag Opt-Out. Se o closest provable encloser fizer parte da negação, seus elementos também entram, assim como os resultados de DNSKEY e RRSIG e a âncora de confiança usada.

Cache e tempo também limitam a conclusão. TTL, início e expiração das assinaturas, publicação no pai e idade do cache do resolvedor definem a janela da observação. Uma alteração posterior no DS pode mudar o estado da delegação mesmo que a prova antiga permaneça no arquivo de auditoria.