Servidor DNS: ¿Qué es y cómo funciona?

¿Alguna vez te has preguntado cómo es que el navegador sabe qué página abrir cuando escribes la dirección en la barra de direcciones? En realidad, esto es algo que se resuelve en la comunicación entre computadoras, y es más profundo de lo que parece a simple vista.

En las décadas de 1970 a 1990, existía una red llamada ARPANET. Esta red fue un esfuerzo del Departamento de Defensa de los Estados Unidos para conectar numerosas computadoras y permitir la transferencia de información durante situaciones de guerra. La importancia de esta red radicaba en su capacidad para transferir información de manera rápida y eficiente a largas distancias. Los principios de funcionamiento de ARPANET sentaron las bases del Internet moderno.

Inicialmente, esta red conectaba computadoras en cuatro instituciones diferentes de los Estados Unidos:

• Universidad de California en Los Ángeles.
• Centro de Investigación de Stanford.
• Universidad de Utah.
• Universidad de California en Santa Bárbara.

Los científicos de estas instituciones decidieron crear una nueva red para transmitir información entre ellos. Para ello, solo necesitaban conocer el identificador de la computadora a la que querían enviar el mensaje, conocido como dirección IP. Con el crecimiento de la red a miles de computadoras en la década de 1980, se volvió difícil recordar todas las direcciones IP. Se necesitaba un sistema que asignara nombres comprensibles a las computadoras y almacenara todas las direcciones en un solo lugar.

El archivo hosts: el primer paso hacia la creación de DNS

Para resolver este problema, los desarrolladores decidieron utilizar un diccionario que vinculara el nombre único con la dirección IP de cada computadora en la red. Este diccionario era el archivo hosts.txt, que era responsable de vincular la dirección IP con el nombre de la computadora. El archivo se encontraba en el servidor del Centro de Investigación de Stanford, y los usuarios de la red lo descargaban regularmente en sus computadoras para mantener actualizado el diccionario, ya que nuevas computadoras aparecían en la red casi todos los días.

El archivo hosts.txt se veía así (y todavía se ve así):

192.168.10.36         MIKE-STRATE-PC
Dirección IP          Nombre de la computadora

Si tenías este archivo en tu computadora, podías usar el nombre en inglés "MIKE-STRATE-PC" en lugar de recordar los números.

Veamos cómo se ve el archivo y tratemos de agregar un nuevo nombre para conectarnos a una computadora usando ese nombre. Para hacer esto, editaremos el archivo hosts. Puedes encontrarlo en tu computadora en la siguiente ubicación:

• En sistemas Unix: /etc/hosts
• En sistemas Windows: %Ruta a la carpeta Windows%/system32/drivers/etc/hosts

▶ Ver la grabación de la terminal

Hemos asignado el nombre "MIKE-STRATE-PC" a la computadora con la dirección IP 192.168.10.36 que se encuentra en la red local. Después de eso, podemos usar el comando ping, que envía una solicitud especial a la computadora de Mike y espera una respuesta. Es similar a tocar la puerta o llamar al timbre para preguntar "¿hay alguien en casa?". Puedes enviar esta solicitud a cualquier computadora.

▶ Ver la grabación de la terminal

A medida que la red se desarrollaba y se "llenaba" con nuevos clientes, este enfoque se volvía incómodo. Todos los usuarios de las computadoras tenían que descargar cada vez más a menudo una nueva versión del archivo desde el servidor del Centro de Investigación de Stanford, que se actualizaba manualmente varias veces a la semana. Para agregar nuevas versiones, era necesario comunicarse con el instituto y solicitarles que agregaran nuevos valores al archivo.

En 1983, Paul Mockapetris describió un nuevo sistema llamado DNS (Domain Name System / Sistema de Nombres de Dominio) en los documentos RFC 882 y RFC 883. El estándar vigente se definió en 1987 (RFC 1034 y RFC 1035). El sistema tenía como objetivo automatizar los procesos de asignación de direcciones IP a nombres de dominio y actualizar los nombres para los usuarios sin la necesidad de descargar manualmente el archivo desde un servidor externo.

Cómo funciona DNS en Internet

En la actualidad, Internet nos rodea en todas partes: lo usamos en dispositivos móviles y de escritorio. Los sistemas de videovigilancia e incluso las teteras se comunican entre sí a través de Internet, y para establecer una conexión correcta con ellos, se necesita un sistema que permita a los usuarios conectarse a un servicio específico con una sola solicitud en la barra de direcciones. Todo esto recae en el sistema DNS, que almacena mucha más información que solo la dirección IP y el nombre del dispositivo. Los registros DNS también son responsables de enviar correos electrónicos correctamente, vincular diferentes dominios y zonas de dominio.

