DNSSEC NSEC3: mitos — cuándo ayuda y cuándo perjudica el rendimiento

NSEC3 en una pantalla: qué es y qué no es

DNSSEC no solo firma los registros que sí tienes. También debe proporcionar una prueba criptográfica para los registros que no existen. Si un
resolutor pregunta por does-not-exist.example, no puedes simplemente decir “no.” Sin prueba, un atacante podría falsificar
respuestas negativas y hacer desaparecer nombres enteros.

De eso tratan NSEC y NSEC3: negación de existencia autenticada. Permiten a un servidor autoritativo probar —criptográficamente— que el
nombre (o tipo) solicitado no existe en la zona.

NSEC (el directo)

Con NSEC, la zona contiene punteros de “siguiente” en orden de nombres en texto claro. Una respuesta negativa incluye un registro NSEC que
prueba: “el nombre solicitado cae entre estos dos nombres existentes, por lo tanto no existe.” Simple, eficiente y amigable para la caché.

La desventaja: NSEC permite enumeración trivial de la zona (“zone walking”). Cualquiera puede consultar nombres sucesivos y recuperar
el conjunto completo de nombres de propietario en la zona, incluso si AXFR está bloqueado.

NSEC3 (el con hash)

NSEC3 sustituye nombres en texto por nombres hasheados. En lugar de enlazar a.example → b.example, enlaza
HASH(a) → HASH(b). Las respuestas negativas incluyen registros NSEC3 que contienen nombres de propietario hasheados.
Esto pretende dificultar el zone walking al requerir que un atacante adivine nombres y los hashee (posiblemente con múltiples iteraciones y
una sal) para coincidir con lo que hay en la zona.

Observa lo que no hace: no oculta tu zona de la adivinación dirigida. Si tus nombres son predecibles, NSEC3 convierte la enumeración en
un ataque por diccionario, no en una capa mágica de secreto.

El modelo mental más corto y útil: NSEC es más rápido y filtra información; NSEC3 es más lento y filtra menos, pero no es secreto.

Los mitos de NSEC3 que no mueren

Mito 1: “NSEC3 evita el zone walking, así que evita el reconocimiento.”

NSEC3 evita el zone walking trivial. No impide que adivinen nombres. Si tu organización usa vpn, mail,
autodiscover, api, dev, stage, prod, y crees que un hash va a detener el
reconocimiento… tengo malas noticias.

Los atacantes no necesitan recorrer tu zona cuando ya has nombrado cosas como los humanos. Adivinarán. Harán fuerza bruta. Usarán wordlists.
Usarán logs de certificate transparency y DNS pasivo. NSEC3 solo eleva el coste de la enumeración ciega.

Mito 2: “Más iteraciones NSEC3 siempre significa más seguridad.”

NSEC3 soporta hashing con iteraciones. Más iteraciones aumentan el coste de adivinar nombres. También aumentan el coste de firmado y, dependiendo
de la implementación y la precomputation, pueden incrementar la carga CPU en la autoridad y la fricción operativa.

La industria se ha alejado de iteraciones altas porque el beneficio en el mundo real es tenue y los costes no lo son. Los recuentos altos
de iteraciones no te protegen de nombres obvios. Protegen de… alguien que adivine etiquetas aleatorias de 20 caracteres. Si ese es tu modelo
de amenaza principal, perfecto. Si no, estás pagando por un apartamento vacío.

Mito 3: “NSEC3 siempre es ‘más seguro’ que NSEC.”

La seguridad no es un eje único. NSEC3 reduce la divulgación de nombres de propietario, pero incrementa la complejidad y el tamaño de las
respuestas. También amplía el radio de desastre por mala configuración porque depurar negaciones de existencia hasheadas es más difícil que
leer una cadena NSEC.

En términos de fiabilidad: NSEC3 es un intercambio. Deberías adoptarlo solo si quieres lo que ofrece.

Mito 4: “NSEC3 arreglará los problemas de SERVFAIL después de activar DNSSEC.”

Si obtienes SERVFAIL tras habilitar DNSSEC, probablemente tienes firmas rotas, registros DS faltantes, RRSIGs caducados, una mala
elección de algoritmo, un rollover de claves roto o problemas de MTU/fragmentación. Cambiar NSEC a NSEC3 no es una reparación; es cambiar las
ruedas porque la luz del motor está encendida.

Broma #1 (corta, relevante): NSEC3 es como poner lunas tintadas a un coche sin frenos. Cambia lo que ven los externos, no si te detienes.

Mito 5: “Si no usamos NSEC3, no cumplimos.”

