Resumo

  • A RFC 3090 trocou estados por algoritmo e a categoria “experimentalmente segura” por três atributos: globalmente segura, localmente segura e não segura.
  • O resolvedor ainda produzia uma decisão binária a partir de suas próprias âncoras, algoritmos, evidências da delegação e rota de validação.

A assinatura de uma zona não configurava o mundo inteiro

O DNSSEC inicial se expandia em trechos. Uma zona podia assinar seus registros antes que o pai conseguisse ligá-la a uma cadeia confiável desde a raiz. Um laboratório podia instalar diretamente a chave em resolvedores participantes. Outros resolvedores não tinham esse ponto de partida. Chamar a zona apenas de “segura” misturava o trabalho feito pela autoridade com a capacidade de quem consultava.

A RFC 3090 separou quatro perspectivas. O administrador definia a condição da zona; o servidor de atualização dinâmica tinha de preservá-la; o pai fazia uma declaração sobre o filho; o resolvedor decidia se conseguia validar os dados. Assinatura do filho, transição do pai e confiança local pertenciam a operadores diferentes.

O documento eliminou um estado distinto para cada algoritmo e removeu “experimentalmente segura”. Para as máquinas que possuíam a chave do experimento, a zona era uma ilha localmente segura. Para o restante da Internet, era não segura. O teste selecionava observadores; não criava outra espécie de segurança.

A ilha aparecia somente a quem conhecia a raiz certa

Zonas assinadas consecutivas podiam formar uma ilha abaixo de um pai não seguro. Ao configurar a chave do topo da ilha como âncora, o resolvedor conseguia validar seus descendentes sem uma cadeia confiável a partir da raiz global.

Dois resolvedores corretos podiam então discordar sobre os mesmos dados. Um tinha a âncora e uma rota aceitável e via a zona como localmente segura. O outro não tinha origem confiável e a via como não segura. O conteúdo autoritativo permanecia idêntico; a diferença estava no estado do verificador.

Com várias âncoras, a origem precisava ser bem escolhida. A “raiz de segurança mais próxima” de RFC 3090 era a configuração com a maior correspondência ordenada de rótulos à direita do nome consultado. Partir de uma raiz mais distante podia encontrar uma chave NULL e concluir insegurança, mesmo existindo uma ilha configurada mais perto. Ilhas sobrepostas tornavam a escolha do ponto inicial parte do diagnóstico.

Uma assinatura capturada não basta. O registro da validação precisa incluir âncoras ativas, lógica de seleção, algoritmos suportados, material obtido, horário e política. O resultado pertence àquela montagem e àquele instante; não é uma qualidade eterna do arquivo de zona.

O pai às vezes afirmava segurança por meio da ausência

Na arquitetura de RFC 2535, um pai seguro podia representar um filho seguro pela ausência da KEY do filho, enquanto uma chave NULL assinada indicava um filho não seguro. A afirmação positiva podia ser silêncio, e a negativa deixava um objeto assinado.

A RFC 3090 chamou o arranjo de contraintuitivo e operacionalmente desconfortável. Ela esclareceu a interpretação, sem substituir o mecanismo. Portanto, a simples falta de um registro não era prova. Era necessário estabelecer que o pai era seguro, que a ausência fazia parte do contexto autenticado e que aquelas regras históricas eram as aplicáveis.

A RFC 3658 introduziu DS; as RFCs 4033, 4034 e 4035 formaram a arquitetura moderna com DNSKEY, RRSIG, NSEC e DS no lugar de KEY, SIG e NXT. Esses textos mostram a mudança, mas não autorizam renomear retroativamente os objetos observados em 2001.

Global era uma classificação exigente, não uma garantia perfeita

Uma zona globalmente segura precisava de algoritmos obrigatórios, cadeia de assinaturas parentais dentro da árvore, KEY apropriada no ápice, cobertura NXT e assinaturas dos conjuntos exigidos. Uma zona localmente segura podia usar outros algoritmos ou caminho pré-configurado fora da árvore, mantendo as propriedades de zona assinada. O restante era não seguro.

“Global” e “local” descreviam atributos, não certificavam conformidade. Um resolvedor restritivo reconheceria apenas a primeira classe; outro, com capacidade ou configuração adicional, aceitaria parte da segunda. Na consulta, cada um ainda emitia apenas seguro ou não seguro.

Nem o rótulo mais forte eliminava comportamento incorreto. Um resolvedor defeituoso podia aceitar dados ruins; um pai comprometido podia interromper a operação. A contribuição da RFC 3090 foi separar as responsabilidades e mostrar como suas evidências se compunham, sem conceder autoridade universal a nenhum participante.

Fontes

  1. https://www.rfc-editor.org/info/rfc3090
  2. https://www.rfc-editor.org/rfc/rfc3090.html
  3. https://www.rfc-editor.org/rfc/rfc3090.txt
  4. https://datatracker.ietf.org/doc/rfc3090/
  5. https://www.rfc-editor.org/errata/rfc3090
  6. https://www.rfc-editor.org/rfc/rfc2535.html
  7. https://www.rfc-editor.org/rfc/rfc3007.html
  8. https://www.rfc-editor.org/rfc/rfc3008.html
  9. https://www.rfc-editor.org/rfc/rfc3658.html
  10. https://www.rfc-editor.org/rfc/rfc4033.html
  11. https://www.rfc-editor.org/rfc/rfc4034.html
  12. https://www.rfc-editor.org/rfc/rfc4035.html
  13. https://www.rfc-editor.org/rfc/rfc5011.html