Resumo

  • A flag Opt-Out autoriza um NSEC3 a cobrir delegações inseguras sem declarar se elas existem. Por isso, a ausência de um hash na cadeia não permite apagar o nome do inventário do pai.
  • A operação segura separa base de provisionamento, geração do assinador, respostas NS/DS de toda a frota e interpretação do validador. Só a primeira dessas superfícies promete completude administrativa.

Pense em uma zona pai que recebe milhares de inclusões e remoções de delegações por dia. O assinador produz uma cadeia NSEC3 íntegra e todos os RRSIGs verificam. Um sistema de reconciliação percorre os nós, não encontra o hash de um filho e abre um incidente de “delegação perdida”. A equipe de DNS consulta o mesmo pai e recebe a referência NS esperada, sem DS.

A delegação nunca desapareceu. O sistema de reconciliação escolheu a evidência errada para responder à pergunta.

Pelo RFC 5155, uma delegação com NS e sem DS é insegura. Seu owner hash pode ficar fora da cadeia quando um intervalo NSEC3 com Opt-Out cobre o ponto correspondente. Esse intervalo afirma nem existência nem inexistência da delegação. Assim, o pai pode alterar delegações elegíveis sem refazer os dois nós vizinhos da cadeia.

O ganho é operacional. O limite probatório também é. Assinatura válida não transforma a projeção em cadastro completo.

A origem e o produto do assinador

O inventário fonte contém o nome do filho, NS, glue quando aplicável, DS, estado de atendimento, momento e autoridade da mudança. O assinador recebe esse conjunto e cria uma estrutura para negação autenticada.

NSEC3 organiza hashes, não nomes, e registra algoritmo, flags, iterações, sal, próximo hash e bitmap de tipos. Um nó coincidente pode provar a existência de determinados tipos no nome original. Um nó cobridor pode participar de uma resposta negativa. A cadeia não foi desenhada como transferência reversível de todos os nomes.

Opt-Out permite omitir apenas a classe prevista. Uma delegação segura inclui DS e não pode ser tratada como descartável. Nomes com dados autoritativos também exigem a representação determinada pelo protocolo. Se o assinador omite algo sem elegibilidade ou sem intervalo Opt-Out correto, a geração deve ser recusada.

Para cada ausência na cadeia, guarde o nome fonte, NS/DS, hash calculado, nó cobridor, flag, bitmap, geração e respostas de cada autoridade. Essa ligação torna possível distinguir três eventos muito diferentes: omissão válida, erro do assinador e divergência de servidor.

Opt-Out não é NXDOMAIN comprimido

Um intervalo Opt-Out não declara que todos os nomes dentro dele são inexistentes. Ele reserva uma faixa na qual delegações inseguras podem estar presentes sem nó próprio. Quem recebe apenas a cadeia precisa responder “indeterminado” para essas delegações.

A consulta direta ao pai pode retornar a referência. Uma transferência autorizada ou a base de registro pode fornecer completude. A cadeia sozinha não pode. Isso também protege contra uma automação que apague um filho porque um scanner não o encontrou entre os hashes.

RFC 8198 aplica o mesmo limite ao cache agressivo. Um resolvedor validador pode reutilizar provas negativas assinadas para responder outras consultas em uma faixa. Se o NSEC3 cobridor tem Opt-Out, porém, ele não prova a inexistência do nome e não autoriza essa síntese.

O bit precisa sobreviver à coleta, normalização e decisão. Se um pipeline guarda apenas “DNSSEC válido”, ele perde exatamente a condição que impede uma falsa resposta negativa.

Entre o ancestral existente e o demonstrável

Wildcards e negativas usam o closest encloser, o ancestral existente mais longo. Em uma zona Opt-Out, uma delegação omitida ou um empty non-terminal derivado apenas dela pode não ter nó NSEC3. A cadeia prova então o closest provable encloser, que pode estar acima do ancestral que realmente existe.

Essa diferença não significa falha. Ela define o alcance do material assinado. Preserve a consulta, os NSEC3 e RRSIG, o next-closer, o cálculo do hash, a passagem pelo fim do espaço de hashes, o bitmap e o horário. Sem os objetos originais, um resultado verde não explica qual inexistência foi de fato demonstrada.

A recomendação atual reduz complexidade

O RFC 9276 recomenda NSEC se as propriedades de NSEC3 não forem necessárias. Quando NSEC3 é usado, a configuração recomendada é algoritmo 1, zero iterações extras e sal vazio.

Iterações altas aumentam o trabalho de servidores e validadores e podem provocar incompatibilidade. Sal não torna nomes previsíveis confidenciais. Um resolvedor pode devolver inseguro ou SERVFAIL quando as iterações excedem sua política e, após validar o record relevante, usar EDE 27. Isso descreve a política de recursos do resolvedor, não o cadastro do pai.

Opt-Out não é recomendado para zonas pequenas. Em uma zona enorme, esparsa e dominada por delegações inseguras, pode haver benefício real. A revisão deve medir volume, proporção de filhos com DS, taxa de mudança, custo de assinatura e capacidade de auditoria. O valor não deve sobreviver por tradição.

Toda mudança de parâmetro cria outra geração

Mudar sal ou iterações exige uma cadeia completa nova e nova assinatura. Validadores usam os parâmetros presentes nos NSEC3 examinados; NSEC3PARAM não é, sozinho, uma prova negativa.

O plano de ativação compara inventário, entradas do assinador, saída antiga e nova, serial ou geração, janelas de assinatura e transferências. Testes consultam um inexistente conhecido, um filho inseguro omitido, um filho seguro e uma fronteira de wildcard em cada servidor autoritativo.

Se uma secundária continua na geração antiga, disponibilidade não resolve a divergência. O operador decide com evidência se conclui o rollout ou volta ao último conjunto coerente, considerando TTLs e provas que ainda vivem nos caches.

Fontes