La mayoría de los marcos de cumplimiento se preocupan de que DNSSEC esté desplegado correctamente y que las claves se gestionen. Rara vez se
exige NSEC3. Algunas organizaciones lo eligen como política para “reducir la enumeración.” Es una elección, no un requisito universal.

Cuándo NSEC3 ayuda de verdad

1) Tus nombres de zona son realmente inadivinables y te importa la divulgación

Si usas etiquetas aleatorias (piensa: tokens por cliente, hostnames largos estilo UUID o estructuras de delegación que preservan privacidad),
NSEC3 puede aumentar materialmente el coste de enumerarlas. En esos nichos, la cadena en texto claro de NSEC es un error evitable.

2) Estás en un entorno hostil de reconocimiento y tu nombrado es disciplinado

Algunas empresas logran mantener nombres previsibles fuera del DNS público y solo exponen lo estrictamente necesario. Para ellas, NSEC3 puede
ser un control significativo para “hacerlo molesto.” No es una bala de plata. Es una molestia. La molestia tiene valor.

3) Gestionas un TLD firmado o una zona pública grande y hay presión de política

En registros y algunas zonas públicas sometidas a escrutinio, la divulgación de todas las delegaciones puede tener implicaciones comerciales
y de abuso. Incluso si la enumeración es posible por otros canales, NSEC3 puede adoptarse para evitar dar una lista limpia vía DNS.

4) Puedes pagar la sobrecarga operativa

Esta es la parte que la gente omite en la revisión de seguridad. NSEC3 requiere parametrización correcta, comportamiento de firmado consistente
entre autoridades y monitorización cuidadosa. Si no puedes comprometerte a eso, es mejor ejecutar NSEC correctamente que ejecutar NSEC3 mal.

Dónde NSEC3 perjudica el rendimiento (y por qué)

Inflación del tamaño de paquetes: las respuestas negativas engordan

DNSSEC ya incrementa el tamaño de las respuestas por RRSIGs y DNSKEYs. Las respuestas negativas pueden ser peores porque la prueba de negación
requiere registros adicionales (NSEC/NSEC3 más sus firmas). Las respuestas NSEC3 suelen contener múltiples registros NSEC3 para cubrir pruebas
de closest encloser y negación de wildcard, y cada uno lleva nombres de propietario hasheados y parámetros.

Respuestas UDP grandes disparan la fragmentación, que provoca pérdida, que provoca reintentos, que provoca retroceso a TCP. Pensaste que
activaste “más seguridad”; en realidad activaste “más estado en firewalls y balanceadores.”

Coste CPU: hashear y firmar no es gratis

NSEC3 usa hashing (SHA-1 en el diseño original). Los servidores autoritativos suelen precalcular las cadenas NSEC3 en el momento del firmado,
pero zonas con actualizaciones dinámicas, re-firmado frecuente o herramientas pobres pueden desplazar trabajo al camino de servicio o incrementar
la churn de firmado.

Incluso cuando se precalcula, la construcción de pruebas negativas más complejas incrementa rutas de código y patrones de acceso a memoria. En
una flota autoritativa ocupada, lo notarás como mayor CPU por consulta y menores ratios de acierto en caché (porque hay más pruebas negativas
distintas circulando).

Dolor en el lado del resolutor: validación y reintentos más feos

Los validadores no aman respuestas grandes y fragmentadas. Aman respuestas consistentes y cacheables. NSEC tiende a ofrecer propiedades de
caché más limpias para la inexistencia porque es simple y estable. La naturaleza hasheada de NSEC3, más la semántica opt-out (en algunos
despliegues), puede llevar a más trabajo en el resolutor, más consultas y más tiempo gastado recorriendo pruebas.

Depuración operativa: los humanos no leen hashes

Con NSEC puedes mirar una respuesta y entender qué se está probando. Con NSEC3 entrecierras los ojos ante blobs en base32 y te preguntas si
invocaste a un demonio por accidente.

Broma #2 (corta, relevante): Depurar NSEC3 a simple vista es como revisar un incidente de almacenamiento desde volcados hex. Técnicamente
posible. Espiritualmente imprudente.

Middleboxes: la parte de internet que aún te odia

DNSSEC depende de EDNS(0) para búferes UDP mayores. Algunas redes aún tratan mal EDNS, UDP fragmentado o respuestas DNS grandes. NSEC3 puede
empujarte más a menudo por encima de umbrales de tamaño, convirtiendo “caso marginal raro” en “ticket diario.”

Opt-out: trampas de rendimiento y política

Opt-out de NSEC3 se diseñó para reducir la carga de firmado en zonas con muchas delegaciones inseguras (común en registros). Puede reducir el
recuento de registros y el tamaño de la respuesta en esos casos. También puede crear malentendidos sobre qué está autenticado y qué no.
Si tu equipo no puede explicar opt-out claramente, probablemente no deberías desplegarlo a la ligera.