DNS es un sistema distribuido, lo que significa que tiene muchos nodos, cada uno de los cuales es responsable de su propia zona. Esto es posible gracias a que la estructura misma de DNS es jerárquica, lo que significa que asigna zonas de responsabilidad, donde cada padre conoce la ubicación de su servidor secundario y conoce la zona de responsabilidad de este último.

Veamos más de cerca cómo funciona DNS y sus componentes.

Terminología

Los componentes principales de DNS son:

Dominio (nombre de dominio): es un nombre simbólico que se utiliza para identificar un servidor en Internet. Los nombres de dominio son una estructura jerárquica en la que cada nivel se separa por un punto. Los niveles principales son:

• Dominio raíz. No se utiliza en la URL, pero siempre se da por sentado. Es el punto de partida para construir todas las URL en Internet
• Dominios de nivel superior. Estos incluyen dominios como .com, .net, .org y los dominios de país como .mx, .co, .ar, .pe o .la. También se les llama dominios de primer nivel
• Dominio de segundo nivel (o dominio principal). Este es el nombre principal de tu sitio web
• Subdominios (dominios de tercer, cuarto, quinto nivel, etc.). Estos incluyen todos los subdominios del dominio principal.

Servidor DNS: es el sistema responsable de almacenar y mantener actualizados los registros de sus dominios secundarios. Cada servidor DNS es responsable solo de su zona, es decir, el servidor DNS del dominio .la sabe dónde se encuentra el dominio codica.la, y el servidor DNS de codica.la sabe dónde se encuentran sus subdominios.

Servidor DNS raíz: es el sistema que conoce la ubicación (dirección IP) de los servidores DNS de los dominios de nivel superior.

Registro de recursos: es una unidad de información del servidor DNS. Cada registro de recursos tiene varios campos:

• Nombre (dominio al que pertenece el registro)
• Tipo
• Parámetros
• Valor

Conexión

Es importante entender que el nombre de dominio es solo una abstracción para las personas. La computadora y las aplicaciones (como el navegador) se comunican con los servicios dentro de la red de Internet solo a través de direcciones IP.

Veamos el proceso de obtener una dirección IP a partir de un nombre de dominio utilizando el ejemplo del dominio app.codica.la.

Hay dos posibles escenarios.

1. La computadora envía una solicitud a un servidor DNS conocido. Por lo general, este es el servidor DNS de tu proveedor de servicios de Internet (ISP) o un resolvedor público, y la pregunta es ¿cuál es la dirección IP del dominio app.codica.la*?*. El servidor DNS del proveedor de servicios de Internet busca en su base de datos la información de que el dominio app.codica.la se encuentra en la dirección IP 104.25.238.104 y devuelve esta información a tu computadora. Este proceso es similar al uso del archivo hosts.txt.
2. El servidor DNS más cercano no tiene información sobre la dirección IP del dominio app.codica.la. En este caso, se inicia una cadena de consultas que permite a tu computadora obtener la dirección IP del dominio.
   1. Como el dominio es una estructura jerárquica y todos los servidores DNS conocen las direcciones de los servidores DNS raíz, la solicitud se envía primero a uno de ellos.
   2. El servidor raíz conoce la ubicación de los servidores DNS de los dominios de nivel superior y devuelve al servidor DNS de tu proveedor las direcciones de los servidores del dominio .la.
   3. El servidor DNS del dominio .la, de acuerdo con su zona de responsabilidad, devuelve las direcciones de los servidores DNS de codica.la.
   4. El servidor DNS de codica.la devuelve el registro A del subdominio app. Después, el servidor DNS de tu proveedor entrega esta dirección a tu computadora, que ya puede acceder a app.codica.la a través de su dirección IP.

Recursividad en DNS

Puedes notar que los dos escenarios descritos anteriormente son muy diferentes: en el primer caso, simplemente enviamos una solicitud y obtenemos una respuesta, mientras que en el segundo caso, tenemos que ir desde el dominio raíz en el proceso de búsqueda de la entrada que necesitamos. Este proceso se llama búsqueda recursiva, ya que el servidor DNS más cercano envía continuamente solicitudes a otros servidores DNS hasta que obtiene los registros de recursos necesarios. Este proceso se puede visualizar de la siguiente manera:

