Summary

  • Un borrador nuevo del grupo DNSOP propone que, con un algoritmo UNIVERSAL en el conjunto DS o de anclas y ninguno FORMERLY-UNIVERSAL, la zona firme al menos con uno de los universales; las demás firmas serían opcionales.
  • Los algoritmos 8 y 13 estrenarían la categoría UNIVERSAL. El registro actual de IANA ya exige implementarlos para validar, pero aún no contiene la nueva columna que pide el borrador.
  • Si un resolvedor desactiva localmente uno de esos algoritmos anunciados, trataría la zona como no firmada aunque pueda usar otro algoritmo anunciado. La decisión del operador cambia el estado de seguridad de la respuesta.

La zona DNS firma con dos algoritmos porque no sabe cuál entenderá cada resolvedor. El resolvedor, sin embargo, acepta una sola cadena de validación correcta. Esa asimetría está en RFC 4035 y en la precisión de RFC 6840: el emisor produce firmas para cada algoritmo presente en los registros pertinentes; el receptor puede quedarse con un camino válido. El proyecto que acaba de entrar en DNSOP quiere dejar de cobrar al emisor por firmas que ningún receptor necesita, bajo condiciones estrictas.

La factura no es solo de CPU. Según el modelo de RFC 8901, dos proveedores pueden firmar una misma zona con claves independientes. Cuando usan algoritmos diferentes, la exigencia de firmar con todos crea una dependencia entre empresas que justamente se contrataron para aportar resiliencia. Cambiar de proveedor abre un intervalo parecido. Preparar una nueva ancla de confianza antes de introducir todas sus firmas puede evitar una fase extensa de doble firma, especialmente incómoda en una zona de gran escala.

«Universal» no es una medalla decorativa

El borrador solicita a IANA una columna nueva, Validation support status, con valores UNIVERSAL, FORMERLY-UNIVERSAL o vacío. Su primera propuesta asigna UNIVERSAL a RSA/SHA-256, número 8, y ECDSA P-256/SHA-256, número 13. Ambos figuran hoy como obligatorios de implementar para validación. No hay ningún algoritmo inicialmente FORMERLY-UNIVERSAL. La nueva etiqueta convertiría la expectativa de soporte en un permiso concreto para reducir firmas.

La regla mira los DS publicados por el padre o las anclas de confianza. Si allí hay al menos un UNIVERSAL y ninguno que haya perdido esa condición, basta firmar con un UNIVERSAL; las demás firmas son optativas. También puede limitarse la publicación de DNSKEY a los algoritmos con los que realmente se firma. Sin UNIVERSAL, o con cualquier FORMERLY-UNIVERSAL, siguen siendo obligatorias las firmas de todos. Una zona no obtiene libertad por anunciar dos algoritmos cualquiera: la composición y la historia de soporte importan.

Eso deja que dos proveedores con algoritmos 8 y 13 sirvan rutas válidas distintas. También permite anunciar una futura ancla de confianza antes de producir su DNSKEY y sus firmas. Un proveedor podría probar un algoritmo poscuántico adicional sin imponerlo simultáneamente a todos sus socios. Si el algoritmo nuevo no es UNIVERSAL, completar la sustitución puede seguir exigiendo un período de doble firma.

El interruptor local tiene consecuencias públicas

Supongamos una zona que anuncia 8 y 13. Un proveedor sirve una firma válida con 8. Un administrador ha desactivado 8 en su resolvedor por política propia, aunque el programa todavía admite 13. El borrador indica que ese resolvedor debe clasificar la zona como no firmada. No puede cargar al proveedor con un resultado bogus y SERVFAIL solo porque la firma presentada usa un algoritmo obligatorio que él decidió apagar.

Es una redistribución de responsabilidad. El operador de la zona actúa confiando en el registro común. El administrador del resolvedor se aparta de esa expectativa. La consulta puede devolver datos, pero en ese resolvedor ya no hay autenticación DNSSEC para la zona. Un panel que solo muestre respuestas exitosas escondería la decisión más importante. La clasificación insecure debe aparecer en pruebas, métricas y cambios de configuración.

La regla anterior perseguía una amenaza legítima: un atacante no debe borrar las firmas que el resolvedor sí entiende y convertir una respuesta segura en una respuesta aparentemente insegura sin alarma. El proyecto afirma conservar esa protección mediante las categorías UNIVERSAL y FORMERLY-UNIVERSAL. Para ello el resolvedor debe recordar incluso los algoritmos que fueron universales y luego quedaron desactivados. Olvidar esa historia cambia los resultados de seguridad.

La versión 00 está fechada el 31 de octubre de 2026 y apenas es un documento inicial del grupo de trabajo. No trae una medición de resolvedores desplegados ni de fallos causados por el nuevo esquema. El dato que falta a un operador concreto es una prueba cruzada: cada proveedor sirve su subconjunto de firmas, cada resolvedor declara secure, insecure o bogus con los algoritmos activados y desactivados. Esa tabla vale más que una promesa genérica de «compatibilidad con DNSSEC».

El borrador plantea un trato claro. Los firmantes dejan de coordinar firmas redundantes por temor al resolvedor desconocido. El resolvedor que impone un veto privado debe poner su nombre a la pérdida de autenticación. La comodidad de recibir una respuesta no puede disfrazar la ausencia de verificación.

Borrador IETF · RFC 4035 · RFC 6840 · RFC 8901 · Registro IANA