Resumo

  • O rascunho DNS Delegation Extensions exige que stubs conscientes e sensíveis à segurança usem resolvedores com as mesmas propriedades, e que validadores com encaminhamento dependam apenas de encaminhadores igualmente conscientes e seguros.
  • O bit DE negocia capacidade, enquanto a proteção contra remoção de dados depende de uma zona assinada, ADT na DNSKEY validada e fiscalização da prova NSEC ou NSEC3 em todo o caminho relevante.

O teste em laboratório parecia completo. O stub enviava o bit DE. O resolvedor recursivo devolvia o mesmo bit. A zona era assinada e o software sabia validar os novos Tipos de Delegação. Em produção, porém, as consultas saíam por um encaminhador legado. Algumas zonas seguras falhavam na validação; em zonas inseguras, usuários em redes diferentes recebiam respostas diferentes.

Nenhuma das duas pontas havia mentido sobre sua capacidade local. A hipótese errada estava no desenho do teste: suporte em A e suporte em C não provam preservação por B.

Essa costura aparece de modo explícito na revisão 11 de DNS Protocol Modifications for Delegation Extensions. O documento, datado de 17 de setembro de 2026 e com expiração em 21 de março de 2027, é um Internet-Draft ativo do grupo DNSOP, destinado à trilha de padrões. Não é RFC final, relatório de implantação ou evidência de que determinado provedor implementou o mecanismo. Ele descreve requisitos propostos e, sobretudo, expõe onde a afirmação “fim a fim” precisa de recibos intermediários.

Uma linguagem negociada por consulta

O texto propõe o bit 2 de EDNS(0) para a flag DE. Um resolvedor consciente a coloca na consulta para indicar que entende Tipos de Delegação. Um resolvedor recursivo consciente, ao receber DE de um stub consciente, deve devolvê-la na resposta.

Quando um servidor autoritativo recebe DE zerado, segue o comportamento legado e trata os novos tipos como dados comuns. Quando recebe DE=1, inclui na indicação os tipos NS-Omitting, NS-Preserving e Private presentes no nome delegado; os tipos On-Demand só aparecem quando consultados explicitamente.

Se houver qualquer tipo NS-Omitting, o servidor não inclui o RRset NS, mesmo que outros tipos estejam presentes ou que a consulta seja por NS. Sem tipo NS-Omitting, inclui NS. A negociação permite que um cliente antigo não receba uma forma de delegação que não sabe executar.

Mas DE pertence à mensagem atual. Um intermediário pode removê-la, intencionalmente ou por falta de suporte. O servidor autoritativo passa a enxergar uma consulta legítima de cliente legado e produz outra forma de resposta. A devolução de DE entre stub e recursivo não prova o estado do pacote que chegou à autoridade.

A costura do encaminhamento

O rascunho determina que um stub consciente da extensão e sensível à segurança use apenas resolvedores conscientes e sensíveis à segurança. Da mesma forma, um resolvedor validante que usa encaminhadores deve depender apenas de encaminhadores conscientes da extensão e sensíveis à segurança.

A razão não é estética. Sem essa continuidade, zonas protegidas por DNSSEC podem deixar de validar e zonas inseguras podem produzir resultados inconsistentes. O intermediário não é um tubo neutro: ele participa da negociação, preserva ou perde informação, e condiciona a evidência que o validador recebe.

Uma lista de recursos de produto não resolve essa dependência. “Suporta DELEXT” pode significar que o software aceita a flag na interface de entrada, que a encaminha na saída, que interpreta novos RRsets, que valida ADT, ou apenas que reconhece a sintaxe. O caminho operacional precisa mostrar qual dessas ações ocorreu em cada salto.

ADT ancora a obrigação fora da consulta

Para detectar a retirada dos novos dados, o texto propõe o bit 14 de DNSKEY como ADT, Authoritative Delegation Types. O validador obtém o estado de ADT no RRset DNSKEY já validado da zona delegante. Se qualquer chave tiver ADT, a indicação deve conter prova NSEC ou NSEC3 da presença ou ausência de Tipos de Delegação no nome delegado.

O validador compara os RRsets NS-Omitting, NS-Preserving e Private da resposta com os Type Bit Maps autenticados. Se a prova declara um tipo e a indicação o omite, a resposta foi adulterada e deve ser ignorada. Tipos On-Demand podem constar no mapa sem vir na indicação comum, porque sua ausência ali é parte do contrato.

Essa obrigação sobrevive à remoção de DE porque não foi negociada na consulta. Ela vem da DNSKEY previamente validada. Um encaminhador ou atacante pode fazer a autoridade devolver apenas NS, mas o validador ainda sabe que a zona assinada prometeu prova sobre Tipos de Delegação.

