featured image

Tras hablar hace tiempo del sistema web y del sistema de correo veo fundamental y complementario a estos abrir un nuevo cómo funciona para hablar del sistema de nombres (o DNS) que permite traducir nombres como altenwald.com en direcciones IP a través de una consulta a un servidor. ¿Sábes cómo funciona?

Actualización (24 de octubre de 2018): se han revisado los artículos referentes al tema cómo funciona. Si tienes alguna sugerencia acerca de algún servidor que quieras saber cómo funciona, déjanos un comentario.

Para acceder a una máquina en Internet usamos su dirección IP, ya sea versión 4 (a.b.c.d) siendo cada número de 8 bits o versión 6 donde cada número es de 16 bits (hablaré de IPv6 en un futuro artículo).

Los números son propensos a confusión y pueden olvidarse fácilmente. Sin embargo, un nombre es más fácil de recordar y puede hacer referencia al tipo de contenido o acceso que buscamos. Por este motivo se comenzaron a emplear nombres en lugar de direcciones IP para el uso cotidiano.

Tenemos dos formas de poder usar nombres: fichero hosts y servidor DNS.

Fichero Hosts

Los sistemas operativos disponen de un fichero donde poner la equivalencia de una IP hacia un nombre. Este fichero es conocido normalmente como /etc/hosts.

Este fichero suele tener este contenido:

127.0.0.1  localhost.localdomain localhost

De esta forma cuando usamos localhost la máquina lo traduce gracias a este fichero a 127.0.0.1 que es la interfaz local.

Como segunda línea suele aparecer también la dirección IP del equipo con el nombre de red que se le proporcionó vía DHCP (Dynamic Host Configuration Protocol).

Si necesitamos agregar un nombre para ser traducido en nuestra máquina local como una IP específica podemos agregarlo a este fichero. Es muy útil cuando desarrollamos páginas web y necesitamos probar con el nombre de dominio apuntando a nuestra IP local.

Servidor DNS

El servidor DNS es algo más completo. Los nombres en Internet se organizan jerárquicamente a través de TLDs (Top Level Domains). Por ejemplo, un dominio como google.com estará almacenado en la zona com del TLD que maneje los com. Este TLD contiene subzonas para todos los nombres que almacena. Por tanto, google será una subzona almacenada en otro servidor DNS con una configuración concreta para google.com y otros niveles como www.google.com.

Los servidores DNS se organizan en zonas como hemos visto. Estas son jerárquicas. Podemos tener tantos niveles como necesitemos.

Además, en cada zona podemos configurar no solo la traducción de un nombre a una IP sino también alias y otro tipo de registros que nos facilitarán la configuración de servicios específicos.

Registros A y AAAA

Una de las configuraciones más comunes en un servidor DNS son los registros de tipo A (Address o Dirección) o en su formato de IPv6: AAAA.

Este registro nos indica una traducción de un nombre a una dirección IP. En los ficheros de configuración de los servidores DNS podemos ver entradas como:

@      IN A 1.2.3.4
www    IN A 1.2.3.4

Registros CNAME

Otro de los registros que podemos encontrar frecuentemente es el CNAME (Canonical Name). Este registro se emplea como alias:

@      IN CNAME www
www    IN A 1.2.3.4

Así evitamos escribir la dirección IP más de una vez y en caso de necesitar cambiarla. Solo la cambiamos una vez.

Registros MX

El registro MX (Mail eXchange o intercambio de correo) es un registro especial para indicar la dirección IP o nombre de máquina que se hará cargo del correo para este dominio o subdominios:

@      IN CNAME www
www    IN A 1.2.3.4
mail   IN CNAME www
@      IN MX 10 mail

Esta configuración indica que mail se hará cargo de los emails del dominio. El número que aparece entre MX y el nombre de la máquina es la prioridad. Podemos agregar tantos registros MX como necesitemos para indicar servidores de correo secundarios en caso de que el primer servidor no esté disponible.

Registros TXT

Los registros TXT contienen texto como su nombre indica. Normalmente este texto corresponde a una cadena necesaria para la comprobación de autoridad, autenticación o pertenencia hacia otros protocolos.

Por ejemplo, el sistema DKIM nos permite almacenar la clave pública con la que los emails serán firmados al ser enviados por nuestro servidor de correo.

También relacionado, el sistema SPF puede estar contenido en un registro de este tipo para indicar la configuración de credibilidad de un servidor que envía un email.

Los sistemas DMARC también emplean estos registros para agregar la dirección de email a la que remitir el informe de emails recibidos por parte de esos dominios.

Por último, también Google y Let's Encrypt usan estos registros para asegurar la pertenencia de los dominios y dar de alta servicios.

Otros registros

