--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "es" category: "DNS y fundamentos técnicos" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/es/glosario/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC extensiones de seguridad del DNS Extensiones del DNS que añaden firmas digitales a las respuestas DNS. Las firmas permiten que un resolutor (el servidor que busca los nombres para los usuarios) compruebe que una respuesta es auténtica y que no ha cambiado por el camino. Los titulares lo activan a través de su proveedor de DNS y de su registrador. DNSSEC añade firmas digitales a las respuestas del sistema de nombres de dominio, para que un ordenador compruebe que una respuesta procede del responsable del dominio y no se ha alterado por el camino. No oculta nada ni frena todos los ataques. Para activarlo tienen que intervenir el proveedor de DNS, el registrador y el registro. ## Qué protege DNSSEC, en pocas palabras Cuando alguien visita example.com, un resolutor busca su dirección. Sin DNSSEC, un atacante que le cuele una respuesta falsa puede desviar a los visitantes a otro servidor. Con DNSSEC, el resolutor de validación comprueba la firma y descarta la falsificación. La RFC 4033 (marzo de 2005) fija lo que aporta: prueba del origen e integridad de los datos DNS. No aporta confidencialidad (las respuestas siguen siendo legibles) ni protege frente a ataques de denegación de servicio. Solo cubre las respuestas DNS, no el phishing ni la toma de una cuenta en el registrador. La RFC 9364 (febrero de 2023) lo considera la mejor práctica actual para autenticar datos DNS; usarlo o no en un dominio es decisión del titular. ## Cómo funciona la cadena de confianza desde la raíz hasta el dominio El resolutor de validación parte de una clave en la que ya confía: el anclaje de confianza, que es la clave de firma de claves (KSK) de la zona raíz, publicada por la IANA. Desde ahí sigue una cadena: 1. La zona raíz contiene un registro DS firmado para .com. 2. Ese DS coincide con una clave de .com, con la que el resolutor comprueba los registros de .com, incluido el DS de example.com. 3. Ese DS coincide con la clave de example.com, que permite comprobar los registros del dominio. Una zona firmada sin registro DS en la zona padre es una «isla de seguridad»: no se puede validar desde la raíz. Una respuesta es segura si todas las firmas se comprueban; insegura si una prueba firmada muestra que la zona padre no tiene registro DS para ella, y no válida (bogus) si las firmas esperadas faltan, han caducado o no se pueden usar (RFC 4033). Ante una respuesta no válida, el resolutor devuelve normalmente un error, SERVFAIL (RFC 4035). ## Claves y registros: KSK, ZSK, DNSKEY, DS y RRSIG - Los registros **DNSKEY** publican las claves públicas de la zona. - Los registros **RRSIG** guardan las firmas, cada una válida solo entre una fecha de inicio y otra de caducidad. - Los registros **DS** están en la zona padre y contienen la etiqueta de la clave, el número de algoritmo y un resumen criptográfico de la clave de la zona hija. - La **KSK** firma solo el conjunto de claves de la zona, y a ella remite el registro DS. La **ZSK** firma todo lo demás. La RFC 6781 (diciembre de 2012) señala que los validadores tratan igual ambas claves: la separación es operativa, y algunas zonas usan una sola clave para las dos funciones. Demostrar que un nombre no existe requiere registros propios. NSEC indica el siguiente nombre existente, lo que permite a cualquiera listar toda la zona (recorrido de zona o «zone walking»). NSEC3 (RFC 5155) aplica antes una función hash a los nombres, aunque sigue dejando ver datos como el tamaño de la zona. ## Activar DNSSEC: qué hacen el registrador, el registro y el proveedor de DNS 1. El proveedor de DNS firma la zona y publica los registros DNSKEY y RRSIG. 2. Los datos del DS, o los de la clave, llegan al registrador. 3. El registrador los envía al registro por EPP con la extensión secDNS (RFC 5910, mayo de 2010), como datos DS o como datos de clave a partir de los que el registro genera el DS. 4. El registro publica el registro DS en la zona del TLD. Si el registrador es también el proveedor de DNS, los pasos 1 a 3 suelen ser una sola opción. En los gTLD, el Acuerdo de Acreditación de Registradores (RAA) de 2013 obliga a los registradores a trasladar las peticiones de añadir, quitar o cambiar material de claves a los registros que admiten DNSSEC, mediante la RFC 5910. El Acuerdo de Registro base (aprobado el 21 de enero de 2024 y vigente a octubre de 2026) obliga a los registros de gTLD a firmar su zona y a aceptar material de claves de los dominios hijos. En los ccTLD las normas varían: conviene consultarlas con el registrador o el registro. Existe además una vía automática: el proveedor de DNS publica registros CDS y CDNSKEY que indican cómo debe ser el DS, y algunos registros y registradores los rastrean. La RFC 8078 (marzo de 2017) añadió una señal para desactivar DNSSEC; la RFC 9615 (julio de 2024) permite a la zona padre verificar criptográficamente esos registros antes de activarlo. ## Qué puede fallar: firmas caducadas, traspasos de claves y cambios de proveedor - **Firmas caducadas.** Si los RRSIG no se renuevan a tiempo, las respuestas pasan a ser no válidas. - **Un DS sin clave que le corresponda.** La RFC 6781 lo llama «security lameness»: el dominio falla en todos los resolutores de validación y la corrección tarda en extenderse. Por eso, al cambiar la KSK, el nuevo DS debe estar en la zona padre antes de retirar la clave antigua. - **Cambio de proveedor de DNS.** El operador saliente controla las claves. Lo mejor es un traspaso de claves coordinado. Si no colabora, se retira el DS, se cambian los servidores de nombres y, cuando el cambio se ha extendido, se añade el nuevo DS. Mientras tanto el dominio queda sin firmar, algo que la RFC 8078 prefiere a los fallos de validación. Unos TTL cortos ayudan. Quien usa un resolutor de validación ve SERVFAIL; para los demás, el dominio puede seguir funcionando. En la raíz, a 9 de octubre de 2026, la ICANN tiene previsto cambiar la KSK el 11 de octubre de 2026: KSK-2024 (etiqueta de clave 38696) sustituye a KSK-2017 (etiqueta de clave 20326), que se revocará el 11 de enero de 2027 y se retirará el 22 de marzo de 2027. Afecta a los operadores de resolutores de validación, que necesitan el nuevo anclaje de confianza, no a los titulares. ## DNSSEC y DNS cifrado: en qué se diferencian DNSSEC firma los datos para que cualquier resolutor pueda comprobarlos, pero todo sigue siendo legible. DNS sobre TLS (DoT) y DNS sobre HTTPS (DoH) cifran el enlace entre el dispositivo del usuario y el resolutor, lo que protege la privacidad, pero no demuestran que los datos procedan del responsable de la zona. Ambos se complementan. ## Fuentes - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## términos relacionados - [registro DS](https://tldlog.com/es/glosario/registro-ds/) - [registro DNSKEY](https://tldlog.com/es/glosario/registro-dnskey/) - [resolutor](https://tldlog.com/es/glosario/resolutor/) - [DNS](https://tldlog.com/es/glosario/dns/)