Skip to main content
Resources

DNSSEC – ¿Qué son y por qué son importantes?

Esta página está disponible en:

¿Te interesa aprender sobre las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC)? Haz clic en la imagen que figura a continuación para ver nuestra infografía, donde encontrarás una descripción de las DNSSEC y los beneficios de su implementación.

BENEFITS OF DEPLOYING DNSSEC

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, cada imagen obtenida de un medio social: todas estas interacciones usan el DNS para traducir nombres de dominio sencillos para los usuarios (como icann.org) a las direcciones IP (como 192.0.43.7 y 2001:500:88:200::7) necesarias para que servidores, enrutadores y otros dispositivos de red dirijan el tráfico en Internet al destino correspondiente.

El uso de Internet en cualquier dispositivo comienza con el DNS. Por ejemplo, considere cuando un usuario escribe el nombre de un sitio web en un navegador en su teléfono. El navegador usa 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 cliente más complicado del DNS denominado resolutor recursivo. 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 estado brindando 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 (DNSSEC)

Los ingenieros del Grupo de Trabajo en Ingeniería de Internet (IETF), la organización responsable de los estándares del protocolo del DNS, hace mucho tiempo que se dieron cuenta de que la falta de una autenticación más sólida en el DNS era un problema. En la década de 1990 comenzaron a trabajar en una solución y el resultado fue la creación de las Extensiones de Seguridad del DNS (DNSSEC).

Las DNSSEC refuerzan la autenticación en el DNSSEC mediante el uso de firmas digitales basadas en la criptografía 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 gTLD y muchos 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. Asimismo, nuevas formas de agregar privacidad a las consultas del DNS podrán usar DANE en el futuro.

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, y el mundo pudo ver más claramente cómo funcionaba todo el sistema de las DNSSEC. 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.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."