Qué Es el DNS y Cómo Funciona la Resolución de Nombres

Qué hace el DNS en cada petición

Toda petición a example.com empieza con una búsqueda que no tiene nada que ver con tu aplicación: algo tiene que convertir ese nombre en una dirección IP antes de que un solo paquete TCP salga de la máquina. Esa traducción es el DNS, el Domain Name System, y se ejecuta en cada petición, sea el cliente un navegador, curl o un servicio backend que llama a otro por hostname.

Detrás no hay una única tabla. El DNS es una jerarquía de servidores, cada uno responsable de una parte del namespace, consultados en secuencia hasta que llega la respuesta. Conocer esa cadena es lo que convierte “el sitio está caído” en “el certificado ha caducado” o “el registro sigue apuntando a la IP antigua”: dos problemas muy distintos que desde una pestaña del navegador parecen idénticos.

Cómo recorre un resolver recursivo la jerarquía DNS

Dos tipos de servidor hacen el trabajo, con funciones distintas. El resolver recursivo es con el que habla tu máquina: el de tu proveedor de internet, o uno público como 1.1.1.1 u 8.8.8.8. Hace el recorrido por ti y devuelve una única respuesta final. Los servidores autoritativos guardan los registros reales de un dominio, repartidos en una jerarquía que refleja los puntos del nombre.

1
2
3
4
5
6
7
8

cliente  ->  resolver                             una consulta, una respuesta
             resolver -> root server              "¿quién gestiona .com?"
                      <- nameservers de .com
             resolver -> servidor TLD .com        "¿quién gestiona example.com?"
                      <- nameservers de example.com
             resolver -> nameserver example.com   "¿registro A de example.com?"
                      <- 93.184.216.34
cliente  <-  resolver                             93.184.216.34

Los root servers no saben nada de example.com. Solo saben qué servidores gestionan .com. El servidor TLD (top-level domain) de .com tampoco guarda el registro; solo sabe qué nameservers son autoritativos para example.com, los que tu registrador configura cuando das de alta el dominio. Solo ese último servidor tiene el registro A y devuelve una IP. Tres saltos, para que tu máquina nunca tenga que saber que esa jerarquía existe.

La mayor parte de ese recorrido no ocurre en una consulta real. Los resolvers cachean las respuestas de root y TLD durante horas o días, porque apenas cambian, así que una consulta real suele empezar ya en el servidor autoritativo del registro concreto. A menudo ni siquiera llega hasta ahí: la respuesta ya está en caché.

Los tipos de registro DNS que usarás de verdad

El servidor autoritativo de un dominio guarda un conjunto de registros, cada uno una respuesta distinta a una pregunta distinta:

El CNAME es el que confunde a todo el mundo. No apunta a una IP; apunta a otro nombre, y el resolver tiene que buscar también ese, siguiendo la cadena hasta llegar a un registro A o AAAA. Una CDN o una plataforma SaaS te da un hostname como abcd123.cloudfront.net justo por eso: puede cambiar las IP detrás de ese nombre cuando haga falta, y devolver una distinta según de dónde venga la consulta, sin que tú toques tu registro DNS.

Hay una restricción que atrapa a cualquiera que configure un dominio desnudo: un CNAME no puede coexistir con otros registros en el mismo nombre, y el ápice de la zona (example.com sin subdominio) siempre necesita registros NS y SOA. Así que no puedes poner un CNAME del ápice al hostname de una CDN, solo de un subdominio como www. Los proveedores lo resuelven con lo que llaman ALIAS, ANAME, o CNAME flattening: el servidor autoritativo resuelve él mismo el destino y devuelve un registro A, así el ápice parece un registro de dirección normal para cualquier cliente, aunque por detrás sigue las IP cambiantes de la CDN.

Cómo consultar el DNS con dig

dig hace estas preguntas directamente, sin la caché de un navegador de por medio.

1

dig example.com

La parte que importa es la ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Cinco campos, en orden: el nombre consultado, el TTL en segundos (cuánto tiempo puede cachearse esta respuesta), la clase (IN de internet, en la práctica siempre esta), el tipo de registro y el valor. Un TTL de 300 significa que cualquier resolver con esta respuesta la vuelve a consultar antes de cinco minutos.

