Resumen

  • RFC 9718 separa el material de la clave raíz DNSSEC de los mecanismos que autentican el archivo que lo distribuye; ni la CA de ICANN ni la PKI web son el ancla DNSSEC.
  • Un ancla utilizable exige cinco juicios distintos: archivo auténtico, periodo válido, representaciones coherentes, análisis compatible y aceptación explícita del operador.

Una cadena de confianza se explica fácilmente de arriba abajo. El validador parte de una clave confiable, verifica la raíz y sigue delegaciones firmadas. La pregunta incómoda apunta hacia arriba: ¿quién verificó la primera clave?

RFC 4033 no oculta el límite. Un ancla es una DNSKEY autorizada o un resumen DS configurado en un validador, y su valor inicial debe obtenerse por un medio seguro o confiable fuera del DNS. DNSSEC autentica lo que sigue al ancla, no la decisión que convirtió el ancla en confiable.

Ese es el aporte duradero de RFC 9718, coescrito por Joe Abley y publicado como RFC informativo del IETF en enero de 2025. Sustituye a RFC 7958 y especifica la publicación por IANA de información sobre anclas de la zona raíz. No elimina la confianza fuera de banda: hace visibles sus uniones.

La primera unión separa el objeto de su envoltorio. IANA publica un XML con registros KeyDigest. Una firma CMS separada puede encadenarse a una autoridad certificadora controlada por ICANN; HTTPS puede autenticar la entrega bajo la PKI web. Esos mecanismos ayudan a comprobar que el documento viene del editor esperado y conserva su contenido.

Pero la CA de ICANN no es un ancla DNSSEC, advierte el RFC. La cadena de certificados autentica el objeto publicado. El resumen o la clave pública dentro de él solo puede convertirse en ancla DNSSEC después del procesamiento y la aceptación. Llamar “raíz de confianza” a ambos borra dos sistemas diferentes y oculta el momento en que el operador altera el estado del validador.

El cambio respecto de RFC 7958 agudiza esa separación. El diseño anterior incluía certificados PKIX, solicitudes de firma por clave y un mecanismo OpenPGP separado. RFC 9718 los retira porque mezclaban la confianza fuera de banda en claves de autenticación con la confianza fuera de banda en las claves raíz DNSSEC. Añadir envoltorios criptográficos no suprimía la decisión inicial.

El XML alberga varios estados independientes. validFrom y validUntil delimitan cuándo un KeyDigest puede utilizarse. No acreditan su instalación universal ni la ordenan. Un archivo bien firmado pero antiguo no constituye automáticamente una configuración actual aceptable.

El campo opcional publickeyinfo puede incluir una clave pública DNSKEY y sus flags junto al resumen. Permite construir material DNSKEY directamente, pero también obliga a comprobar coherencia: si la clave y el resumen discrepan, ese KeyDigest no debe usarse. Una firma CMS válida no repara una contradicción interna.

La opcionalidad también revela capacidad local. Dos procesadores conformes pueden obtener conjuntos distintos del mismo XML auténtico si uno entiende publickeyinfo y otro no. La procedencia común no garantiza interpretación común; versión del analizador, transformación y salida deben formar parte del recibo operativo.

Incluso el atributo source del XML es meramente orientativo. Una URL localiza un documento, pero no adquiere autoridad por estar escrita dentro de él. Un localizador no es un mandato.

Después llega la aceptación. RFC 9718 permite que el operador decida bajo su propia política si acepta las anclas. IANA publica; los sistemas de certificados apoyan la verificación del origen; los implementadores analizan; los proveedores empaquetan; y el operador decide qué entra en el estado de confianza del resolutor.

RFC 5011 no elimina la primera decisión. Permite que un validador que ya confía en un ancla aprenda sucesoras dentro del protocolo tras periodos de observación. La confianza existente autentica la transición, pero no puede justificar retroactivamente la instalación inicial.

La página vigente de IANA muestra las superficies concretas: root-anchors.xml porta los datos, root-anchors.p7s la firma separada e icannbundle.pem los certificados para validarla. También señala que los proveedores distribuyen actualizaciones de formas y en momentos diferentes.

En su aviso de noviembre de 2024, IANA pidió recuperar el XML regularmente y probar el formato revisado. Publicar con éxito no equivale a desplegar con éxito: el archivo puede ser auténtico y oportuno mientras un analizador lo rechaza, un paquete queda atrasado o un operador no lo adopta.

El root-anchors.xml vigente es el objeto legible por máquinas, no una declaración de que un resolutor concreto haya aceptado sus entradas.

La biografía de NSRC registra que Abley dirigió DNS Operations en ICANN y participó en el despliegue de DNSSEC en la raíz. Eso no lo convierte en soberano de la raíz. Explica, en cambio, la disciplina operativa del RFC: ninguna prueba adyacente debe suplantar a otra.

Un recibo auditable debe conservar cinco respuestas: ¿cómo se verificaron origen y contenido? ¿Estaba la entrada dentro de su periodo? ¿Coincidían sus representaciones? ¿Qué analizador produjo el ancla candidata? ¿Quién la aceptó, en qué validador y bajo qué regla? “Firma válida” solo responde la primera pregunta.