En las solicitudes 1 y 2, el servidor más cercano obtendrá información sobre la ubicación de los servidores DNS que están en su zona de responsabilidad, a los que se envió la solicitud. En la solicitud 3, se obtendrán los registros de recursos necesarios para el dominio codica y sus subdominios.

La búsqueda recursiva es una operación bastante lenta que también carga la red y los propios servidores DNS. Para eliminar la recursividad, cada servidor DNS almacena en caché la información de los registros que recibe para una entrega rápida de esta información al usuario.

Como se puede ver, la búsqueda recursiva implica encontrar una respuesta final a nuestra solicitud buscando registros en todos los servidores DNS necesarios, comenzando desde el dominio raíz. En contraste, también existe una consulta iterativa, que a diferencia de la recursiva, realiza solo una iteración, que es una solicitud al servidor DNS más cercano del que podemos obtener una respuesta en caché o los datos de la zona de responsabilidad de ese servidor. Es importante tener en cuenta que una consulta iterativa implica solo una solicitud.

La mayoría de los servidores DNS en Internet pueden enviar solicitudes recursivas, ya que esto permite almacenar en caché la respuesta, lo que reduce la carga tanto en el servidor como en otros servidores DNS. El tiempo durante el cual el servidor DNS almacena en caché la información se especifica en el registro de recursos DNS que se discutirá a continuación.

Registros de recursos DNS

El Internet moderno implica no solo obtener una dirección IP a partir de un nombre de dominio, sino también el envío de correos electrónicos, la conexión de servicios adicionales de análisis a un sitio web, la configuración del protocolo seguro HTTPS. Esto se hace principalmente a través de registros de recursos DNS.

Veamos qué registros de recursos se utilizan y a qué apuntan. Los registros de recursos DNS principales son:
Registro A: uno de los registros más importantes. Este registro apunta a la dirección IP del servidor que está vinculado al nombre de dominio.

Registro MX: apunta al servidor que se utilizará para enviar correo electrónico de dominio.

Registro NS: apunta al servidor DNS del dominio.

Registro CNAME: convierte un nombre en un alias de otro nombre. Por ejemplo, www.ejemplo.com puede ser un alias de ejemplo.com o del nombre que te da tu servicio de alojamiento. Un nombre con CNAME no puede tener otros registros al mismo tiempo, por eso en la raíz del dominio (ejemplo.com) normalmente no se usa CNAME. Algunos proveedores ofrecen para ese caso registros propios como ALIAS o ANAME, que no forman parte del estándar.

Registro TXT: este registro almacena información de texto sobre el dominio. A menudo se utiliza para confirmar los derechos de propiedad del dominio mediante la adición de una cadena específica enviada por el servicio de Internet. También se usa para la seguridad del correo, con las políticas SPF, DKIM y DMARC, que indican qué servidores pueden enviar correo en nombre de tu dominio.

Otros registros útiles. El registro CAA indica qué autoridades pueden emitir certificados HTTPS para tu dominio, el registro SRV señala el servidor y el puerto de ciertos servicios, y los registros HTTPS y SVCB dan a los navegadores parámetros de conexión junto con la dirección. Casi todos los proveedores de dominios y alojamiento tienen un panel donde puedes crear estos registros sin usar la línea de comandos.

Los registros de recursos son casi siempre los mismos, pero algunos registros pueden tener otros campos, por ejemplo, los registros MX también tienen un valor de prioridad. En su mayoría, los registros de recursos tienen la siguiente estructura:

Nombre del registro   TTL   Clase   Tipo de registro  Valor

Desglosemos esto en más detalle:

Nombre del registro: es el dominio al que pertenece el registro de recursos.

TTL (tiempo de vida): es el tiempo en segundos durante el cual el valor del registro de recursos se almacenará en caché. Esto es necesario para aliviar la carga en los servidores DNS. Gracias al almacenamiento en caché, es posible que el servidor DNS más cercano conozca la dirección IP del dominio solicitado.

Clase: originalmente, DNS podía funcionar no solo en Internet, por lo que se especifica la clase en el registro. Actualmente, solo se admite un valor: IN (Internet).

Tipo: especifica el tipo de registro de recursos, los principales de los cuales se discutieron anteriormente.

Valor: es el valor real del registro de recursos. Dependiendo del tipo de registro de recursos, los valores pueden tener diferentes formatos.

Veamos cómo se almacenan estos registros en los servidores DNS utilizando el dominio example.com como ejemplo. Es un dominio reservado para documentación, y las direcciones y los valores de abajo son ilustrativos. Para esto, usaremos la utilidad dig, que consulta los registros DNS de un dominio y los muestra al usuario.

