¿Qué es DNSSEC?
El DNSSEC (Domain Name System Security Extensions) firma criptográficamente las respuestas del DNS, de modo que quien consulta puede distinguir la respuesta auténtica de una forjada. No esconde nada y no acelera nada: resuelve la imposibilidad histórica de saber si la traducción de un nombre es confiable. La verificación sube por una cadena de firmas hasta la raíz de internet, y solo protege cuando los dos extremos hacen su parte, porque firmar es decisión de quien tiene el dominio y validar es decisión de quien consulta.
Cómo funciona el DNSSEC
La idea es simple y la ejecución es encadenada: cada nivel del DNS firma su contenido y le da al nivel de arriba lo suficiente para que confirme quién es. Quien consulta solo necesita confiar en el primer eslabón.
La zona se firma
El dueño del dominio genera un par de claves y firma sus registros. La firma de cada conjunto de registros va en un registro propio, el RRSIG, que viaja junto con la respuesta.
La clave pública se publica
La mitad pública del par entra en la propia zona, en un registro DNSKEY. Es con ella que cualquier resolutor del mundo verifica las firmas de ese dominio.
Se registra el eslabón con el nivel de arriba
Un resumen de esa clave se publica en la zona del padre, como registro DS, a través del registrador del dominio. Es ese paso, hecho fuera del panel de DNS, el que ata su dominio a la cadena.
El resolutor sube la cadena y decide
Al recibir la respuesta, el resolutor verifica la firma con la clave, la clave con el DS del nivel de arriba, y así hasta la raíz. Si algún eslabón no cierra, rechaza la respuesta en lugar de retransmitirla.
Fuente: RFC 4033, la especificación oficial del IETF que introduce el DNSSEC y define la cadena de confianza como una secuencia alternada de registros DNSKEY y DS, cada eslabón avalando al siguiente, el RFC 4035, que define el comportamiento del resolutor validador y el rechazo de la respuesta que no cierra, y el material de medición de APNIC Labs sobre la diferencia entre firmar y validar.
Lo que el DNSSEC no hace
- No esconde la consulta. La norma es explícita: el DNSSEC no fue diseñado para ofrecer confidencialidad ni control de acceso. Quien observa la red sigue viendo qué nombres buscó usted; lo que cambia es que la respuesta ya no puede cambiarse sin que se note.
- No protege contra la indisponibilidad. También está escrito en la norma: el DNSSEC no ofrece ninguna protección contra ataques de negación de servicio. Autenticidad y disponibilidad son problemas distintos.
- No impide el secuestro en el origen. Si el delincuente obtiene acceso a la cuenta del dominio en el registrador, pasa a ser quien firma, y la cadena cierra perfectamente alrededor de una respuesta que es oficialmente equivocada.
- El beneficio no aparece de su lado. Firmar su dominio no protege su navegación: protege a quienes lo buscan a usted, y solo si el resolutor de esa persona valida firmas. Usted hace su mitad entera, y la otra mitad nunca llega a ser suya.
Las piezas de la cadena de confianza
- DNSKEY (DNS Public Key), la clave pública de la zona Queda publicada en el propio dominio y es lo que permite a cualquier servidor del mundo verificar sus firmas. Exponer esa mitad es intencional y no representa riesgo: con ella se verifica, nunca se firma.
- RRSIG (Resource Record Signature), la firma de cada conjunto Cada grupo de registros recibe su propia firma, que viaja con la respuesta y tiene fecha de vencimiento. Una firma vencida no pasa la verificación, lo que convierte la renovación en tarea continua y no en un proyecto que termina.
- DS (Delegation Signer), el eslabón con el nivel de arriba Un resumen de su clave, publicado en la zona del padre a través del registrador. Es el único paso que no ocurre en su panel de DNS, y por eso el que más deja proyectos por la mitad: la zona queda firmada y nadie logra validarla.
- La raíz, el ancla de confianza La cima de la cadena ya viene configurada de antemano en cualquier resolutor que valide en la internet pública. La norma lo llama ancla de confianza: una clave en la que se confía por configuración, no por verificación. Es lo que vuelve viable el modelo: nadie necesita confiar en cada dominio, solo en el primer eslabón.
Quién paga la cuenta y quién cosecha el beneficio
Lo que más confunde a quien decide es que el DNSSEC es un protocolo de dos extremos con dueños distintos. Firmar su dominio es una decisión suya y la ejecuta solo; validar firmas es decisión de quien consulta, y ahí usted no manda. Eso significa que el beneficio de firmar no aparece en su entorno, aparece en la experiencia de terceros que lo buscan a usted, y únicamente en aquellos cuyo resolutor hace la verificación. Es lo opuesto a la intuición de quien está acostumbrado a comprar controles que protegen el propio perímetro. Para una empresa, la consecuencia práctica es elegir el lado correcto en cada caso: firmar el dominio protege a clientes, socios y a los servidores que entregan su correo de recibir una respuesta forjada en su nombre; usar resolutores validadores protege su propia operación de ser llevada al lugar equivocado. Las dos cosas son baratas y son independientes entre sí, y la segunda es la que suele quedar atrás por un motivo banal: la mayor parte de las redes usa el resolutor que vino por defecto del proveedor de acceso, y la validación hoy está concentrada en pocos resolutores públicos (APNIC Labs). Cambiar a un resolutor que valida es una decisión de configuración, no de presupuesto.
Cómo implementar el DNSSEC sin romper el dominio
Equivocarse aquí no degrada el servicio, deja el dominio fuera de servicio para todos los que validan. Por eso el orden importa:
- Confirme que el proveedor de DNS y el registrador lo soportanLos dos tienen que soportarlo, y no siempre son la misma empresa. Descubrirlo después de firmar es lo que produce el dominio firmado que nadie logra validar.
- Firme la zona y verifique antes de publicar el eslabónCon la zona firmada y todavía sin el DS en el padre, nada cambia para el mundo: es la ventana para verificar que las firmas están correctas sin riesgo de indisponibilidad.
- Publique el DS en el registrador con el valor exactoEste es el paso manual y el más peligroso: un resumen equivocado, o publicado fuera de orden, hace que todo resolutor validador rechace su dominio. Verifique el valor antes y la cadena después.
- Trate la rotación de clave como rutina, no como proyectoLas firmas vencen. Automatice la renovación y el cambio de clave, y monitoree el vencimiento como monitorea el certificado de un sitio, porque la falla tiene el mismo efecto: el nombre deja de resolver.
- Del otro lado, use resolutores que validanFirmar se ocupa de quienes lo buscan a usted. Para proteger su propia operación, lo que cuenta es que el resolutor que usa su red verifique las firmas que recibe.
En la práctica
Es una certificación de firma en cadena: cada nivel avala la firma del nivel de abajo, hasta un primer eslabón que todos ya conocen de antemano. Y eso es lo que vuelve viable el modelo a escala planetaria: la confianza no se negocia dominio por dominio, baja desde un único punto conocido. Por eso la pregunta a hacerse nunca es si usted confía en ese dominio, sino si su cadena cierra hasta allá arriba.
Cómo Zamak trata el DNSSEC
Zamak Technologies trata el DNSSEC como dos decisiones separadas, porque lo son: firmar la zona del cliente, con el eslabón correctamente publicado en el registrador y la rotación de clave automatizada y monitoreada, y del otro lado asegurar que los resolutores que usa la operación verifican firmas. Es la base que sostiene la autenticación de correo, ya que el DMARC y los demás registros de autenticación son respuestas de DNS, y es la respuesta directa al envenenamiento de caché DNS. No se confunde con el filtrado de DNS, que decide si un dominio debe bloquearse: aquí la pregunta es si la respuesta es auténtica. Quien quiera ver el estado de su propio dominio antes de cualquier conversación puede correr la verificación gratuita de dominio, que muestra si la zona está firmada junto con el resto de la autenticación. Esto forma parte de la Ciberseguridad gestionada del Método Zamak.