Resumo

  • A RFC 9718 separa o material da chave raiz DNSSEC dos mecanismos que autenticam o arquivo de distribuição; nem a AC da ICANN nem a PKI da Web são a âncora DNSSEC.
  • Uma âncora utilizável exige cinco avaliações distintas: arquivo autêntico, período elegível, representações coerentes, interpretação compatível e aceitação explícita do operador.

É simples explicar uma cadeia de confiança de cima para baixo. O validador começa com uma chave confiável, verifica a raiz e segue delegações assinadas. A pergunta desconfortável aponta para cima: quem verificou a primeira chave?

A RFC 4033 não esconde a fronteira. Uma âncora é uma DNSKEY autoritativa ou um resumo DS configurado no validador, e seu valor inicial precisa chegar por um meio seguro ou confiável fora do DNS. O DNSSEC autentica o que vem depois da âncora, não a decisão que a tornou confiável.

Esse é o valor duradouro da RFC 9718, coassinada por Joe Abley e publicada como RFC Informational da IETF em janeiro de 2025. Ela substitui a RFC 7958 e especifica como a IANA publica informações sobre âncoras da zona raiz. Não elimina a confiança fora de banda; dá nome às suas emendas.

A primeira emenda separa o objeto de seu envelope. A IANA publica um XML com registros KeyDigest. Uma assinatura CMS destacada pode formar cadeia até uma autoridade certificadora controlada pela ICANN; o HTTPS pode autenticar a entrega pela PKI da Web. Esses mecanismos ajudam a confirmar a origem esperada do documento e sua integridade.

Mas a AC da ICANN não é uma âncora DNSSEC, diz a RFC. A cadeia de certificados autentica o objeto publicado. O resumo ou a chave pública dentro dele só pode se tornar uma âncora após processamento e aceitação. Chamar ambos de “raiz de confiança” apaga dois sistemas diferentes e o instante em que o operador muda o estado do validador.

A mudança em relação à RFC 7958 torna a separação mais nítida. O modelo antigo incluía certificados PKIX e pedidos de assinatura para cada chave, além de um mecanismo OpenPGP destacado. A RFC 9718 os remove porque misturavam confiança fora de banda nas chaves de autenticação com confiança fora de banda nas chaves raiz DNSSEC. Mais embalagem criptográfica não eliminava a decisão inicial.

O XML também contém estados independentes. validFrom e validUntil delimitam quando um KeyDigest pode ser usado. Não provam instalação generalizada nem a ordenam. Um arquivo corretamente assinado, porém antigo, não é automaticamente uma configuração atual aceitável.

O publickeyinfo opcional pode incluir uma chave pública DNSKEY e flags junto do resumo. Ele permite formar material DNSKEY diretamente, mas cria uma obrigação de coerência: se chave pública e resumo divergirem, aquele KeyDigest não deve ser usado. Uma assinatura CMS válida não corrige contradição interna.

A opcionalidade também revela capacidade local. Dois processadores conformes podem gerar conjuntos diferentes a partir do mesmo XML autêntico se apenas um compreender publickeyinfo. Origem comum não garante interpretação uniforme; versão do analisador, transformação e saída pertencem ao comprovante operacional.

Até o atributo source do XML é apenas informativo. Uma URL localiza o documento; não ganha autoridade por aparecer nele. Localização não é mandato.

Por fim vem a aceitação. A RFC 9718 permite ao operador decidir, conforme sua política, se aceitará as âncoras. A IANA publica; sistemas de certificados ajudam a verificar origem; implementadores interpretam; fornecedores empacotam; operadores decidem o que entra no estado de confiança do resolvedor.

A RFC 5011 não elimina a primeira escolha. Ela permite que um validador que já confia numa âncora aprenda sucessoras dentro do protocolo após períodos de observação. A confiança existente autentica a transição, mas não consegue justificar retroativamente a instalação original.

A página atual da IANA mostra os objetos concretos: root-anchors.xml contém os dados, root-anchors.p7s a assinatura destacada e icannbundle.pem os certificados usados para validá-la. Também observa que fornecedores distribuem atualizações de maneiras e em momentos diferentes.

No aviso de novembro de 2024, a IANA pediu recuperação regular do XML e testes do formato revisado. Publicação bem-sucedida não é implantação bem-sucedida: o arquivo pode ser autêntico e atual enquanto um analisador o rejeita, um pacote permanece antigo ou um operador decide não adotá-lo.

O root-anchors.xml vigente é o objeto legível por máquinas, não uma declaração de que qualquer resolvedor específico aceitou suas entradas.

A biografia da NSRC registra que Abley liderou DNS Operations na ICANN e participou da implantação do DNSSEC na raiz. Isso não o torna soberano da raiz. Ajuda a explicar a disciplina operacional do documento: provas adjacentes não devem fingir que são a mesma prova.

Um recibo auditável deve guardar cinco respostas: como origem e conteúdo foram verificados? A entrada estava dentro da vigência? Suas representações coincidiam? Qual analisador produziu a âncora candidata? Quem a aceitou, em qual validador e segundo qual regra? “Assinatura válida” responde apenas à primeira pergunta.