Hay otros registros especiales como SRV o SPF que tienen diferentes utilidades. Estos escapan un poco del ámbito de intentar conocer cómo funciona el servidor DNS por lo que no entraré en detalles. Dejaré al lector que pueda leer más información sobre ellos en otros sitios como:

Nombre relativo o absoluto

Suponiendo que estemos configurando el dominio google.com al agregar los registros anteriores se completarán como www.google.com. con punto final. Si nuestro segundo serivdor de email está en otro dominio:

@      IN CNAME www
www    IN A 1.2.3.4
mail   IN CNAME www
@      IN MX 10 mail
@      IN MX 20 mail.google.es.

El nombre del dominio mail.google.es. termina en punto para informarnos de que es un nombre completo y no debe completarse. Cuando escribimos en las secciones anteriores los nombres tan solo como www o mail (sin punto final) indica que deben ser completados con el dominio al que pertenecen.

¿Cómo funciona el servicio DNS?

DNS (Domain Name Server) es un servidor de nombres disponible en Internet a través del puerto 53 (tcp). Hay herramientas como lookup o dig que nos permiten hacer preguntas directas a los servidores de nombres para obtener traducciones.

Emplearemos dig para hacer un par de pruebas. En principio veamos una salida básica:

$ dig www.google.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27869
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         227     IN      A       172.217.20.164

;; Query time: 0 msec
;; SERVER: 213.133.100.100#53(213.133.100.100)
;; WHEN: Mon May 15 14:41:04 2017
;; MSG SIZE  rcvd: 48

El comando contiene bastantes comentarios (comenzando por punto y coma -;-) y obtenemos varias secciones: QUESTION SECTION y AUTHORITY SECTION son las más importantes. La primera nos da la pregunta enviada al servidor y la segunda su respuesta.

Tras el dominio encontramos un número (227). Este es el TTL (Time-To-Live o Tiempo de Vida) del registro. Los servidores DNS se pueden configurar también para hacer caché de consultas. El servidor DNS configurado en nuestro sistema es el servidor de caché de nuestro proveedor de acceso a Internet (o quizás uno propio nuestro). Este servidor guarda una caché de las peticiones y este número indica el tiempo que queda (en segundos) para la siguiente petición real al servidor remoto (el siguiente en la cadena).

Por último vemos la traducción del registro a una dirección IP.

Si agregamos mx como otro parámetro a dig obtenemos los registros MX en lugar del registor A para el nombre:

$ dig google.com mx

Además podemos preguntar a un servidor DNS específico así:

$ dig @8.8.8.8 www.google.com

Compro un Dominio, ¿dónde está la zona?

Cuando compramos un dominio y solo el dominio la configuración nos solicita agregar 4 o más nombres de servidores DNS donde estará almacenada la zona para configurar los nombres de nuestro dominio.

Normalmente nuestro proveedor nos facilita la configuración de la zona en sus propios servidores y nos proporciona por defecto estos nombres. En la configuración de la zona estos nombres aparecen como registros de tipo NS (name server).

No obstante si queremos configurar nuestra zona en otro proveedor como Route53 de Amazon, por ejemplo, tendríamos que emplear la configuración de los nombres host del servicio de Route53 de Amazon para el nuevo nombre. Así al utilizar el nombre el TLD dirigirá las peticiones a esos servidores de nombres.

Los cambios no son inmediatos

Obviamente con tantos servidores DNS haciendo caché entre tu servidor y el navegador que accede a tu sitio web cualquier cambio dependerá de la última vez que se accediese al servidor DNS para consultar por los servidores intermedios.

Podemos acortar este tiempo a 60 segundos en lugar de los 3600 segundos o incluso hasta las 6 horas que configuran los servidores DNS por defecto.

Características avanzadas de los servidores DNS

En estos últimos años los servidores DNS han presentado un gran número de características avanzadas que vale la pena tener en cuenta. Por ejemplo geoip. Dependiendo de la IP que consulte al servidor DNS se da una IP u otra en función de los centros de datos donde está distribuido nuestro sitio web y el más rápido para el usuario que quiere acceder.

También algo más antiguo es el balanceo de carga round-robin agregando varias entradas de tipo A para diferentes direcciones IP.

En temas de seguridad además de contar con los registros SRV que nos facilitan la identidad de los servicios de nuestro dominio, y SPF para información de aceptación de emails, contamos con el registro TXT donde se almacenan recientemente incluso hasta certificados para garantizar la identidad del sitio.

Conclusiones

Ha sido un repaso muy a grosso modo de cómo funciona el sistema de nombres y los servidores DNS en general. Realmente desde la compra de un dominio, la configuración de un sistema para atender peticiones DNS y la configuración de las zonas para atender estas peticiones hay muchos aspectos que se han quedado en el aire y pueden generar dudas y nuevas preguntas. Si es este tu caso y quieres saber más, no dudes, pregunta a través de los comentarios e iremos completando aún más el artículo si es necesario.