Resumo

  • A chave de autenticação pertencia à zona, não aos servidores que guardavam cópias; por isso o resolvedor podia avaliar o dado assinado sem conceder confiança automática ao caminho de entrega.
  • Servidores antigos ainda eram úteis como armazenamento e transporte de KEY, SIG e NXT, mas podiam exigir buscas extras e não resolviam os casos de CNAME, delegação ou indicação autenticada.
  • O RFC assumia dados DNS públicos e iguais para todos: não introduzia confidencialidade, listas de acesso nem garantia sobre o host que usava o endereço autenticado.

Um servidor de cache responde rapidamente e com autoridade operacional. Ainda assim, a pergunta de segurança é outra: quem autorizou o conjunto de registros que chegou? O RFC 2065 tornou essa diferença verificável ao anexar evidência criptográfica aos próprios objetos DNS.

O texto dizia que a chave de origem da zona não era a chave dos servidores que distribuíam suas cópias. Um servidor comprometido podia ocultar dados, recusar serviço ou tentar repetir material antigo. Sem a chave privada, porém, não ganhava automaticamente a capacidade de criar uma assinatura nova e válida. A posse da rota de entrega deixava de equivaler à autoria da afirmação.

Chave, dado e transação não eram a mesma coisa

O documento definiu três serviços. O primeiro, distribuição de chaves públicas, usava o registro KEY para associar uma chave a um nome. O resolvedor ainda precisava de um ponto inicial configurado por via confiável. A partir daí, chaves assinadas podiam estender uma cadeia por zonas seguras. O sistema localizava a confiança; não a eliminava.

O segundo serviço autenticava origem e integridade dos dados. SIG indicava o tipo coberto, o signatário, o algoritmo, o TTL original, início, expiração e assinatura. Uma verificação bem-sucedida sustentava uma proposição limitada sobre um RRset, sob uma chave e dentro de uma janela. Não autenticava todo o pacote por proximidade.

NXT criava evidência para nomes ou tipos inexistentes. A forma mudou nas gerações seguintes, mas o problema permanecia distinto: ausência de resposta não é prova assinada de ausência.

O terceiro serviço era a autenticação opcional de transações e pedidos. O RFC deixou claro que uma assinatura da mensagem não autenticava, sozinha, os RRs nela contidos. Segurança do intercâmbio e autoridade sobre o conteúdo tinham recibos diferentes.

A borda verificava o que o meio apenas carregava

O RFC preservava o protocolo DNS na rede e acrescentava tipos de registro. Um servidor minimamente compatível precisava armazenar e devolver KEY, SIG e NXT, inclusive em transferência de zona. Isso permitia que software sem lógica criptográfica servisse dados necessários a um validador.

O ganho cobrava latência. Um servidor consciente de segurança tentava incluir a assinatura correspondente na resposta. Um servidor comum talvez só atendesse ao tipo pedido. O resolvedor então consultava todos os SIG daquele nome e selecionava os que cobriam o RRset de interesse. A rede podia migrar de forma desigual, mas a complexidade não desaparecia; mudava para quem decidia confiar.

CNAME era uma fronteira explícita. O processamento tradicional podia seguir o alias antes de devolver os registros de segurança no nome original. A conformidade completa precisava tratar esse caso, construir respostas aprimoradas, compreender delegações e implementar os bits AD e CD.

AD afirmava que o servidor que respondia havia verificado os dados. CD permitia que um resolvedor criptograficamente capaz recebesse material ainda pendente de verificação no servidor. Sistemas antigos deixavam os bits zerados. Isso mantinha compatibilidade, mas não produzia um atestado.

A assinatura não congelava o cache

O TTL cai durante o armazenamento, enquanto uma assinatura deixa de verificar se o valor assinado muda. O RFC conciliou as duas regras incluindo em SIG o TTL original e os limites temporais da assinatura. O cache podia encurtar a retenção, nunca alongá-la acima do original assinado. Depois da expiração, a assinatura não valia mesmo que os bytes ainda estivessem disponíveis.

A hora do resolvedor também entrava no sistema de confiança. Um relógio atrasado maliciosamente podia aceitar uma assinatura antiga. A validação dependia de fonte de tempo, ancoragem, política de cache e custódia de chaves. Nenhum desses elementos era provado pelo simples sucesso do transporte.

Integridade pública não era privacidade

O RFC 2065 começou seus limites pela filosofia pública do DNS. As respostas deveriam ser iguais para os solicitantes; não se tentou criar listas de acesso ou distinguir quem podia perguntar. Também não se ofereceu confidencialidade para consulta ou resposta. Uma proteção de canal, como IPsec, teria de cumprir esse papel separadamente.

Além disso, uma resposta autenticada sobre endereço não autenticava a máquina que estava usando aquele endereço naquele instante. Não impedia captura de pacotes, substituição do host ou falsificação fora da camada DNS. O resultado “válido” precisava ser levado à aplicação com mais controles.

Um começo que aceitava ser substituído

O Datatracker mostra versões do rascunho entre 1994 e 1996 e publicação em 1997; não mostra quantos servidores o executaram. O RFC 2535 substituiu o 2065 em 1999 e declarou incorporar experiência inicial de implementação e pedidos de possíveis usuários. A família formada pelos RFCs 4033, 4034 e 4035 substituiu essa geração em 2005.

Ler o mecanismo moderno diretamente para trás apagaria mudanças reais. É mais seguro acompanhar a continuidade da divisão de trabalho: o signatário produz prova sobre dados; o servidor os disponibiliza; o resolvedor decide a partir de âncoras e relógio; a aplicação protege o restante.

A noção posterior de Lu Heng de uma especificação inicial mínima ajuda a interpretar, mas não documenta a intenção dos autores. O RFC concentrava o acordo comum em estruturas e verificações, sem exigir que todo servidor intermediário tivesse a mesma capacidade. Publicar a regra não provava adoção; transportar o dado não concedia autoridade para interpretá-lo.

Fontes