Resumo

  • O DNSSEC transformou a resposta negativa em evidência verificável ao assinar os limites ordenados em torno de nomes e tipos de registro ausentes.
  • NSEC3, Opt-Out e o reaproveitamento do cache validado distribuem exposição, computação, garantia de delegações e o momento em que um novo nome começa a funcionar.

Imagine um arquivo em que todo documento presente tenha assinatura autêntica. Isso não prova que o funcionário não escondeu o documento solicitado. Para demonstrar ausência, é preciso também um catálogo assinado cuja ordem torne visível a lacuna.

Esse foi o salto conceitual da negação autenticada de existência do DNSSEC.

O DNS comum retorna NXDOMAIN quando um nome não existe, ou uma resposta sem dados quando o nome existe, mas não o tipo solicitado. Sem validação DNSSEC, a negativa depende da integridade do caminho da resposta. Um adversário em trânsito pode alcançar seu objetivo apenas fazendo um serviço desaparecer.

A RFC 4034 deu à zona assinada uma forma de descrever suas lacunas. Um registro NSEC informa o próximo nome autoritativo na ordem canônica e traz um mapa dos tipos presentes no nome atual. A RFC 4035 define a validação. Se a consulta cai entre dois limites assinados, o intervalo prova que o nome exato não existe. Se o nome existe, mas o tipo não aparece no mapa assinado, a prova se refere ao tipo. Um erro de nome também precisa excluir um curinga capaz de gerar resposta.

Não há um registro negativo para cada pergunta possível. O espaço de rótulos seria grande demais. A evidência é o intervalo ordenado: dois fatos autenticados delimitam um vazio.

A primeira prova mostrava o catálogo

Como cada NSEC aponta para o próximo nome, um consulente paciente pode percorrer a cadeia e reconstruir a zona. Esse “zone walking” não revela informação que o DNS prometesse criptografar, mas uma lista fácil de enumerar pode expor padrões de nomes, serviços de aparência interna ou um mapa de reconhecimento. O validador precisa de limites claros; o operador nem sempre quer fornecer um índice legível.

A RFC 5155 introduziu o NSEC3. A cadeia permanece, mas nomes legíveis viram hashes. O validador ainda consegue demonstrar que o hash consultado está dentro de um intervalo assinado; quem enumera precisa adivinhar rótulos fora de linha.

Isso cria atrito, não sigilo. Rótulos comuns são previsíveis e aparecem em certificados, logs e links. A RFC 9276 registra o retorno decrescente: mais iterações impõem trabalho aos servidores e validadores sem tornar confidenciais nomes fáceis de adivinhar.

Opt-Out incorpora o custo de escala

Em zonas muito grandes, cheias de delegações não assinadas, manter um NSEC3 para cada filho pode pesar sobre assinatura e memória. O Opt-Out permite cobrir delegações inseguras dentro de um intervalo sem um registro hash individual para cada uma.

A economia é real e a concessão também. Segundo a RFC 5155, um intervalo Opt-Out não afirma se uma delegação insegura dentro dele existe. Os demais dados autoritativos continuam protegidos, mas a prova é deliberadamente menor nesse limite. A zona compra mudanças de delegação mais baratas sem oferecer a mesma afirmação criptográfica sobre cada filho não assinado.

Opt-Out é, portanto, uma decisão de governança. Ele define quais ausências o operador aceita respaldar. A RFC 9276 o desaconselha para zonas pequenas e reserva sua utilidade para zonas de delegação enormes, dinâmicas e pouco assinadas.

Uma lacuna em cache responde no futuro

A RFC 8198 permite que um resolvedor validador use agressivamente intervalos NSEC ou NSEC3 em cache. Se uma consulta posterior cai em uma faixa já provada vazia, ele sintetiza a negativa sem voltar ao servidor autoritativo.

Isso reduz latência, carga e vazamento de consultas inúteis, além de ajudar contra parte de ataques com rótulos aleatórios. Mas o cache aplica uma declaração assinada a perguntas futuras; a validade dessa declaração passa a reger a operação.

Os TTLs de NSEC ou NSEC3, junto com os valores de cache negativo da zona, determinam quando um nome recém-criado pode funcionar. Se ele for publicado logo após uma prova ampla de ausência, validadores ainda podem responder corretamente “não” a partir do cache. O protocolo funciona; o plano de mudança ignorou a vida útil da evidência negativa.

A prática atual prefere menos complexidade

A RFC 9276 recomenda NSEC quando os recursos de NSEC3 não são necessários. Quando NSEC3 é preciso, exige zero iterações extras e recomenda salt vazio. Iterações adicionais aumentam computação, risco de esgotamento de CPU e falhas de interoperabilidade; um salt estático oferece pouco porque o nome completo já torna o cálculo específico de cada zona.

Após mudar parâmetros, o operador deve consultar nos secundários nomes sabidamente inexistentes. Registros positivos podem parecer saudáveis enquanto a cadeia negativa está atrasada, divergente ou cara demais para uma implementação.

As RFCs definem mecanismo e prática, mas não comprovam a qualidade de nenhuma implantação específica. Isso precisa ser medido nas bordas autoritativas e validadoras reais.

Fontes