Resumen

  • DNSSEC convirtió una respuesta DNS negativa en evidencia verificable al firmar los límites ordenados que rodean los nombres y tipos de registro ausentes.
  • NSEC3, Opt-Out y el uso del caché validado distribuyen divulgación, cómputo, garantía sobre delegaciones y el momento en que un nombre nuevo puede empezar a funcionar.

Imaginemos un archivo donde cada expediente presente lleva una firma auténtica. Eso no demuestra que el encargado no haya escondido el documento solicitado. Para acreditar una ausencia hace falta además un catálogo firmado cuyo orden muestre el hueco.

Ese fue el cambio conceptual del rechazo autenticado de DNSSEC.

El DNS normal responde NXDOMAIN si un nombre no existe, o sin datos si el nombre existe pero no tiene el tipo de registro solicitado. Sin validación DNSSEC, esa negativa solo es tan fiable como el trayecto de la respuesta. Para un adversario en ruta, hacer desaparecer un servicio puede ser tan útil como desviar su dirección.

RFC 4034 dio a una zona firmada una forma de describir sus huecos. Un registro NSEC nombra al siguiente propietario autoritativo en el orden canónico de la zona e incluye un mapa de los tipos presentes en el nombre actual. RFC 4035 define la validación: si la consulta cae entre dos límites firmados, el intervalo prueba que no existe ese nombre exacto. Si el nombre existe pero falta el tipo pedido en el mapa firmado, la prueba se refiere al tipo. Un error de nombre también debe descartar un comodín que pudiera haber respondido.

No hace falta crear un registro negativo para cada pregunta posible. El espacio de etiquetas sería inabarcable. La prueba es el intervalo ordenado: dos hechos autenticados delimitan un espacio vacío.

La primera prueba mostraba demasiado

La claridad de NSEC tiene otra consecuencia. Como cada registro apunta al siguiente nombre autoritativo, un consultante paciente puede recorrer la cadena y reconstruir la zona.

Este recorrido no revela datos que el DNS estuviera diseñado para cifrar, pero una lista fácil de enumerar puede exponer patrones de nombres, servicios de apariencia interna o un mapa de reconocimiento. El validador necesita límites precisos; el operador no siempre quiere entregar un índice legible.

RFC 5155 introdujo NSEC3. Conserva la cadena pero sustituye los nombres visibles por hashes. El validador aún puede probar que el hash consultado cae dentro de un intervalo firmado; quien enumera debe adivinar etiquetas fuera de línea.

Es fricción, no secreto. Los nombres comunes son previsibles y aparecen en certificados, registros y enlaces. RFC 9276 advierte del rendimiento decreciente: más iteraciones exigen más trabajo a servidores y validadores sin convertir nombres adivinables en información confidencial.

Opt-Out incorpora el precio de la escala

En zonas enormes y llenas de delegaciones, mantener un NSEC3 por cada hijo no firmado puede consumir firma y memoria. Opt-Out permite que un tramo cubra delegaciones inseguras sin que cada una tenga su propio registro hash.

El ahorro es real y también lo es la renuncia. RFC 5155 señala que un tramo Opt-Out no afirma si dentro de él existe una delegación insegura. Otros datos autoritativos siguen protegidos, pero la prueba es deliberadamente menos completa en ese límite. La zona obtiene cambios de delegación más baratos a cambio de no respaldar la misma afirmación criptográfica para cada hijo no firmado.

Por eso Opt-Out es una decisión de gobierno, no un ajuste neutro. Define qué ausencias respalda el operador. RFC 9276 lo desaconseja para zonas pequeñas y solo contempla su utilidad en zonas de delegación muy grandes, dinámicas y con pocos hijos firmados.

Un hueco en caché puede responder después

RFC 8198 permite a un resolvedor validador reutilizar agresivamente intervalos NSEC o NSEC3 almacenados. Si una pregunta posterior cae en un tramo ya probado como vacío, puede sintetizar la respuesta negativa sin volver al servidor autoritativo.

Así disminuyen la latencia, la carga y las consultas que revelan información; también puede amortiguarse parte de un ataque con etiquetas aleatorias. Pero el caché aplica una declaración firmada a preguntas futuras, de modo que su vigencia se convierte en una condición operativa.

RFC 8198 explica que los TTL de NSEC o NSEC3, junto con la caché negativa de la zona, determinan cuándo puede empezar a funcionar un nombre recién creado. Si se publica justo después de una prueba amplia de ausencia, algunos validadores todavía estarán autorizados a responder “no”. El protocolo funciona bien; el plan de cambio ignoró la vida útil de la evidencia negativa.

La práctica actual premia la sencillez

RFC 9276 recomienda NSEC cuando no hacen falta las funciones de NSEC3. Si NSEC3 es necesario, exige cero iteraciones adicionales y recomienda sal vacía. Las iteraciones extra aumentan el cómputo, el riesgo de agotamiento de CPU y los fallos de interoperabilidad; una sal fija aporta poco porque el nombre completo ya hace que el cálculo sea específico de cada zona.

También recomienda probar nombres deliberadamente inexistentes en los secundarios tras cambiar parámetros. Los registros positivos pueden parecer sanos mientras la cadena negativa está desactualizada, no coincide o resulta demasiado costosa para uno de los servidores.

Estas RFC describen el protocolo y la práctica vigente; no demuestran que un operador concreto los aplique bien. La calidad debe medirse en las fronteras autoritativas y validadoras reales.

Fuentes