Resumo

  • A RFC 3655 trocou um rótulo amplo sobre a política do servidor por uma indicação mais limitada: os RRsets relevantes da resposta haviam sido autenticados pelas regras revisadas.
  • AD é um relato do resolvedor, não uma assinatura do pacote DNS nem uma prova de que o resolvedor, a rota ou a política de confiança do usuário sejam confiáveis.

Análise

A cena começa com uma aplicação que consulta um nome por meio do resolvedor local. O stub encaminha a pergunta a um resolvedor recursivo, capaz de percorrer a cadeia de chaves, buscar assinaturas e aproveitar o cache. Na resposta, um bit do cabeçalho pode informar à aplicação sobre o trabalho feito a montante. A questão central não é o tamanho do campo, mas quem pode fazer essa afirmação e qual evidência ela resume.

A RFC 2535 dava ao bit Authenticated Data (AD) um sentido amplo: o servidor dizia que os dados das seções Answer e Authority estavam autenticados de acordo com sua política. Publicada em novembro de 2003, a RFC 3655 argumentou que o sinal não era muito útil na prática. Um servidor conforme já deveria evitar devolver dados que falhassem na sua política de segurança; assim, AD descrevia principalmente a postura geral do servidor, não o estado específico daquela resposta.

A revisão tornou o repasse mais preciso. Um servidor recursivo não deveria definir AD se os RRsets relevantes em Answer e Authority não satisfizessem as condições de autenticação. O bit deveria ser definido quando os registros da resposta — e os registros pertinentes que sustentam uma resposta negativa — estivessem autenticados. Isso não significa que cada pacote DNS passou a carregar sua própria assinatura. DNSSEC autentica conjuntos de registros; AD resume o julgamento local do resolvedor para aquela resposta.

Essa diferença também separa DO e CD de AD. DO pede a inclusão de registros DNSSEC; a RFC 3655 exigia que esses registros tivessem sido solicitados e que os SIG relevantes fossem retornados antes de AD ser definido. CD desativa a checagem naquela consulta. Isso não apagava AD automaticamente: o servidor ainda podia marcar dados previamente verificados ou aceitos pela política local. Cada bit descreve uma etapa: pedir evidência, controlar a checagem e relatar o resultado.

Com isso, a RFC 3655 colocou o resolvedor recursivo como intermediário de confiança. As aplicações não precisavam, cada uma, implementar um validador completo e podiam reaproveitar o cache. Mas o stub não podia tratar AD como uma prova que se autentica sozinha. Era preciso confiar explicitamente no resolvedor e proteger a comunicação — por canal seguro ou autenticação de mensagem, como TSIG ou SIG(0). Sem isso, um respondente no caminho que definisse AD estaria fazendo uma alegação sobre validação, não entregando evidência segura de validação.

A regra para servidores autoritativos mostrou outra fronteira. Um servidor primário de uma zona segura podia ser configurado para definir AD, mas isso precisava ser explícito e deveria vir desativado por padrão. O documento reconhecia que um autoritativo não tinha obrigação de validar os dados da própria zona; verificar assinaturas ao carregar a zona ou em cada consulta podia ter custo operacional. Portanto, AD em uma resposta autoritativa direta não prometia, por padrão, validação igual à de um resolvedor recursivo.

AD=0 também é fácil de interpretar demais. A RFC 3655 proibia AD em uma resposta insegura, mas o bit apagado, sozinho, não dizia se os dados eram inseguros, se o resolvedor não os verificou, se faltava um registro DNSSEC solicitado ou se o servidor preferiu não afirmar aquele estado. AD=1 só tem sentido dentro da relação de confiança; AD=0 não é um diagnóstico completo.

Em 2005, as RFCs 4033, 4034 e 4035 revisaram o conjunto DNSSEC e tornaram obsoleta a RFC 3655. O repasse de estado por AD permaneceu, agora dentro de uma explicação mais completa sobre validadores, stubs, autoritativos e caminhos de autenticação. A RFC 3655 é melhor entendida como o reparo de uma interface estreita: levar a avaliação do resolvedor até a aplicação sem fingir que o bit do cabeçalho era prova criptográfica.

A cadeia de evidências tem camadas. Uma RRSIG pode sustentar a autenticação de um RRset por meio da cadeia de chaves e de uma âncora de confiança. O resolvedor validador toma uma decisão local. AD pode reportar essa decisão. Um canal seguro com um resolvedor confiável pode vincular a resposta ao serviço que o consumidor escolheu. Nenhum desses fatos, isoladamente, prova que o titular do domínio seja honesto, que a informação esteja atual para a aplicação ou que ela tenha agido com segurança.

Fontes