Mesmo assim, quatro condições precisam coexistir: zona delegante assinada, ADT definido, validação DNSSEC e aplicação da verificação. Sem qualquer uma delas, o mecanismo não oferece proteção criptográfica contra a retirada da flag ou dos RRsets. A palavra “compatível” não substitui esse conjunto.

Se ADT estiver zerado, uma resposta positiva com DELEG não deve ser marcada como DNSSEC-bogus só por isso. Ela segue as regras normais. Aceitabilidade e resistência à remoção continuam sendo estados diferentes.

O número do tipo também governa o caminho

O intervalo proposto 0xF0000xF1FF é dividido em quatro segmentos. 0xF0000xF07F contém tipos que dispensam NS. 0xF0800xF0FF preserva NS. 0xF1000xF1EF reúne tipos consultados sob demanda. 0xF1F00xF1FF é de uso privado, com comportamento de preservação de NS.

O segmento permite que uma implementação consciente do arcabouço, mas não de um tipo futuro específico, determine o comportamento da indicação. Isso torna a alocação do código uma decisão de protocolo. Um tipo que substitui NS, se colocado no segmento que o preserva, instrui software genérico a manter um caminho que o projeto do tipo queria eliminar.

A revisão especializada precisa avaliar a adequação do segmento, a segurança para implementações que ainda desconhecem o tipo e a compatibilidade com DNSSEC. Não se trata apenas de evitar colisão numérica. O registro distribui uma regra de fallback para software futuro.

A ausência de fallback é deliberada

Quando uma indicação contém um tipo NS-Omitting, o resolvedor deve usá-lo e ignorar NS. Registros NS presentes não são validados nem armazenados. Se o tipo NS-Omitting é conhecido como existente, mas seus dados são inutilizáveis, o resolvedor não pode recorrer a NS; trata a lista como servidores inalcançáveis.

Essa escolha impede que uma falha faça o tráfego voltar silenciosamente a DNS tradicional e possivelmente não criptografado. Para disponibilidade, parece tentador usar o NS que ainda responde. Para segurança, isso troca a política sem autorização.

O encaminhador intermediário amplia o risco. Ele pode transformar uma decisão explícita de “não voltar a NS” em uma resposta legada antes que o validador veja os dados. ADT, quando suas condições valem, permite detectar a falta da prova. Sem ADT ou DNSSEC, a diferença pode aparecer apenas como êxito por um caminho mais fraco.

Diagnóstico não é restauração

Se uma delegação tem apenas novos tipos e nenhum NS, um cliente que envia DE=0 recebe resposta negativa. O servidor deve, em princípio, incluir EDE 34, “New Delegation Only”. O código explica que a delegação existe em uma forma que o cliente não entende. Não ensina essa forma ao cliente.

Um atacante também pode remover DE para provocar a negativa. Com ADT validado, o resolvedor exige prova NSEC ou NSEC3 e rejeita uma resposta sem ela. No caso de Compact Denial of Existence, uma resposta NXNAME no nome consultado esconderia os bits no ponto de delegação; é necessária a prova convencional de Name Error.

Detectar a adulteração permite falhar com razão verificável, mas não garante uma resposta ao usuário. Métricas devem manter separados “ataque recusado”, “incompatibilidade diagnosticada” e “nome resolvido”.

SLIST mostra candidatos, não uso real

O rascunho transforma SLIST em um conjunto capaz de guardar múltiplos tipos de informação de delegação. Valores iguais entram uma vez. Ainda assim, dependências cíclicas e trabalho excessivo exigem limites explícitos.

O próprio texto afirma que RFC 1034 e a proposta definem como preencher SLIST, não como usá-la. A presença de um servidor no conjunto não comprova escolha, conexão, transporte criptografado ou resposta. Esse limite é especialmente importante com encaminhadores: o componente que montou a lista pode não ser aquele que realizou a consulta externa.

Um recibo fim a fim registra DE em cada fronteira, DNSKEY e ADT validados, prova NSEC/NSEC3, segmento do tipo, decisão sobre NS, candidatos de SLIST, servidor efetivamente escolhido, transporte e resultado. Sem esses elos, o sucesso de uma ponta empresta credibilidade indevida às demais.

O resolvedor do incidente conhecia a extensão. O stub também. O problema estava no trecho que ninguém havia incluído no modelo de evidência. Em sistemas distribuídos, “fim a fim” não é um adjetivo que se cola à arquitetura; é uma sequência de afirmações locais que precisa sobreviver a cada intermediário.

Fontes