Hechos e historia: cómo llegamos aquí

• NSEC llegó primero: la negación autenticada originalmente usó NXT, luego NSEC, que exponía directamente el orden de nombres de la zona.
• El zone walking no fue una sorpresa: era una propiedad obvia de NSEC y la comunidad debatió años si importaba.
• NSEC3 se introdujo para abordar la enumeración: añadió hashing (más sal e iteraciones) para dificultar la divulgación masiva.
• NSEC3 usa SHA-1: no porque sea “moderno”, sino porque se estandarizó cuando SHA-1 era la elección pragmática para este caso.
• Las iteraciones fueron un “dial” en etapas tardías: la idea era subir el coste de ataques offline por adivinación; en la práctica creó drama de ajuste.
• Las respuestas grandes se convirtieron en el verdadero enemigo: a medida que DNSSEC se desplegó, las fallas operativas a menudo vinieron de tamaño/fragmentación UDP en vez de pura criptografía.
• Opt-out se diseñó para registros: pretendía mantener NSEC3 factible para zonas con enormes números de delegaciones inseguras.
• El tooling operativo quedó rezagado: los primeros despliegues sufrieron porque monitorización y workflows de depuración eran inmaduros respecto a hoy.
• Muchos operadores ahora prefieren la simplicidad: para muchas zonas, la lección ha sido “usa NSEC salvo que tengas una razón para no hacerlo.”

Una cita, porque pertenece a cada discusión de ops. Werner Vogels (CTO de Amazon) dijo: “Everything fails, all the time.” Esa mentalidad aplica
aquí: diseña elecciones de DNSSEC alrededor de los modos de fallo que puedes sobrevivir, no de la perfección teórica.

Guía rápida de diagnóstico

El objetivo no es convertirse en un erudito de DNSSEC mientras los usuarios hacen timeout. El objetivo es encontrar el cuello de botella rápido:
CPU autoritativa, pérdida/fragmentación de paquetes, fallos de validación en resolutores o estado de firmado roto.

Primero: confirma si el problema son respuestas negativas o todo

• Muestra consultas para nombres existentes y nombres NXDOMAIN. Si NXDOMAIN es desproporcionadamente lento o provoca TCP más a menudo, NSEC3 es
  un sospechoso principal.
• Observa tamaños de respuesta. Si estás regularmente por encima de ~1232 bytes, estás en la “ruleta de fragmentación” para muchas redes.

Segundo: revisa fragmentación, reintentos y retroceso a TCP

• Captura en el borde autoritativo. Si ves queries repetidas, respuestas truncadas (TC=1) o muchas sesiones TCP/53, estás pagando el impuesto de tamaño.
• Verifica el comportamiento EDNS desde redes cliente reales. No confíes en un único punto de vista desde una LAN corporativa limpia.

Tercero: valida la cadena DNSSEC y las pruebas de negación

• Usa un resolutor validador y herramientas que muestren la prueba de negación de existencia. Confirma la validez de RRSIG y la cobertura correcta de NSEC3.
• Busca errores de rollover de clave o expiración de firmas. Se disfrazan de “rendimiento” porque desencadenan reintentos y caminos alternativos.

Cuarto: aísla el coste en el servidor

• Observa CPU autoritativa y qps bajo carga. Si la CPU sube con la tasa de NXDOMAIN, puede que estés haciendo trabajo NSEC3 dinámico o sufriendo fallos de caché.
• Comprueba si tu signer está thrashing (re-firmado demasiado frecuente, demasiadas claves, validez de firma corta o cambios pobres de parámetros NSEC3).

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas reales que puedes ejecutar durante un incidente o un martes tranquilo. Cada una incluye: comando, ejemplo de salida, qué significa y
qué decisión tomar.

Tarea 1: Compara tamaño y flags de respuesta positiva vs negativa

cr0x@server:~$ dig +dnssec +bufsize=1232 www.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 www.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 18 msec
;; MSG SIZE  rcvd: 412

cr0x@server:~$ dig +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1129
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 3600 900 1209600 300
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...
6JQ2K7...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 6K5... NS SOA RRSIG DNSKEY NSEC3PARAM
6JQ2K7...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...
9F8P1...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 B0T... A AAAA RRSIG
9F8P1...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 44 msec
;; MSG SIZE  rcvd: 1216

Qué significa: NXDOMAIN es ~3x más grande y más lento, y está coqueteando con el límite de búfer de 1232 bytes.

Decisión: Trata las respuestas negativas como el riesgo principal de rendimiento. Empieza a probar truncamiento y fragmentación a continuación.

