DNSSEC en lenguaje sencillo

Módulo 8: Seguridad y resolución de problemas · Tiempo de lectura: 11 minutos

Objetivo de la lección: Después de esta lección podrá explicar en lenguaje sencillo qué protege DNSSEC, cómo funciona la cadena de confianza y por qué puede fallar al transferir un dominio.

Conceptos clave: DNSSEC, firma (RRSIG), clave (DNSKEY), registro DS, cadena de confianza, resolver validador, SERVFAIL

El problema: ¿cómo sabe que una respuesta es auténtica?

En el módulo 1 vio que un resolver hace una serie de preguntas: a la raíz, al servidor del TLD y al servidor de nombres autoritativo. La respuesta que recibe se da por buena y se guarda en la caché. Pero el DNS normal no comprueba si esa respuesta viene realmente del servidor de nombres correcto. Un atacante que consiga enviar una respuesta falsa antes de que llegue la real puede hacer creer a un resolver que example.com se encuentra en 203.0.113.66 en lugar de en 192.0.2.10. Esto se llama cache poisoning (envenenamiento de caché): la caché queda "envenenada" y todo el que use ese resolver acaba en el servidor equivocado.

DNSSEC (DNS Security Extensions) resuelve esto firmando las respuestas. Así el resolver puede comprobar si una respuesta es auténtica y no ha sido modificada por el camino.

Qué hace DNSSEC y qué no hace

Esto es lo más importante que debe recordar:

Una firma funciona como un sello en un sobre: cualquiera puede leer la carta, pero verá de inmediato si alguien la ha abierto.

Los tres componentes

DNSSEC añade algunos tipos de registro. No tiene que crearlos usted mismo (eso lo hace su administrador de DNS o el panel), pero los encontrará:

• DNSKEY: la clave pública de la zona. Con ella cualquiera puede comprobar las firmas.
• RRSIG: la firma de un grupo de registros. Cada respuesta de tipo A, MX o TXT recibe un RRSIG. Una firma tiene una fecha de inicio y una de fin: la zona debe volver a firmarse periódicamente.
• DS (Delegation Signer): una especie de "huella digital" corta de la clave de su zona. Esta no está en su propia zona, sino en la zona superior: para example.com está en el registro de dominios de .com (Verisign), y para un dominio .nl está en SIDN (el registro de dominios de .nl en los Países Bajos).

Así se ve una respuesta firmada (abreviada):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

En el RRSIG se ve, entre otras cosas, el algoritmo (13 = ECDSA P-256 con SHA-256), la fecha de fin (19 de noviembre de 2026), la fecha de inicio y el número de la clave (30794).

La cadena de confianza

¿Por qué está el DS en la zona superior? Porque una clave en su propia zona no demuestra nada: un atacante también podría enviar su propia clave. Por eso la comprobación va de arriba abajo:

1. El resolver confía en la clave de la raíz. Esta viene integrada en todo resolver validador (el trust anchor o ancla de confianza).
2. La raíz tiene un DS para .com, firmado con la clave de la raíz. Así el resolver sabe qué clave debería tener .com.
3. La zona .com tiene un DS para example.com, firmado con la clave de .com.
4. La zona example.com tiene un DNSKEY que coincide con ese DS, y con ella se pueden comprobar todos los RRSIG.

Cada eslabón demuestra el siguiente. Si se rompe un eslabón, toda la cadena deja de ser fiable.

Un resolver validador (la mayoría de los grandes resolvers públicos, y cada vez más proveedores) recorre esa cadena. Si es correcta, usted recibe la respuesta. Si no lo es, el resolver no da respuesta, sino el estado de error SERVFAIL. Para el visitante, el sitio parece simplemente "no existir", aunque sus registros puedan estar perfectamente bien.

Puede comprobarlo usted mismo con un dominio que se ha estropeado a propósito:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Con +cd ("checking disabled") le pide al resolver que se salte la comprobación. Si entonces sí obtiene una respuesta, sabrá con seguridad que el problema está en DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Un dominio sin DNSSEC (sin DS en la zona superior) no da SERVFAIL: simplemente no está firmado y se deja pasar como "no seguro".

