Resumo

  • Um resolvedor recursivo validador ativa o bit DNSSEC AD quando considera autênticos os RRsets pertinentes das seções Answer e Authority; o bit relata a conclusão do resolvedor, não uma propriedade que se comprova sozinha.
  • Um stub não validador só pode depender dessa conclusão se confiar no resolvedor e proteger ou autenticar o canal até ele. Um stub validador deve fazer a própria validação.
  • A validação DNSSEC, a entrega do veredito e a decisão do aplicativo são fronteiras de evidência diferentes; a ausência de AD não diagnostica, isoladamente, dados Bogus.

Um bit aceso depois de muito trabalho invisível

Um notebook pergunta um nome ao resolvedor recursivo configurado. Antes de responder, o serviço pode ter seguido delegações, obtido registros DNSKEY e DS, montado uma cadeia até uma âncora de confiança, conferido assinaturas e tratado uma prova autenticada de inexistência. O histórico não cabe na resposta final. Em seu lugar, o cabeçalho pode trazer o sinalizador Authenticated Data: AD.

Essa compactação é útil. Um cliente pequeno não precisa necessariamente repetir a validação já feita por um resolvedor capaz. Mas o contexto também desaparece. Se uma interface traduz AD=1 como “seguro”, parece que todo o caminho, o destino e a ação solicitada foram certificados. As RFCs sustentam uma afirmação bem mais estreita.

A RFC 4035 determina que um servidor recursivo ciente de segurança só ative AD quando considerar autênticos todos os RRsets nas seções Answer e Authority. O sujeito da conclusão é o resolvedor. Ele aplicou suas âncoras, sua política e sua visão da resposta. O bit resume essa avaliação; não é uma assinatura sobre o cabeçalho DNS nem carrega provas suficientes para qualquer destinatário refazer o raciocínio.

Scott Rose aparece com Roy Arends, Rob Austein, Matt Larson e Dan Massey como coautor das RFCs 4033, 4034 e 4035. O desenho coletivo não transformou um campo minúsculo em prova universal. Separou onde ocorre a validação, como seu resultado chega ao próximo participante e qual confiança ainda é necessária nesse limite.

Quatro estados não cabem em um único sinalizador

A RFC 4033 descreve quatro resultados gerais para uma resolução ciente de segurança: Secure, Insecure, Bogus e Indeterminate. Secure indica uma cadeia válida sob uma âncora aceita. Insecure é um estado não assinado demonstrável. Bogus corresponde a dados que deveriam validar, mas falharam nos testes. Indeterminate cobre o que a informação ou a política disponível não permite classificar.

AD não codifica os quatro estados. Ativado, comunica o resultado positivo previsto nas regras. Desativado, comporta várias explicações: os dados podem estar legitimamente Insecure, o resolvedor talvez não valide, a consulta pode não ter solicitado o retorno do bit, ou outro estado ou política pode estar em jogo. Traduzir sempre AD=0 como “DNSSEC falhou” apaga distinções que o protocolo oferece.

A RFC 6840 esclarece ainda a consulta. O solicitante pode ativar AD nela para declarar que entende e deseja o sinalizador, mesmo sem pedir os registros DNSSEC por meio de DO. O resolvedor validador deve colocar AD na resposta apenas quando a condição de validação for satisfeita e a consulta contiver DO ou AD. Assim, os mesmos dados validados podem chegar sem o bit a um cliente que não anunciou nenhuma dessas capacidades. A ausência sozinha não reconstitui o estado interno do resolvedor.

Um bit positivo tampouco diz que todos os resolvedores chegariam à mesma conclusão. Âncoras de confiança e políticas locais podem diferir; o tempo, o cache e a resposta observada também. O DNSSEC define a mecânica, e AD informa como um resolvedor específico a aplicou a uma resposta específica.

O bit não protege o pacote que o transporta

Se um atacante puder alterar o tráfego entre o stub e o resolvedor, não precisará falsificar uma assinatura DNSSEC para enganar um cliente que confia cegamente em AD. Poderá mudar um bit de cabeçalho não assinado, substituir a resposta ou interferir no canal. O cliente passará a confiar em uma afirmação cujo transporte jamais autenticou.