Tarea 2: Comprueba el comportamiento de truncamiento (bit TC) con un búfer EDNS más pequeño

cr0x@server:~$ dig +dnssec +bufsize=512 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9001
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

Qué significa: Con un búfer más pequeño, el servidor establece TC=1 y espera que el cliente vuelva a intentar por TCP.

Decisión: Si muchos clientes actúan efectivamente así (EDNS roto, búferes pequeños), verás picos de TCP. Planea mitigaciones.

Tarea 3: Confirma que el retroceso a TCP funciona y mídelo

cr0x@server:~$ dig +tcp +dnssec does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7711
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; Query time: 96 msec
;; MSG SIZE  rcvd: 1216

Qué significa: TCP funciona pero suele costar ~2–5x latencia frente a UDP en muchos entornos.

Decisión: Si fuerzas a los clientes a TCP con frecuencia, estás construyendo outages latentes. Reduce el tamaño de las respuestas o mejora el path MTU.

Tarea 4: Inspecciona la presencia de NSEC vs NSEC3 en la zona

cr0x@server:~$ dig +dnssec example.com NSEC3PARAM @ns1.example.net

;; ANSWER SECTION:
example.com. 300 IN NSEC3PARAM 1 0 10 A1B2C3D4
example.com. 300 IN RRSIG NSEC3PARAM 13 2 300 20260204000000 20260114000000 12345 example.com. ...

Qué significa: La zona usa NSEC3 con algoritmo 1, flags 0, iteraciones 10 y sal A1B2C3D4.

Decisión: Si las iteraciones son altas “por seguridad,” revísalo. Si no tienes un modelo de amenaza concreto, prefiere iteraciones bajas o NSEC.

Tarea 5: Comprueba si las respuestas negativas incluyen múltiples registros NSEC3

cr0x@server:~$ dig +dnssec +norecurse nohost.sub.example.com A @ns1.example.net

;; AUTHORITY SECTION:
... NSEC3 ...
... NSEC3 ...

Qué significa: Estás obteniendo pruebas de closest-encloser y negación de wildcard. Esto es normal y aumenta el tamaño.

Decisión: Espera que NXDOMAIN pese más que las respuestas positivas. Si este patrón es de alto volumen (errores tipográficos, escáneres), optimiza para ello.

Tarea 6: Revisa QPS y CPU del autoritativo durante ráfagas de NXDOMAIN

cr0x@server:~$ sudo rndc stats
cr0x@server:~$ sudo tail -n 12 /var/named/data/named_stats.txt
++ Incoming Requests ++
[View: default]
                17642 QUERY
                 8810 NXDOMAIN
++ Name Server Statistics ++
               1420010 IPv4 requests received
                  9901 TCP requests received

Qué significa: NXDOMAIN es una gran fracción y las peticiones TCP no son triviales.

Decisión: Trata NXDOMAIN como carga. Considera limitar la tasa de respuestas para patrones abusivos, ajustar el uso de wildcard y reducir el tamaño de respuestas negativas.

Tarea 7: Verifica fragmentación UDP DNS en la interfaz del servidor

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 and udp -vv -c 6
tcpdump: listening on eth0, link-type EN10MB
12:00:01.100000 IP 198.51.100.20.53534 > 203.0.113.53.53: UDP, length 67
12:00:01.100500 IP 203.0.113.53.53 > 198.51.100.20.53534: UDP, length 1492
12:00:01.100520 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 1492:1480@0+
12:00:01.100540 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 220@1480

Qué significa: Estás enviando respuestas UDP fragmentadas. Algunas redes descartan fragmentos. Eso se convierte en fallos DNS aleatorios.

Decisión: Reduce el tamaño de la respuesta UDP (política y opciones de firmado), o ajusta la estrategia EDNS/MTU. No ignores fragmentos en 2026.

Tarea 8: Prueba desde un resolutor validador para separar problemas “autoritativos” de “de validación”

cr0x@server:~$ dig +dnssec www.example.com A @9.9.9.9

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

Qué significa: ad indica que el resolutor validó DNSSEC con éxito.

Decisión: Si algunos validadores muestran ad y otros devuelven SERVFAIL, sospecha de ruta/fragmentación o caches obsoletas/rotas, no solo firmas.

Tarea 9: Usa delv para validar y mostrar por qué falla un nombre

cr0x@server:~$ delv +vtrace does-not-exist.example.com A @9.9.9.9
; fully validated
does-not-exist.example.com. 300 IN A ; negative response, NXDOMAIN

Qué significa: La prueba negativa se validó de extremo a extremo.

Decisión: Si delv falla con una queja de firma o negación de existencia, deja de afinar rendimiento y arregla la corrección primero.