Dónde falla: transferencias y cambios de clave

DNSSEC en sí mismo casi nunca se estropea. El problema surge cuando el DS en el registro de dominios ya no coincide con la clave de la zona. Esto ocurre sobre todo:

• Al transferir los servidores de nombres o el proveedor de DNS. El nuevo proveedor firma con su propia clave, pero en el registro de dominios aún figura el DS del proveedor anterior. Resultado: SERVFAIL para todo el que use un resolver validador. Este es el error clásico tras una transferencia.
• Al cambiar de clave, cuando el nuevo DS no se ha enviado (a tiempo) al registro de dominios.
• Cuando las firmas caducan, porque la zona ha dejado de firmarse de nuevo.

Por eso, el orden seguro al transferir un dominio es:

1. Retire el DS del registro de dominios (o pida al nuevo proveedor que le facilite un DS para añadirlo).
2. Espere a que pase el TTL del DS antiguo.
3. Cambie los servidores de nombres.
4. Active DNSSEC en el nuevo proveedor y haga que coloque el nuevo DS en el registro de dominios.

Muchos registradores y paneles gestionan esto automáticamente en la actualidad, siempre que el dominio y el DNS estén en el mismo proveedor. Si están en proveedores distintos, tendrá que transferir el DS usted mismo.

Comprobarlo usted mismo: DNSViz, Zonemaster e internet.nl

No tiene que recorrer la cadena con dig. Existen herramientas gratuitas que lo hacen por usted y muestran el resultado.

