Resumen
- Un intervalo NSEC3 con Opt-Out puede abarcar una delegación insegura existente y no afirmar nada sobre su existencia. Recorrer los nodos firmados no produce una copia autenticada de todas las delegaciones del padre.
- La aceptación operativa exige reconciliar el registro fuente, la generación del firmante, cada autoridad y la conducta del validador. «No aparece en la cadena» debe quedar como indeterminado, no convertirse en ausente.
En una revisión ficticia, dos equipos entregan conclusiones opuestas. El primero reconstruye una cadena NSEC3 con firmas válidas y no encuentra el hash de un nombre hijo. El segundo consulta al padre y recibe los NS de la delegación, pero ningún DS. Ninguno ha falsificado datos. Uno observó la proyección de negación; el otro, la delegación insegura que esa proyección podía omitir.
El problema empieza cuando una herramienta asigna a la primera superficie la autoridad de la segunda.
RFC 5155 define NSEC3 para negar datos mediante nombres hasheados. Cuando un record lleva el bit Opt-Out, su tramo puede cubrir cero o más delegaciones sin DS. Ese tramo no afirma que tales delegaciones existan ni que no existan. Precisamente por eso el padre puede incorporarlas o retirarlas sin reconstruir los nodos vecinos de la cadena.
La firma protege esa afirmación limitada. No autentica una conclusión de inventario que el protocolo excluyó deliberadamente.
El padre mantiene una lista que el anillo no reemplaza
El inventario fuente contiene nombres de delegación, NS, glue aplicable, DS, estado de provisión y autorización del cambio. El firmante recibe esa realidad y produce otra cosa: una estructura ordenada en espacio de hash para responder pruebas de existencia y no existencia.
Cada NSEC3 lleva algoritmo, flags, iteraciones, sal, siguiente hash y bitmap de tipos. Si existe un nodo coincidente, el bitmap puede demostrar qué RRsets hay en el nombre original. Si un intervalo cubre el hash pertinente, puede participar en una prueba negativa. Nada de eso convierte los hashes en una exportación reversible de la zona.
La clasificación previa importa. Un hijo con NS y DS es una delegación segura. Un hijo con NS y sin DS es inseguro. Opt-Out puede excluir el owner hash del segundo, no cualquier nombre que resulte cómodo omitir. Los nombres autoritativos y las delegaciones seguras conservan sus requisitos de representación. Un hueco sin relación con una delegación elegible es un defecto, no una optimización.
Por eso cada omisión necesita expediente propio: nombre original, estado NS/DS, hash calculado, intervalo cubriente, bit Opt-Out, generación del firmante y respuestas observadas en todas las autoridades relevantes.
Tres resultados, no dos
Los productos de inventario suelen ofrecer presente o ausente. Opt-Out exige un tercer estado: no determinable desde esta cadena.
Si el hash cae en un intervalo Opt-Out, la cadena no permite decidir si una delegación insegura existe dentro. El consumidor debe acudir a una superficie competente: la base de provisión, una transferencia autorizada o las consultas directas al padre. La consulta DS distingue la relación de confianza; la referencia NS muestra la delegación servida. Ninguna firma NSEC3 sustituye esos hechos.
La regla se refleja en RFC 8198. Un resolvedor validador puede reutilizar rangos NSEC/NSEC3 para sintetizar respuestas negativas y evitar consultas repetidas. No puede hacerlo para un nombre cubierto por un NSEC3 Opt-Out, porque el record no demuestra que ese nombre sea inexistente.
La prohibición evita que una optimización de caché transforme una no-afirmación en NXDOMAIN. Un auditor o motor de seguridad debería ser al menos igual de cuidadoso.
La prueba puede detenerse antes del ancestro real
Las reglas de wildcard usan el closest encloser: el ancestro existente más largo del nombre consultado. En una zona Opt-Out, una delegación omitida o un empty non-terminal derivado solo de ella puede carecer de nodo NSEC3. Entonces la prueba utiliza el closest provable encloser, el ancestro cuya existencia sí puede demostrar la cadena.
La diferencia explica por qué conviene conservar el mensaje completo. Nombre consultado, records NSEC3, RRSIG, parámetros, bitmap, hash cubierto, next-closer, posible vuelta del intervalo y hora de validación forman una unidad. Guardar únicamente «validó» impide saber si el sistema probó ausencia o se encontró ante un espacio donde Opt-Out prohibía esa conclusión.
La política moderna reduce trabajo inútil
RFC 9276 recomienda NSEC cuando no se necesitan las propiedades particulares de NSEC3. Cuando NSEC3 sí se usa, el punto de partida recomendado es algoritmo 1, cero iteraciones adicionales y sal vacía.
Más iteraciones consumen CPU en autoridades y validadores y pueden crear fallos de interoperabilidad. La sal no vuelve secretos los nombres previsibles. Un resolvedor puede considerar insegura una prueba con iteraciones superiores a su política, devolver SERVFAIL o, después de validar el record aplicable, emitir EDE 27. Esa respuesta describe sus límites de procesamiento; no prueba que el nombre no esté delegado.
Opt-Out tampoco es una opción general. No se recomienda para zonas pequeñas. Puede tener sentido en zonas enormes y centradas en delegaciones, con una gran mayoría de hijos inseguros y alta rotación. La decisión debe apoyarse en cifras actuales, no en una plantilla heredada del firmante.
Cambiar la cadena requiere observar la flota
Cambiar sal o iteraciones genera una cadena nueva y exige volver a firmar la zona. NSEC3PARAM no es por sí solo la prueba que consume el validador; los parámetros decisivos viajan en los NSEC3 que se verifican.
La activación debe comparar inventario fuente, salida del firmante, serial o identificador de generación, RRSIG, primario y secundarios. Las sondas incluyen un nombre inexistente conocido, una delegación insegura omitida, una delegación segura y un límite wildcard. Después se repiten contra cada dirección autoritativa.
Si la flota sirve dos generaciones fuera de la transición prevista, el operador no debe esconder la divergencia tras una métrica de disponibilidad. Conserva la última generación coherente, mide TTL y expiración de firmas y decide si completar o revertir.
Fuentes
- RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence
- RFC 9276 — Guidance for NSEC3 Parameter Settings
- RFC 8198 — Aggressive Use of DNSSEC-Validated Cache
- RFC 4033 — DNS Security Introduction and Requirements
- RFC 4034 — Resource Records for DNS Security Extensions
- RFC 4035 — Protocol Modifications for DNS Security Extensions
- RFC 4592 — The Role of Wildcards in the Domain Name System
- RFC 6840 — DNS Security Clarifications
- RFC 6781 — DNSSEC Operational Practices, Version 2
- RFC 7129 — Authenticated Denial of Existence in the DNS
- IANA — DNSSEC NSEC3 Parameters
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
