DNSSEC – ¿Qué son y por qué son importantes?
¿Le interesa aprender sobre las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC)? Haga clic en la imagen que figura a continuación para ver nuestra infografía, donde encontrará una descripción de las DNSSEC y los beneficios de su implementación.
Contenido:
Breve descripción de cómo funciona el DNS
Para comprender las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC), resulta útil tener un entendimiento básico del Sistema de Nombres de Dominio (DNS).
El funcionamiento adecuado de Internet depende fundamentalmente del DNS. Cada página web visitada, cada correo electrónico enviado y cada imagen obtenida de las redes sociales depende del DNS. De hecho, el DNS traduce nombres de dominio amigables, como icann.org, en direcciones IP como 192.0.43.7 y 2001:500:88:200::7. Estas direcciones IP son esenciales para que los servidores, enrutadores y otros dispositivos de red dirijan el tráfico a través de Internet al destino correcto.
El uso de Internet en cualquier dispositivo comienza con el DNS. Por ejemplo, cuando un usuario introduce el nombre de un sitio web en el navegador de su teléfono, el navegador inicia primero el proceso de traducir el nombre de dominio en una dirección de Protocolo de Internet (IP). Este proceso comienza con el resolutor mínimo (stub), el cual forma parte del sistema operativo del dispositivo, para comenzar el proceso de traducir el nombre de dominio del sitio web a una dirección IP (Protocolo de Internet). Un resolutor mínimo (stub) es un cliente muy simple del DNS que transmite la solicitud de una aplicación de datos del DNS a un componente más complicado denominado resolutor recursivo, que es un servidor del DNS. Muchos operadores de redes ejecutan resolutores recursivos para manejar solicitudes, o consultas, del DNS que envían los dispositivos en su red. (Los operadores y organizaciones de menor envergadura a veces emplean resolutores recursivos en otras redes, incluidos resolutores recursivos operados como un servicio para el público, como Google Public DNS, OpenDNS y Quad9).
El resolutor recursivo localiza, o resuelve, la respuesta a la consulta del DNS enviada por el resolutor mínimo (stub). Este proceso de resolución requiere que el resolutor recursivo envíe sus propias consultas del DNS, por lo general, a varios servidores de nombres autoritativos diferentes. Los datos del DNS para cada nombre de dominio se almacenan en un servidor de nombres autoritativo en algún lugar de Internet. Los datos del DNS de un dominio se denominan zona. Algunas organizaciones operan sus propios servidores de nombres para publicar sus zonas, pero, por lo general, las organizaciones tercerizan esta función a otras partes. Hay diferentes tipos de organizaciones que alojan zonas del DNS en nombre de otros, incluidos registradores, registros, compañías proveedoras de alojamiento web y proveedores de servidores de red, entre otros.
El DNS en sí no es seguro
El DNS fue diseñado en la década de 1980 cuando la Internet era mucho más pequeña y la seguridad no era una consideración primordial en su diseño. En consecuencia, cuando un resolutor recursivo envía una consulta a un servidor de nombres autoritativo, el resolutor no tiene forma de verificar la autenticidad de la respuesta. El resolutor solo puede comprobar que una respuesta parece provenir de la misma dirección IP desde la que el resolutor envió la consulta original. Pero el hecho de basarse en una dirección fuente de IP de una respuesta no es un mecanismo de autenticación sólido, dado que la dirección fuente de IP de un paquete de respuestas del DNS puede ser fácilmente falsificada o suplantada. De la manera en que el DNS fue originalmente diseñado, un resolutor no puede detectar fácilmente una respuesta falsificada a una de sus consultas. Un atacante puede hacerse pasar de manera sencilla por el servidor autoritativo que un resolutor originalmente consultó mediante la suplantación de una respuesta que parece provenir del servidor autoritativo. En otras palabras, un atacante puede redirigir a un usuario a un sitio potencialmente malicioso sin que el usuario se dé cuenta.
Los resolutores recursivos almacenan en la memoria caché los datos del DNS que reciben de los servidores de nombres autoritativos para acelerar el proceso de resolución. Si un resolutor mínimo (stub) solicita datos del DNS que el resolutor recursivo tiene en su caché, el resolutor recursivo puede responder de inmediato sin la demora que se presenta al consultar primero a uno o varios servidores autoritativos. Sin embargo, esta dependencia de almacenamiento en caché tiene una desventaja: si un atacante envía una respuesta falsificada del DNS que es aceptada por un resolutor recursivo, el atacante ha envenenado la caché del resolutor recursivo. El resolutor entonces procederá a devolver los datos fraudulentos del DNS a otros dispositivos que consulten por ellos.
Como un ejemplo de la amenaza presentada por un ataque de envenenamiento de la memoria caché, considere lo que sucede cuando un usuario visita el sitio web de su banco. El dispositivo del usuario consulta su servidor de nombre recursivo configurado sobre la dirección IP del sitio web del banco. Pero un atacante pudo haber envenenado el resolutor con una dirección IP que apunte no al sitio legítimo sino a un sitio web creado por él. Este sitio web fraudulento imita al sitio web del banco y tiene exactamente la misma apariencia. El usuario, sin sospechar nada, introduciría su nombre y contraseña, como lo hace siempre. Lamentablemente, el usuario ha proporcionado sin saberlo sus credenciales bancarias al atacante, quien entonces puede iniciar sesión como ese usuario en el sitio web legítimo del banco para transferir fondos o realizar otras acciones no autorizadas.
Extensiones de Seguridad del DNS
En la década de 1990, los ingenieros del Grupo de Trabajo en Ingeniería de Internet (IETF), la organización responsable de los estándares del protocolo del DNS, se dieron cuenta de que la falta de una autenticación más sólida en el DNS era un problema. El resultado fueron las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC).
Las DNSSEC refuerzan la autenticación del DNS mediante firmas digitales basadas en cifrado de clave pública. Con las DNSSEC, no son las consultas y las respuestas del DNS en sí las que están criptográficamente firmadas, sino que los datos del DNS en sí están firmados por el propietario de los datos.
Cada zona del DNS tiene un par de claves pública-privada. El propietario de la zona usa la clave privada de la zona para firmar los datos del DNS en la zona y generar firmas digitales sobre esos datos. Tal como lo implica el nombre "clave privada", este material clave es mantenido de manera secreta por el propietario de la zona. La clave pública de la zona, en cambio, se publica en la zona en sí para que cualquier persona la obtenga. Todo resolutor recursivo que busque datos en la zona también obtiene la clave pública de la zona, la cual usa para validar la autenticidad de los datos del DNS. El resolutor confirma que la firma digital sobre los datos del DNS que obtiene es válida. Si eso ocurre, los datos del DNS son legítimos y son devueltos al usuario. Si la firma no los valida, el resolutor asume que es un ataque, descarta los datos y devuelve un error al usuario.
Las DNSSEC agregan dos funciones importantes al protocolo del DNS:
- La autenticación del origen de los datos permite a un resolutor verificar criptográficamente que los datos que recibe provienen de la zona donde considera que los datos se originaron.
- La protección de la integridad de los datos permite que el resolutor sepa que los datos no han sido modificados en tránsito desde que fueron firmados originalmente por el propietario de la zona con la clave privada de la zona.
Confianza en las claves de las DNSSEC
Cada zona publica su clave pública, la cual un resolutor recursivo recupera para validar los datos en la zona. Pero, ¿de qué manera un resolutor puede garantizar que la clave pública de una zona es auténtica? La clave pública de una zona está firmada, al igual que los otros datos de la zona. Sin embargo, la clave pública no está firmada por la clave privada de la zona, sino por la clave privada de la zona principal. Por ejemplo, la clave pública de la zona icann.org está firmada por la zona org. Del mismo modo que la zona principal del DNS es responsable de publicar la lista de servidores de nombres autoritativos de una zona secundaria, una zona principal también es responsable de garantizar la autenticidad de la clave pública de su zona secundaria. La clave pública de cada zona está firmada por su zona principal, a excepción de la zona raíz: no tiene zona principal para firmar su clave.
La clave pública de la zona raíz es, por ende, un punto de partida importante para validar los datos del DNS. Si un resolutor confía en la clave pública de la zona raíz, puede confiar en las claves públicas de las zonas del nivel superior firmadas por la clave privada de la raíz, tal como la clave pública de la zona org. Y dado que el resolutor puede confiar en la clave pública de la zona org, también puede confiar en las claves públicas que han sido firmadas por su clave privada respectiva, como la clave pública para icann.org. (En la práctica real, la zona principal no firma la clave de la zona secundaria directamente-- el mecanismo real es más complicado-- pero tiene idéntico efecto como si la zona principal hubiese firmado la clave de la zona secundaria).
La secuencia de claves criptográficas firmando otras claves criptográficas se denomina cadena de confianza. La clave pública al comienzo de una cadena de confianza se denomina anclaje de confianza. Un resolutor tiene una lista de anclajes de confianza, los cuales son claves públicas para diferentes zonas en las que el resolutor confía de manera implícita. La mayoría de los resolutores están configurados con solo un anclaje de confianza: la clave pública de la zona raíz. Al confiar en esta clave en el nivel superior de la jerarquía del DNS, un resolutor puede crear una cadena de confianza a cualquier ubicación en el espacio de nombres del DNS, siempre que cada zona de la ruta esté firmada.
Validación y firma con DNSSEC
Con el fin de que Internet tenga una seguridad generalizada, las DNSSEC deben ser implementadas de forma masiva. Las DNSSEC no son automáticas: en este momento necesitan ser habilitadas específicamente por los operadores de redes en sus resolutores recursivos y también por los propietarios de nombres de dominio en los servidores autoritativos de su zona. Los operadores de resolutores y de servidores autoritativos tienen diversos incentivos para activar las DNSSEC para sus sistemas, pero cuando lo hacen, más usuarios tienen la seguridad de obtener respuestas autenticadas a sus consultas del DNS. De manera sencilla, un usuario puede tener la seguridad de que llegará al destino en línea deseado.
La habilitación de la validación con DNSSEC en los resolutores recursivos es sencilla. De hecho, ha sido admitida por prácticamente todos los resolutores comunes durante muchos años. La activación implica cambiar solo unas pocas líneas en el archivo de configuración del resolutor. A partir de ese punto, cuando un usuario solicita al resolutor la información del DNS que proviene de zonas firmadas, y que los datos han sido alterados, el usuario no obtendrá (intencionalmente) ningún dato. Las DNSSEC protegen al usuario de obtener datos incorrectos de una zona firmada al detectar el ataque e impedir que el usuario reciba los datos alterados.
La firma de las zonas con DNSSEC se realiza en unos pocos pasos, pero hay millones de zonas que firman su información del DNS de manera que los usuarios de resolutores de validación puedan asegurarse de recibir los datos correctos. Prácticamente todos los elementos de software de servidores de nombres autoritativos comunes son compatibles con la firma de zonas y muchos proveedores de alojamiento del DNS externos también admiten las DNSSEC. Por lo general, la habilitación de las DNSSEC para una zona con un proveedor de alojamiento resulta bastante simple: usualmente implica solo hacer clic en una casilla de verificación.
Para que el propietario de una zona implemente las DNSSEC mediante la firma de los datos de su zona, esa zona principal, y su zona principal, hasta la zona raíz, también deben ser firmadas para que las DNSSEC sean lo más eficaces posible. Una cadena continua de zonas firmadas comenzando en la zona raíz permite que un resolutor cree una cadena de confianza desde la zona raíz para validar los datos. Por ejemplo, para implementar eficazmente las DNSSEC en la zona icann.org, la zona org debe estar firmada así como también la zona raíz. Afortunadamente, la zona raíz del DNS está firmada desde el año 2010 y también lo están todos los dominios genéricos de alto nivel (gTLD) y muchos dominios de alto nivel con código de país (ccTLD).
Hay un paso más para completar la implementación de las DNSSEC en una zona: el material de la clave pública de la zona recientemente firmada debe ser enviado a la zona principal. Tal como se describió anteriormente, la zona principal firma la clave pública de la zona secundaria y permite que se cree una cadena de confianza desde la zona principal hasta la secundaria.
En la actualidad, el propietario de la zona generalmente debe comunicar el material de la clave pública de la zona a la secundaria en forma manual. En la mayoría de los casos, esa comunicación se realiza a través del registrador del propietario de la zona. Del mismo modo que el propietario de una zona interactúa con su registrador para realizar otros cambios a una zona, como la lista de los servidores de nombres autoritativos de la zona, el propietario de la zona también interactúa con el registrador para actualizar el material de la clave pública de la zona. Si bien en la actualidad este proceso es manual, se prevé que protocolos recientemente desarrollados permitan que este proceso sea automatizado en el futuro.
Próximos pasos para las DNSSEC
A medida que la implementación de las DNSSEC aumente, el DNS puede convertirse en una base para otros protocolos que requieran una forma de almacenar datos en forma segura. Se han desarrollado protocolos nuevos que dependen de las DNSSEC y, por lo tanto, solo funcionan en zonas que están firmadas. Por ejemplo, la Autenticación Basada en el DNS de Entidades Nominadas (DANE) permite la publicación de claves de Seguridad de la Capa de Transporte (TLS) en zonas para aplicaciones tales como el transporte de correo. DANE brinda una manera de verificar la autenticidad de las claves públicas que no depende de autoridades de certificación. Otra forma de agregar privacidad a las consultas del DNS es utilizar DANE.
En el año 2018, la ICANN por primera vez cambió el anclaje de confianza de la raíz del DNS. Se aprendieron muchas lecciones sobre las DNSSEC durante dicho proceso. Además, muchos operadores de resolutores obtuvieron más conocimiento sobre las DNSSEC y activaron la validación, lo cual proporciona a la comunidad global una comprensión más clara sobre cómo funciona todo el sistema de las DNSSEC. La ICANN también ha estado trabajando con diversas partes interesadas de la comunidad de Internet, como gobiernos, operadores de TLD, proveedores de alojamiento del DNS, proveedores de servicios de Internet (ISP) y operadores de redes móviles (MNO) para aumentar la implementación de las DNSSEC tanto a nivel de firma como de validación.
En 2024, la ICANN generó un nuevo anclaje de confianza para la raíz del DNS que está previsto que se active en 2026. La ICANN espera, en los próximos años, ver una mayor adopción de las DNSSEC, tanto por parte de los operadores de resolutores como de los propietarios de zonas. Esto implicaría que más usuarios de todas partes pudieran beneficiarse de la sólida seguridad criptográfica de las DNSSEC de que están obteniendo respuestas auténticas del DNS a sus consultas.
Más información
Qué hace la ICANN en torno a las DNSSEC
-
Información sobre las DNSSEC de la IANA
Esta página contiene información relacionada con la función de la IANA como operadora de la clave para la firma de la llave de la zona raíz del DNS: anclajes de confianza y traspasos, materiales de la ceremonia de la KSK, políticas y procedimientos de gestión de claves de la zona raíz, etc. -
Participación Técnica
Esta página contiene información sobre el equipo de la ICANN encargado de llevar a cabo y facilitar la creación de capacidades técnicas y las iniciativas de participación y difusión para diversas partes interesadas dentro de la comunidad de Internet para ayudar a mantener un ecosistema del DNS seguro.
Publicaciones relevantes
- La ICANN publica un nuevo anclaje de confianza para las DNSSEC para prepararse para 2026, agosto de 2024
- Dos años de apoyo a la implementación de las DNSSEC en África y Medio Oriente, Yazid Akanho, octubre de 2022
- Las sesiones de participación de la ICANN en LAC en 2021 alcanzaron a más de 3000 partes interesadas, Nicolás Antoniello y Daniel Fink, diciembre de 2021
- El reciente traspaso de la KSK: Resumen y próximos pasos, octubre de 2018
- Cinco años de capacitación técnica en APAC para garantizar la seguridad, estabilidad y flexibilidad de Internet, Champika Wijayatunga, septiembre de 2018
Para encontrar más blogs de la ICANN sobre las DNSSEC, utilice la palabra clave "DNSSEC" en el cuadro de búsqueda de esta página.
Documentos de la ICANN
- OCTO-035: Observación de los ciclos de vida de las claves de las DNSSEC, julio de 2022
- OCTO-033: Uso del algoritmo de las DNSSEC en 2022, abril de 2022
- OCTO-029: Guía de implementación de las DNSSEC para los ccTLD, noviembre de 2021
- OCTO-012: Revisión del traspaso de la KSK de las DNSSEC en 2018, julio de 2020
- OCTO-006: DNSSEC: Protección del DNS, actualizado en julio de 2020
- Archivo de proyectos de las DNSSEC: documentos archivados de proyectos específicos de la comunidad relacionados con el desarrollo y la evolución de las DNSSEC en la Zona Raíz. No se debe depender de ellos para obtener información actualizada sobre las operaciones y se proporcionan únicamente con fines históricos.