DNSViz (https://dnsviz.net/) dibuja toda la cadena como un diagrama. Así se usa:

1. Escriba en la página principal el nombre de dominio en el cuadro de búsqueda (solo el nombre, sin https:// ni www) y haga clic en Go.
2. DNSViz muestra el último análisis. Si es antiguo, o si acaba de cambiar algo, haga clic en Update now. Tras unos segundos verá el diagrama.
3. Lea el diagrama de arriba abajo: arriba la raíz (.), debajo el TLD (por ejemplo nl), abajo del todo su dominio. Cada zona es un recuadro.

Lo que ve en el diagrama:

La cadena se sigue así: el DS (en la zona superior) apunta al DNSKEY (en su zona), y ese DNSKEY pone su firma (RRSIG) bajo los registros. Es exactamente la cadena de esta lección, pero dibujada.

Los colores indican si todo está en orden:

• Azul: seguro (secure). La cadena es ininterrumpida desde la raíz hasta este componente.
• Negro: no firmado (insecure). No hay DS, así que no hay nada que comprobar. No es un error: el dominio simplemente no usa DNSSEC.
• Rojo: roto (bogus). Un DS no coincide con una clave, o una firma no es correcta. Un resolver validador dará entonces SERVFAIL.
• Morado (en una firma): la firma ha caducado o aún no es válida. La zona ha dejado de firmarse de nuevo.
• Amarillo: una advertencia, por ejemplo un servidor de nombres que no responde bien, o un algoritmo que la herramienta no reconoce.
• Gris y punteado: se hace referencia a una clave que no existe. Si ve un DNSKEY punteado bajo un DS, significa que en la zona superior todavía hay un DS de una clave antigua: el error clásico tras una transferencia.

Junto a un componente puede aparecer un triángulo (advertencia) o un símbolo de error redondo. Pase el ratón por encima, o consulte la lista debajo del diagrama: ahí se explica en palabras qué está mal.

Pruébelo con sidn.nl (todo en azul) y con dnssec-failed.org (en rojo, con una clave punteada bajo el DS).

Otras herramientas que analizan lo mismo desde otro ángulo:

• Zonemaster (https://zonemaster.net/): comprueba toda su zona como lo haría un registro de dominios, incluido DNSSEC. El resultado es una lista con verde (correcto), naranja (advertencia) y rojo (error).
• internet.nl (https://internet.nl/): la prueba de sitio web y correo electrónico muestra, entre otras cosas, si DNSSEC está en orden para su dominio y sus servidores de correo, con marcas verdes o cruces rojas.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): recorre la cadena paso a paso y pone en cada paso una marca verde o una cruz roja. Útil si busca un fallo concreto.

Utilícelas después de cada cambio en DNSSEC, y desde luego antes y después de una transferencia de dominio. Deje que la herramienta vuelva a analizar con calma: estas herramientas también trabajan con cachés y TTL.

En la práctica: así se ve en un panel

En Mi WebOké, active DNSSEC para un dominio en DNSSEC/DANE; el panel genera las claves y envía el DS al registro de dominios. En DirectAdmin y en proveedores externos como Cloudflare, suele llamarse "Habilitar DNSSEC"; Cloudflare le mostrará entonces un registro DS que debe introducir usted mismo en su registrador. Otros paneles funcionan de forma similar: siempre hay un paso de "generar claves" (en el proveedor de DNS) y un paso de "DS en el registro de dominios" (en el registrador).

Resumen

• DNSSEC firma las respuestas DNS para que un resolver pueda comprobar que son auténticas. No cifra nada.
• DNSKEY es la clave, RRSIG la firma, DS la huella digital en la zona superior.
• La comprobación funciona como una cadena desde la raíz hasta su dominio. Si se rompe un eslabón, un resolver validador da SERVFAIL.
• Casi todos los problemas surgen porque el DS en el registro de dominios ya no coincide, a menudo tras una transferencia.
• Con dig +cd puede ver si un problema se debe a DNSSEC.
• DNSViz dibuja la cadena: azul es seguro, negro es no firmado, rojo es roto. Zonemaster, internet.nl y el Verisign DNSSEC Debugger son buenas segundas opiniones.

Cuestionario

Ejercicio

Ejercicio Z8.1: Ver DNSSEC. Averigüe cuál de estos dos dominios tiene DNSSEC correctamente configurado y cuál se ha estropeado a propósito: sidn.nl (el dominio de la SIDN, el registro de dominios de .nl en los Países Bajos) y dnssec-failed.org. Consulte para ambos el registro DS y el registro A a través de un resolver validador (por ejemplo 1.1.1.1 o 9.9.9.9), con dig o una herramienta en línea. Indique: el número de clave (key tag, el primer número) del DS de sidn.nl, y el estado que obtiene para dnssec-failed.org.

Ejercicio Z8.1b: Leer DNSViz. Analice nlnetlabs.nl en DNSViz (https://dnsviz.net/, escriba el nombre y haga clic en Go; haga clic en Update now si el análisis es antiguo). Lea el diagrama e indique: (1) el estado de nlnetlabs.nl (seguro, no firmado o roto), (2) el número de algoritmo de los registros DNSKEY (aparece en cada óvalo como alg=), (3) cuántos óvalos DNSKEY hay en la zona de nlnetlabs.nl, (4) el número de clave (id=) del DNSKEY relleno de gris al que apunta el DS, y (5) el estado que da DNSViz para dnssec-failed.org. La verificación consulta en vivo los mismos datos.

Ejercicio O8.1: Evaluar tres zonas DNSSEC de demostración. Hemos preparado tres zonas de demostración: signed-demo.dnspractice.com (cadena correcta), broken-demo.dnspractice.com (estropeada a propósito) y unsigned-demo.dnspractice.com (no firmada). Averigüe para cada zona si es segura, está rota o no está firmada, por ejemplo con DNSViz o con dig +dnssec (preste atención al indicador AD, y pruebe también con +cd si obtiene SERVFAIL). Elija a continuación su respuesta para cada zona.

Para saber más

Estos artículos describen los pasos en los paneles de WebOké; en otros proveedores los botones tienen otros nombres.

• Manual de WebOké 5.8: DNSSEC y DANE
• ¿Qué es DNSSEC?
• Activar DNSSEC
• La página web o el correo electrónico no funciona tras una migración o un cambio de DNS: compruebe su dominio