Consulta un tipo concreto en vez del A por defecto:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Añade +short cuando quieras solo el valor, que es lo que te interesa en un script:

1
2

dig +short example.com
93.184.216.34

Consulta un resolver concreto con @. Así es como compruebas si un cambio ya ha llegado a un proveedor antes de que te llegue a ti:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace repite todo el recorrido, desde el root server hasta la respuesta autoritativa, en lugar de confiar en un resultado cacheado:

1

dig +trace example.com

nslookup hace el mismo trabajo básico con una interfaz más antigua y más verbosa. Vale la pena conocerlo porque viene instalado en Windows por defecto, donde dig a menudo no está.

Por qué un cambio de DNS tarda: TTL y caché

Cambias un registro y no aparece en todas partes al instante. Al retraso se le llama “propagación”, una palabra que sugiere algo que se extiende por internet copia a copia. No se extiende nada. El nuevo valor está activo en el servidor autoritativo en el momento en que lo guardas. Lo que tarda es cada resolver que ya tenía en caché la respuesta antigua y sigue sirviéndola hasta que esa copia caduca.

Eso cambia la pregunta que hay que hacerse. No “cuánto tarda la propagación”, sino “qué TTL tenía el registro antiguo, y cuántos resolvers lo cachearon”. Un TTL de 300 segundos significa que un resolver que consultó hace un minuto sirve la respuesta antigua como máximo cuatro minutos más. Un TTL de 86400 significa que algún resolver en algún sitio responde con la IP antigua hasta un día después del cambio. Algunos proveedores además ignoran el TTL que has puesto y cachean más tiempo del que pediste, que es el otro motivo por el que dos personas en redes distintas pueden ver honestamente respuestas distintas a mitad de un cambio.

Así que planifica el cambio en lugar de esperar a que pase solo. Un día antes de una migración planificada a un nuevo servidor o una nueva CDN, baja el TTL del registro que vas a tocar a 60 o 300 segundos. Ese TTL bajo tiene que llegar primero a las cachés y hacer caducar las copias de larga duración. Después haz el cambio real: cada resolver se actualiza ahora dentro de la nueva ventana corta en vez de la antigua larga. Vuelve a subir el TTL una vez confirmado el nuevo valor.

Errores comunes de DNS, y cuándo el problema no es el DNS

Un CNAME colgado es el más habitual en la práctica. Un subdominio sigue apuntando a un servicio dado de baja, un bucket de S3 antiguo o una distribución CDN eliminada, y quien reclame ese nombre al otro lado puede servir su propio contenido bajo tu dominio. Elimina el registro DNS el mismo día en que desmontas aquello a lo que apuntaba, no semanas después.

Los registros MX ausentes o mal configurados parecen un problema del servidor de correo. Si el correo saliente funciona pero nunca llega nada, revisa el registro MX del dominio antes de tocar la configuración del servidor de correo; puede que siga apuntando a un servicio del que migraste hace meses.

Muchos reportes de “el DNS está roto” no tienen nada que ver con el DNS. Si dig example.com devuelve la IP actual correcta y el sitio sigue sin cargar, la resolución ya ha tenido éxito y el problema está más adelante: una regla de firewall, un certificado que no coincide en el handshake TLS, o un reverse proxy que enruta según una cabecera Host que no reconoce. Comprueba la respuesta con dig antes de sacar conclusiones de lo que muestra el navegador.

Qué revisar primero cuando un dominio no resuelve

Ejecuta dig +short <dominio> contra tu resolver del sistema y contra uno público (dig @1.1.1.1 +short <dominio>). Si no coinciden, estás en mitad de un cambio, y el TTL antiguo te dice cuánto más esperar. Si coinciden y la IP es correcta, el DNS ha hecho su trabajo: pasa a revisar TLS, el enrutamiento o la aplicación. Si la IP es incorrecta o no llega nada, corrígelo en el nameserver autoritativo. Vaciar tu caché local no cambia nada de lo que ve nadie más.

Artículos relacionados

• Qué Es un CDN y Cómo Funciona
• Qué Es TLS y Cómo Funciona el Cifrado HTTPS
• Qué Es un Reverse Proxy y Cómo Funciona