Tarea 10: Verifica DS en el padre (la clásica comprobación “¿por qué hay SERVFAIL?”)

cr0x@server:~$ dig +dnssec example.com DS @a.gtld-servers.net

;; ANSWER SECTION:
example.com. 86400 IN DS 12345 13 2 3A1B...C9
example.com. 86400 IN RRSIG DS 13 1 86400 20260204000000 20260114000000 9999 com. ...

Qué significa: El padre publica un DS. Los validadores aplicarán las firmas para example.com.

Decisión: Si falta o es incorrecto, arregla la cadena de delegación antes de culpar a NSEC3. Un DS incorrecto crea fallo de validación universal.

Tarea 11: Comprueba ventanas de validez de RRSIG (desajuste de reloj y caducidad)

cr0x@server:~$ dig +dnssec example.com SOA @ns1.example.net | grep RRSIG
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...

Qué significa: Las firmas tienen tiempo de inicio y expiración. Si el reloj del signer está mal o permites firmas caducadas, los validadores fallarán.

Decisión: Si ves caducidad cercana con re-firmado lento, amplia la validez o ajusta la programación del signer. Corrección supera a la ingeniosidad.

Tarea 12: Mide la distribución de latencia autoritativa bajo carga

cr0x@server:~$ sudo dnstap-read /var/log/dnstap/dnstap.log | head -n 6
2010-01-01 12:00:01.100 CQ example.com/A udp 198.51.100.20:53534
2010-01-01 12:00:01.101 CR example.com/A NOERROR 1ms 412b
2010-01-01 12:00:02.200 CQ does-not-exist.example.com/A udp 198.51.100.21:53535
2010-01-01 12:00:02.260 CR does-not-exist.example.com/A NXDOMAIN 60ms 1216b

Qué significa: NXDOMAIN es más lento y más grande. Esa es la firma (juego de palabras intencionado) de la sobrecarga de negación de existencia más efectos de red.

Decisión: Si NXDOMAIN domina la latencia tail, trátalo como un requisito de producto: reduce el volumen de NXDOMAIN (typos, escáneres) o reduce el tamaño de la prueba.

Tarea 13: Inspecciona parámetros NSEC3 en BIND (si firmas allí)

cr0x@server:~$ grep -R "nsec3param" -n /etc/bind
/etc/bind/named.conf.local:42:    auto-dnssec maintain;
/etc/bind/named.conf.local:43:    inline-signing yes;
/etc/bind/named.conf.local:44:    nsec3param 1 0 10 A1B2C3D4;

Qué significa: Está activado inline signing y los parámetros NSEC3 están explícitos.

Decisión: Si heredaste esta configuración, cuestiónala. Si no tienes razón para NSEC3, elimina el parámetro y pasa a NSEC (cambio planificado), o baja las iteraciones.

Tarea 14: Comprueba problemas de cumplimiento EDNS desde una red cliente “mala”

cr0x@server:~$ dig +dnssec +edns=0 +bufsize=4096 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5150
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; MSG SIZE  rcvd: 1216

Qué significa: Desde este punto de vista EDNS funciona, pero eso no prueba que funcione para carriers móviles, proxies corporativos o dispositivos legacy.

Decisión: Si los incidentes se correlacionan con ciertas redes, asume interferencia EDNS/fragmentación y prioriza hacer que las respuestas entren en tamaños más seguros.

Tres mini-historias corporativas desde las trincheras DNS

Mini-historia 1: El incidente causado por una suposición errónea (“NSEC3 detendrá el reconocimiento, así que estamos a salvo”)

Una compañía SaaS mediana tenía una zona pública con muchos nombres de conveniencia internos publicados por accidente: jenkins,
grafana, vpn, staging-api. Nada explotable directamente, pero muchas migas.
Una revisión de seguridad señaló “zone walking vía NSEC” como fuga de información.

La respuesta del equipo fue rápida y ordenada: activar NSEC3, aumentar iteraciones “por seguridad”, desplegar. Declararon victoria y siguieron.
Nadie se hizo la pregunta incómoda: “Si alguien puede adivinar nuestros nombres, ¿qué logramos realmente?”

Unas semanas después recibieron una ola de password spraying dirigido contra los mismos servicios que la zona “ocultó.” El atacante no caminó nada.
Adivinó los nombres, los validó vía DNS y luego intentó credenciales comunes. NSEC3 hizo su trabajo —impidió una lista limpia— mientras no contribuyó
en nada contra la amenaza real, que era aburrida y predecible.