A RFC 3655 fixou esse limite antes da suíte definitiva: um stub alheio à segurança não deve confiar cegamente em AD, salvo quando se comunica com um resolvedor recursivo confiável por transporte seguro ou autenticação de mensagem. A RFC 4033 preserva a arquitetura. Delegar a validação exige confiar tanto no servidor recursivo quanto no canal. Para essa propriedade, integridade e autenticação importam; confidencialidade, sozinha, não torna o veredito confiável.

As condições são independentes. Um canal autenticado até um resolvedor não confiável apenas identifica quem produziu uma resposta duvidosa. Um resolvedor confiável por um canal alterável não pode responder pelo que chegou ao cliente. A combinação sustenta a validação delegada.

Um stub validador segue outro caminho. A RFC 4035 orienta que ele ignore AD e realize a própria validação. Pode usar os registros DNSSEC recebidos como insumo, mas o veredito vem da cadeia conferida sob sua configuração. O bit externo é uma observação, não a autoridade.

“Resolvedor confiável” é uma relação operacional

Não deveria ser apenas um rótulo de produto. O cliente precisa saber qual serviço pretende usar, autenticar a troca de modo adequado e aceitar a política de validação aplicada. Configurar um endereço não prova que todos os intermediários preservam a conclusão.

Por isso, centralizar a validação muda a governança, não só o processamento. O operador escolhe âncoras, versões, exceções, comportamento de falha e duração do cache. Clientes que recebem apenas o resumo herdam essas decisões. A centralização pode ser a arquitetura certa, mas AD não elimina a dependência: apenas a compacta.

A trajetória de Rose mostra por que a fronteira continua atual. Seu perfil no NIST menciona proteção da infraestrutura da Internet e protocolos seguros. Em março de 2026, o NIST publicou nova revisão do Secure Domain Name System Deployment Guide, de Scott Rose, Cricket Liu e Ross Gibson. Ali, DNSSEC aparece como sistema operacional contínuo: assinar uma zona é só uma parte; configuração do resolvedor, uso protegido dos resultados e monitoramento preservam a evidência até a decisão.

A atribuição deve ser precisa. Rose é um dos cinco coautores da suíte central, não inventor único do DNSSEC nem controlador de suas implementações. As RFCs 3655 e 6840 têm outros autores. Sua relevância está na arquitetura duradoura que ajudou a estabelecer: autenticação tem escopo, e o consumidor deve saber de quem recebe a conclusão.

Um veredito DNS não é um veredito do aplicativo

Mesmo calculado corretamente e entregue por canal autenticado, AD termina na fronteira dos dados DNS. Ele pode sustentar que certos RRsets foram autenticados sob a cadeia DNSSEC do resolvedor. Não prova que um servidor web está íntegro, um endereço IP é benigno, um certificado é aceitável, um destinatário tem autorização ou uma transação deve ocorrer.

Aplicativos combinam DNS com autenticação TLS, verificação de certificado e nome, autorização de conta, regras de atualidade, políticas de conteúdo, regras de negócio e intenção humana. Alguns protocolos incorporam registros autenticados por DNSSEC a uma decisão maior. É uma composição valiosa, mas continua sendo composição. A aplicação deve identificar o registro, o veredito, a propriedade do canal e o teste posterior que justificaram a ação.

Uma trilha que guarda apenas AD=true elimina essas dependências. Um registro melhor separa o estado e a política do resolvedor, a entrega autenticada desse estado e o uso ou rejeição pelo aplicativo. Se a ação der errado, será possível distinguir validação defeituosa, conclusão alterada no trajeto e autoridade excessiva concedida ao DNS.

O bit Authenticated Data não é decorativo nem mágico. É uma declaração compacta de um validador específico sobre dados específicos. O uso disciplinado preserva o trabalho realizado sem fantasiar confiança delegada de prova fim a fim.

Fontes