Resumen

  • El RFC 2065 hizo que la evidencia viajara con los conjuntos de registros: la zona firmaba y el resolutor verificaba, aunque un servidor intermedio no supiera ejecutar criptografía.
  • La convivencia tenía costes y excepciones: consultas extra para recuperar SIG, problemas con CNAME y distintos niveles de conformidad para servidores y resolutores.
  • La firma no ofrecía secreto, selección de usuarios ni garantía sobre el host alcanzado después de resolver el nombre.

Un paquete llega desde un caché conocido. Eso prueba que el caché lo envió; no demuestra quién autorizó el dato que contiene. El RFC 2065, publicado como Proposed Standard en enero de 1997, quiso hacer esa diferencia computable. En lugar de convertir cada salto en una raíz de confianza, añadió objetos que un resolutor podía comprobar por sí mismo.

El texto asignaba la clave de autenticación a la zona, no a los servidores que guardaban copias de sus datos. La consecuencia era concreta. Si un atacante tomaba un servidor, podía degradar disponibilidad, omitir material o ofrecer datos antiguos. Sin la clave privada de la zona, no podía fabricar sin más una nueva firma válida. El control del transporte y el control de la afirmación dejaban de coincidir.

Tres promesas con recibos diferentes

El RFC separó distribución de claves, autenticación de origen e integridad, y autenticación opcional de transacciones o peticiones.

KEY asociaba claves públicas con nombres DNS. La cadena no nacía de la nada: el resolutor necesitaba al menos una clave inicial configurada de forma fiable. Desde ella podía verificar claves firmadas de otras zonas seguras. Era una arquitectura de confianza explícita, no una eliminación de la confianza.

SIG autenticaba registros de un tipo concreto. Incluía el firmante, el algoritmo, el TTL original, los instantes de creación y caducidad y la firma criptográfica. Su alcance era preciso: un RRset podía considerarse autorizado y razonablemente actual bajo una clave trazable. La presencia de ese RRset junto a otros datos no extendía la firma a todo el mensaje.

NXT proporcionaba una forma de probar la inexistencia de nombres o tipos. Aunque la evolución posterior sustituyó ese diseño, el principio ya era claro: no recibir algo no equivale a recibir una negación autenticada.

La firma opcional de una transacción tampoco sustituía las firmas de zona. El propio RFC avisaba de que autenticar el intercambio no autenticaba cada RR incluido. El canal podía demostrar una conversación; los SIG adecuados demostraban el origen de los datos.

La compatibilidad se compró con más trabajo del resolutor

Para añadir autenticación de origen no fue necesario abandonar el formato DNS. Bastaba, en el nivel mínimo, con que servidores y resolutores pudieran almacenar y devolver los nuevos tipos. Un servidor sin conocimiento de seguridad podía actuar como depósito y mensajero.

Pero el mensajero no siempre preparaba el paquete ideal. Un servidor consciente intentaba enviar la firma correspondiente junto a los registros solicitados. Un servidor ordinario podía obligar al resolutor a pedir todos los SIG del nombre y escoger los que cubrían el tipo deseado. La migración ahorraba una sustitución coordinada de toda la red, a cambio de latencia y lógica adicionales en el borde que verificaba.

Los CNAME marcaban el límite más visible. El comportamiento tradicional de seguir el alias podía impedir recuperar el material de seguridad del nombre original. Por eso el documento distinguía conformidad mínima y completa. La mínima era conservar, transferir y responder KEY, SIG y NXT. La completa añadía generación e inclusión automática, tratamiento correcto de alias y delegaciones y soporte de los bits AD y CD.

AD comunicaba que el servidor había verificado los datos devueltos. CD permitía que un resolutor dispuesto a hacer la criptografía recibiera datos todavía no comprobados por el servidor. En el software antiguo ambos bits eran cero. Aquello evitaba romper el protocolo, pero el cero no era una declaración positiva de autenticidad.

Una firma tenía dos relojes alrededor

El TTL de una respuesta almacenada disminuye. Si ese valor variable se firmara tal cual, cada segundo rompería la firma. El RFC 2065 incluyó en SIG el TTL original y separó la validez criptográfica mediante instantes de inicio y caducidad. Un caché podía acortar la vida útil, pero no ampliarla más allá del límite firmado. Cuando la firma expiraba, el registro dejaba de estar autenticado aunque siguiera ocupando memoria.

También era necesaria una hora razonablemente segura. Un reloj manipulado hacia atrás podía hacer creer vigente una firma antigua. La automatización de validación dependía, por tanto, de custodia de claves, tiempo, política de caché y trazabilidad; no únicamente de que una consulta hubiera terminado con éxito.

El DNS seguro seguía siendo público

El RFC no escondió sus renuncias. El diseño del DNS suponía datos públicos y respuestas iguales para todos los consultantes. No se añadieron listas de acceso ni una forma de distinguir quién tenía derecho a leer. Tampoco se cifraron consultas o respuestas; el texto remitía esa función a una protección de canal separada, como IPsec.

La autenticidad del dato no resolvía la seguridad posterior. Verificar la dirección asociada a un nombre no impedía que una máquina no autorizada ocupara esa dirección ni que el tráfico fuera interceptado. DNSSEC reducía la incertidumbre sobre el RRset. No certificaba toda la sesión de aplicación.

La revisión fue parte del método

El historial del IETF conserva borradores entre 1994 y 1996 y la publicación del RFC en enero de 1997. No ofrece un censo de despliegues. Dos años después, el RFC 2535 sustituyó al 2065 e indicó que recogía experiencia temprana de implementación y peticiones de posibles usuarios. En 2005, los RFC 4033, 4034 y 4035 sustituyeron esa generación.

No conviene leer las revisiones posteriores como si todos sus detalles hubieran estado presentes desde el inicio. Sí puede seguirse una continuidad de responsabilidades: el firmante produce evidencia, el servidor la transporta, el resolutor decide si una cadena anclada y temporalmente válida basta, y otros protocolos protegen lo que queda fuera.

La idea de Lu Heng sobre una especificación inicial mínima aporta una comparación posterior. No documenta la intención de los autores del RFC. Sirve para observar que las reglas comunes podían concentrarse en objetos verificables, mientras la adopción y la decisión de aceptar quedaban en sistemas que ejecutaban el código. La interoperabilidad no exigía conferir soberanía al intermediario.

Fuentes