El postmortem fue doloroso porque la solución no fue “afinar iteraciones.” La solución fue higiene de nombres y control de exposición: quitar nombres
internos del DNS público, poner endpoints admin detrás de VPN y dejar de publicar CNAMEs de conveniencia que apuntaban a UIs de gestión.
NSEC3 no estaba equivocado; la suposición sí.

La coletilla operativa: la compañía mantuvo NSEC3 de todos modos, porque quitarlo parecería “reducir la seguridad.” Mientras tanto, el on-call
aprendió que el efecto medible más grande del proyecto fue un salto en tamaños de respuesta DNS y fallback a TCP ocasional.

Mini-historia 2: La optimización que salió mal (“subir iteraciones NSEC3 al infinito”)

Una gran empresa con una flota autoritativa global decidió estandarizar NSEC3 en todas partes. Realmente temían la enumeración masiva de subdominios
delegados y tenían narrativa de cumplimiento que lo respaldaba.

Alguien propuso aumentar significativamente las iteraciones NSEC3 “para ralentizar a los atacantes.” Sonaba razonable. El hashing es barato, ¿no?
Y su clúster autoritativo tenía margen en estado de calma.

Entonces llegó un evento de firmado: un rollover de clave coordinado más un cambio de contenido que tocó muchos nombres. La carga del signer saltó.
Las firmas tardaron más en regenerarse. El desfase de propagación aumentó. El equipo empezó a ver fallos de validación intermitentes desde ciertos
resolutores porque la zona quedó en un estado medio-actualizado más tiempo del esperado. Los usuarios lo vieron como: SERVFAIL aleatorio.

La respuesta al incidente se centró en “bugs de resolutores” y “la internet es inestable”, hasta que alguien correlacionó la línea temporal con el
cambio de parámetros NSEC3. Las iteraciones altas no solo “ralentizaron a los atacantes”—también ralentizaron la capacidad de la organización para
recuperarse y completar operaciones de firmado bajo churn.

Revirtieron a parámetros más sensatos e introdujeron una regla: nunca cambiar parámetros NSEC3 al mismo tiempo que un evento de claves. Además:
probar la capacidad de firmado como se prueba el tiempo de reconstrucción de almacenamiento—bajo condiciones peores, no en el happy-path en reposo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (monitorización estricta y disciplina “cabe en UDP”)

Una compañía de servicios financieros ejecutó DNSSEC durante años con mínimo drama. Su secreto no fue criptografía exótica. Fue disciplina:
monitorización de tamaño de respuesta, gestión predecible de claves y un playbook escrito para fallos de validación.

Eligieron NSEC para la mayoría de zonas. Para las pocas zonas que realmente se beneficiaban de NSEC3, mantuvieron parámetros conservadores y evitaron
recuentos de iteraciones gratuitos. Más importante: tenían un SLO: “Las respuestas DNSSEC deben caber dentro de un presupuesto UDP elegido para
la mayoría de respuestas negativas.” Si un cambio hacía respuestas más grandes, se trataba como una regresión.

Un día, una campaña DDoS pasó de tráfico volumétrico a inundación de NXDOMAIN contra su zona pública. El ataque no fue inteligente; fue consultas junk
de alta tasa diseñadas para forzar respuestas negativas costosas.

Como tenían métricas base, reconocieron el patrón en minutos: pico en ratio NXDOMAIN, aumento de tamaño en la cola, subida de fallback a TCP,
CPU autoritativa en tendencia ascendente. Activaron rate limiting para fuentes abusivas, ajustaron caché y filtrado en la puerta de entrada, y
volvieron a estabilidad. Nada heroico. No hubo hilos de Slack a medianoche “¿por qué DNS está roto?”

Lo bueno: el equipo pudo justificar decisiones “aburridas” previas con datos. NSEC no fue ideología; fue una elección de fiabilidad consciente
que mantuvo las respuestas negativas más pequeñas y fáciles de cachear.

Errores comunes: síntomas → causa raíz → arreglo

1) Síntoma: timeouts aleatorios, especialmente en redes móviles

Causa raíz: respuestas DNSSEC UDP fragmentadas (a menudo NXDOMAIN con NSEC3) descartadas por redes o middleboxes.

Arreglo: reduce el tamaño de respuestas (prefiere NSEC cuando sea aceptable; reduce la complejidad NSEC3; evita datos adicionales sobredimensionados) y prueba con búferes EDNS más pequeños.

2) Síntoma: aumento repentino de conexiones TCP/53 tras habilitar DNSSEC

Causa raíz: truncamiento TC=1 por tamaño de respuesta y resolutor que reintenta por TCP; a veces exacerbado por búferes EDNS pequeños.

Arreglo: monitoriza tasas del bit TC; ajusta para mantener respuestas típicas bajo tu presupuesto UDP; asegura que TCP autoritativo esté escalado y protegido.