La utilidad dig es un cliente DNS y es parte de uno de los servidores DNS más comunes, BIND.

Se consulta cada tipo de registro por separado.

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com SOA

También existe la consulta ANY, que en su momento devolvía todos los registros de una vez. Hoy muchos servidores responden a ella con una respuesta mínima o truncada (RFC 8482), así que no es una forma fiable de ver todos los registros.

Ejemplos de registros DNS reales

No te asustes por la salida de dig. Incluso ahora, puedes entender casi todo lo que se muestra aquí. Analicemos cada sección con más detalle.

La salida consta de varias partes.

• Encabezado
• Sección de consulta
• Sección de respuesta
• Información de servicio

Encabezado de la consulta

; <<>> DiG 9.18 <<>> example.com A
;; Got answer.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52109
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Aquí se indican las banderas establecidas en nuestra solicitud, la cantidad de solicitudes y respuestas, así como otra información de servicio.

Sección de consulta

;; QUESTION SECTION:
;example.com.   IN    A

En la sección de consulta se indica el dominio al que se está accediendo, la clase de registro y el tipo de registro que queremos obtener. Aquí pedimos el registro A, pero con la misma utilidad puedes pedir cualquier otro tipo, como MX o TXT.

Sección de respuesta

La sección de respuesta cambia según el tipo de registro. Veamos un ejemplo de cada uno, con valores ilustrativos.

;; ANSWER SECTION (dig example.com NS)
example.com. 	86400	IN	NS	 ns1.example.com.
example.com. 	86400	IN	NS	 ns2.example.com.

;; ANSWER SECTION (dig example.com A)
example.com.	300	IN	A	 203.0.113.10

;; ANSWER SECTION (dig example.com AAAA)
example.com.	300	IN	AAAA	 2001:db8::10

Tanto el registro A como el registro AAAA apuntan a la dirección IP que está vinculada a nuestro dominio. El registro A apunta a una dirección IP en formato IPv4, mientras que el registro AAAA apunta a una dirección IP en formato IPv6.

;; ANSWER SECTION (dig example.com MX)
example.com.	3600	IN	MX	 10 mail.example.com.
example.com.	3600	IN	MX	 20 mail2.example.com.

El registro MX también tiene un parámetro de prioridad. Dado que puede haber varios servidores para enviar correo electrónico, puede haber muchos registros, por lo que se especifica la prioridad del registro para determinar el servidor principal. Cuanto menor sea el número, mayor será la prioridad.

;; ANSWER SECTION (dig example.com SOA)
example.com.	3600	IN	SOA	 ns1.example.com. admin.example.com. 2026102701 7200 3600 1209600 3600

Registro SOA (Start of Authority) apunta a varios parámetros diferentes:

1. El servidor con la información de referencia para el dominio actual.
2. Información de contacto de la persona responsable.
3. Varios parámetros de almacenamiento en caché de registros.

Existen otros registros de recursos más específicos sobre los que no se habló aquí, pero esto no significa que sean inútiles. Siempre puedes encontrar una lista completa de tales registros en la documentación (por ejemplo, para el servidor DNS BIND).

Conclusiones

Los servidores DNS son la base de Internet en la actualidad y se utilizan en casi todas las acciones que los usuarios realizan en la red, ya sea visitar un sitio web, enviar correos electrónicos, trabajar con una aplicación de Internet en un teléfono, etc. Por lo tanto, el conocimiento de los principios de funcionamiento de los servidores DNS y los registros de recursos principales, que permiten la navegación en la red de Internet, es importante para los desarrolladores.

DNS hoy

Los principios son los mismos de hace décadas, pero el entorno cambió.

• Resolvedores públicos. Además del DNS de tu proveedor de Internet, puedes usar resolvedores públicos como 1.1.1.1 (Cloudflare) o 8.8.8.8 (Google).
• Consultas cifradas. Tradicionalmente las consultas DNS viajan sin cifrar. Los protocolos DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT) las cifran entre tu dispositivo y el resolvedor, y muchos navegadores y sistemas operativos ya los admiten.
• DNSSEC. Es una extensión que firma los registros para que se pueda comprobar que no fueron alterados en el camino. Requiere que el dominio y su zona lo tengan activado.
• CDN. Muchos sitios están detrás de una red de entrega de contenido (CDN). En ese caso, la dirección IP que devuelve DNS suele ser la de la CDN y no la del servidor donde está alojado el sitio, así que la IP de un dominio no siempre indica dónde vive el servidor.

Recursos adicionales

Un cómic divertido sobre cómo funciona DNS (en inglés)