Resumo

  • O RFC 3445 limitou novos KEY ao valor de protocolo 3, DNSSEC, porque a consulta só escolhia o tipo e a assinatura abrangia todos os membros do RRset.
  • A retirada foi assimétrica: parar de escrever valores antigos, mas preservá-los durante a leitura e verificação, pois eliminá-los alterava o conjunto assinado e podia dividir caches.

Um recipiente universal sem seleção interna

No RFC 2535, KEY levava flags, octeto de protocolo, algoritmo e chave pública. O valor 1 era email, 2 IPsec, 3 DNSSEC, 4 TLS; 5–254 podiam ser atribuídos e 255 abrangia qualquer protocolo. A proposta reutilizava DNS como prateleira comum.

Mas o cliente pedia KEY, não um protocolo dentro do RDATA. Recebia o RRset completo do nome. A assinatura DNSSEC também cobria o conjunto, não a parte pertinente. O formato permitia muitos propósitos, enquanto busca e prova operavam em um só bloco.

Publicado em dezembro de 2002, o RFC 3445 transformou problemas de implantação experimental limitada em uma fronteira. O texto, registro editorial, Datatracker, histórico, referências, citações e errata provam o documento, não a extensão da implantação.

Seis diferenças dentro da mesma forma

As chaves divergiam em finalidade, administrador, autenticação, inclusão pelo servidor autoritativo, tratamento pelo resolvedor e consequência de falha ou comprometimento. DNSSEC sustenta a integridade dos dados DNS; uma chave de aplicação não possui significado especial para DNS.

O RRset misto crescia com usos alheios, ampliava respostas e amarrava ciclos independentes. Código que ignorasse o protocolo ainda poderia tratar uma chave de aplicação comprometida como chave de zona. Criptografia correta não conserta uma atribuição errada de autoridade.

O RFC 3445 restringiu novos dados autoritativos ao protocolo 3, reservou todas as flags exceto o bit de zona 7 e fechou 1, 2, 4, 255 e a faixa aberta. Novas atribuições passaram a exigir Standards Action. Permaneceram os usos DNSSEC ligados ao RFC 2930, RFC 2931 e RFC 3007, não a antiga distinção host/usuário.

Rejeitar autoridade sem apagar evidência

Um valor diferente de 3 não podia autenticar DNS, mas deveria continuar presente durante a validação. A assinatura fora calculada sobre o RRset original. Retirar um membro antes de verificar SIG criava outro objeto; filtros diferentes também faziam caches discordarem.

O princípio de migração separava uso semântico de preservação probatória: fechar a produção, manter compreensão suficiente, negar autoridade e remover somente após convergência demonstrada. “Não confiar” não é sinônimo de “não analisar”.

Os RFC 4033, 4034 e 4035 depois substituíram a família 2535 com DNSKEY. SSHFP, CERT e TLSA ilustram recipientes específicos, sem provar causalidade única. A IANA registra símbolos; não certifica código, adoção ou segurança.

O menor conjunto que compartilha regras reais

As camadas da realidade de Heng Lu separam valor registrado, assinatura válida, autoridade administrativa, execução e resultado. Um recipiente não funde essas provas. A primazia do código em funcionamento dá peso ao experimento que revelou custos de consulta, assinatura e cache, sem transformar código em soberano.

A especificação inicial mínima favorece padronizar o menor núcleo com propósito, verificação e falha comuns. DNS podia governar sua chave de infraestrutura sem governar toda chave de aplicação. É interpretação editorial, não alegação sobre intenção pessoal.

Forma de fio comum não cria domínio de confiança comum. Se consulta, assinatura e cache obrigam objetos a mover-se juntos, a fronteira desse conjunto já é uma fronteira de segurança e responsabilidade.

Fontes