3) Síntoma: validadores devuelven SERVFAIL para nombres inexistentes pero nombres existentes funcionan

Causa raíz: pruebas de negación de existencia rotas (cadena NSEC3 incorrecta, firmado erróneo, estado inline-signed obsoleto).

Arreglo: valida con delv +vtrace; re-firma limpiamente; asegura transferencias de zona consistentes del contenido firmado; evita cambios parciales de parámetros.

4) Síntoma: picos de CPU autoritativa que correlacionan con inundaciones NXDOMAIN

Causa raíz: construcción de respuestas negativas costosas, mal comportamiento de caché o trabajo de firmado filtrándose al servicio.

Arreglo: limita la tasa de fuentes abusivas; aumenta caché en los bordes; asegura que cadenas NSEC3 estén precalculadas; considera NSEC para zonas donde la enumeración no es problema.

5) Síntoma: “Activamos NSEC3 y el equipo de seguridad dice que es mejor, pero los incidentes aumentaron”

Causa raíz: control de seguridad elegido sin un modelo de amenaza; regresiones de rendimiento ignoradas; riesgo de divulgación exagerado.

Arreglo: documenta por qué NSEC3 es necesario; si no puedes, no lo uses. Prefiere DNSSEC más simple cuando sea posible y céntrate en control de exposición.

6) Síntoma: SERVFAIL intermitente alrededor de rollovers de clave

Causa raíz: throughput del signer y desfase de propagación; cambios de parámetros NSEC3 durante eventos de claves; ventanas de tiempo de firma demasiado ajustadas.

Arreglo: separa cambios de parámetros de rollovers de claves; amplía ventanas de validez apropiadamente; monitoriza cola del signer y estado de publicación.

7) Síntoma: resolutores se comportan diferente (unos validan, otros fallan)

Causa raíz: diferencias de path MTU, manejo EDNS distinto o estado en caché roto; no siempre “bugs del resolutor.”

Arreglo: prueba desde múltiples redes; captura fragmentación; confirma consistencia de DS y DNSKEY; reduce tamaños de respuesta para minimizar sensibilidad de ruta.

8) Síntoma: “Aún se puede hacer zone walking aunque tengamos NSEC3”

Causa raíz: etiquetas predecibles permiten ataques por diccionario; otras fuentes de datos filtran nombres de todos modos.

Arreglo: trata el DNS público como público. Elimina nombres sensibles, randomiza si es apropiado y evita asumir que NSEC3 proporciona secreto.

Listas de verificación / plan paso a paso

Lista de decisión: ¿debería esta zona usar NSEC3?

1. Enumera la amenaza: ¿estás intentando prevenir la enumeración masiva de nombres realmente inadivinables, o solo evitar vergüenza?
2. Evalúa la predictibilidad de nombres: si las etiquetas son palabras comunes, NSEC3 no detendrá la adivinación.
3. Estima el volumen NXDOMAIN: zonas con alto NXDOMAIN (typos, escáneres, tráfico bot) pagan más por NSEC3.
4. Define un presupuesto UDP: elige un objetivo (a menudo 1232) y prueba respuestas negativas contra él.
5. Confirma la madurez de la herramienta: ¿puede tu equipo validar y depurar fallos NSEC3 rápidamente?
6. Tener un plan de rollback: cambios de parámetros y mecanismos de negación de existencia necesitan despliegue escalonado y monitorización.

Plan de despliegue: cambiar NSEC ↔ NSEC3 sin dolor autoinfligido

1. Baseline primero: mide tamaños de respuesta, ratio NXDOMAIN, tasa TCP/53 y latencia en la cola.
2. Prueba desde múltiples redes: incluye móviles y rutas con “proxy corporativo”.
3. Etapa el cambio: canary en una zona o subconjunto de autoridades; vigila tasas TC=1 y conteos de fragmentos.
4. No mezcles con eventos de clave: no cambies parámetros NSEC3 durante KSK/ZSK rolls. Mantén variables separadas.
5. Observa comportamiento de caché negativa: revisa tasas de consulta de resolutores tras el cambio; no asumas que la caché te salvará.
6. Ensaya fallos: practica la validación de SERVFAIL y fallos de prueba negativa con el equipo on-call.

Lista operativa: mantener DNSSEC aburrido (el más alto cumplido)

1. Monitoriza tamaños de respuesta DNS (especialmente NXDOMAIN) y percentiles, no solo promedios.
2. Monitoriza tasas TCP/53, tasas del bit TC y conteos de fragmentos UDP.
3. Alerta sobre el horizonte de expiración de firmas (RRSIGs acercándose a caducar).
4. Mantén relojes de signers correctos (NTP) y verifica sincronía en signers y autoridades.
5. Documenta runbooks de rollover de claves y ejecútalos en horario laboral cuando sea posible.
6. Mantén valores EDNS por defecto sensatos; evita búferes enormes que inviten a fragmentación en internet abierta.
7. Asume que habrá inundaciones NXDOMAIN; ten rate limiting y controles de abuso listos.

Preguntas frecuentes

1) ¿Es NSEC3 obligatorio para DNSSEC?

No. DNSSEC requiere negación de existencia autenticada, pero eso puede proveerse con NSEC o NSEC3. Muchas zonas ejecutan NSEC con éxito.

2) ¿Hace NSEC3 mi zona “privada”?

No. Dificulta la enumeración masiva, no el descubrimiento dirigido. Si los nombres son adivinables, son descubribles.

3) ¿Por qué las respuestas NXDOMAIN son tan grandes con DNSSEC?

Porque el servidor debe incluir prueba. Esa prueba incluye registros de negación (NSEC/NSEC3) y sus firmas, además a menudo SOA y su firma. Las
pruebas NSEC3 pueden incluir múltiples registros.

4) ¿Debo aumentar iteraciones NSEC3 por más seguridad?

Solo si tienes un modelo de amenaza claro que se beneficie y has probado el impacto operativo en firmado y servicio. De lo contrario, manténlo
conservador o evita NSEC3.

5) ¿Cuál es la forma más simple de saber si NSEC3 causa problemas de rendimiento?

Compara tamaño y latencia de respuesta para unas cuantas consultas positivas frente a consultas NXDOMAIN, y comprueba si NXDOMAIN te empuja hacia
truncamiento, fragmentación o fallback a TCP.

6) Si cambio de NSEC3 a NSEC, ¿fallarán los validadores?

No deberían, siempre que la zona esté correctamente firmada y publicada. Pero la transición es sensible operativamente: despliega con cuidado y
monitoriza validación y comportamiento de caché.

7) ¿NSEC siempre es más rápido que NSEC3?

A menudo, sí—especialmente para respuestas negativas—porque las pruebas son más simples y típicamente más pequeñas. Pero tu experiencia depende del
contenido de la zona, la implementación del servidor y las redes cliente.

8) ¿Y el opt-out de NSEC3—debería usarlo?

Opt-out existe principalmente para zonas con muchas delegaciones inseguras (como algunos registros) para reducir recuento de registros y carga
operativa. También complica las garantías. Si no puedes explicar lo que hace a un auditor y al on-call, no lo uses a la ligera.

9) Nuestro equipo de seguridad quiere NSEC3 para evitar que “los atacantes aprendan subdominios.” ¿Qué les digo?

Diles que NSEC3 reduce la enumeración trivial pero no evita adivinación, descubrimiento derivado de CT ni descubrimiento por DNS pasivo. Si aún lo
quieren, exige un presupuesto de tamaño de respuesta y SLOs operativos para que la fiabilidad no se comprometa silenciosamente.

10) ¿Cuál es la falla de DNSSEC que más parece un problema de rendimiento?

La pérdida y reintentos por fragmentación. Se manifiesta como timeouts intermitentes y mayor latencia tail, no como un evento limpio de “caída”.
DNSSEC (y especialmente respuestas negativas pesadas) puede empujarte a ese régimen.

Conclusión: qué hacer a continuación (práctico, no espiritual)

NSEC3 no es “DNSSEC pero más.” Es un intercambio específico: menos divulgación de nombres a cambio de más complejidad, respuestas negativas más grandes
y mayor probabilidad de descubrir que partes de internet aún no pueden transportar tus paquetes de forma fiable.

Pasos siguientes que pagan la renta:

1. Mide el comportamiento NXDOMAIN en tu zona: tamaño, latencia, tasa de fallback a TCP y señales de fragmentación.
2. Decide si la enumeración es un problema real para tu zona. Si los nombres son adivinables, arregla exposición y nombrado, no solo pruebas de negación.
3. Elige un presupuesto UDP y aplícalo como prueba de regresión para cambios DNS, especialmente cambios DNSSEC.
4. Si usas NSEC3, mantén parámetros conservadores y separa cambios de parámetros de rollovers de claves.
5. Operacionaliza la validación: runbooks, pruebas desde múltiples puntos y alertas por expiración de firmas y picos TCP.

Ejecuta DNSSEC como ejecutas almacenamiento: asume fallos, vigila la latencia tail y prefiere el diseño más simple que cumpla el requisito real.
NSEC suele ser ese diseño. NSEC3 es para cuando puedes nombrar al enemigo y aceptar la factura.