Resolución DNS, de Principio a Fin

Cada vez que escribes un dominio en un navegador, una cadena de búsquedas se dispara antes de que un solo paquete llegue al sitio que quieres. La mayor parte de esa cadena es invisible, y la mayoría de las explicaciones sobre ella se detienen en "es como una guía telefónica". Aquí está lo que realmente sucede, paso a paso, incluyendo las partes que la gente normalmente salta.

El stub resolver no es inteligente

Tu sistema operativo no hace una resolución DNS real por sí solo. Ejecuta un stub resolver, un código delgado que simplemente reenvía tu consulta a cualquier servidor DNS configurado en /etc/resolv.conf en Linux o en la configuración de tu adaptador de red en Windows. Verifica el tuyo con:

cat /etc/resolv.conf

Ese archivo usualmente apunta a tu router (como 192.168.1.1), el resolver de tu ISP, o uno público como 1.1.1.1 u 8.8.8.8. El stub resolver no tiene lógica de caché propia más allá de la que proporciona el sistema operativo o un daemon local como systemd-resolved.

El resolver recursivo hace el trabajo real

Una vez que tu consulta llega a un resolver recursivo, ese servidor toma el trabajo de encontrar la respuesta, incluso si tiene que preguntar a múltiples otros servidores para hacerlo. Si la respuesta ya está cacheada de una búsqueda anterior, la obtienes inmediatamente. Verifica el TTL con:

dig example.com

Mira la ANSWER SECTION — el número antes del tipo de registro (como 300 antes de A) es el TTL en segundos. Ese es el tiempo durante el cual los resolvers pueden cachear el registro antes de preguntar de nuevo.

Si nada está cacheado, el resolver recursivo comienza una búsqueda por la jerarquía DNS desde la raíz.

Servidores raíz, TLD y autorizados

Hay 13 direcciones de servidor raíz (a.root-servers.net hasta m.root-servers.net), cada una respaldada por muchas máquinas físicas a través de enrutamiento anycast. El servidor raíz no sabe dónde vive example.com, pero sabe qué servidores manejan .com, así que devuelve una referencia.

El resolver entonces pregunta a un servidor TLD .com, que nuevamente no conoce la respuesta final pero sabe qué nameservers son autorizados para example.com específicamente. Puedes ver esta delegación por ti mismo:

dig +trace example.com

Ese comando muestra cada paso: raíz, luego TLD, luego los nameservers autorizados para el dominio, terminando con el registro A o AAAA actual. Es el mejor comando para entender DNS visualmente en lugar de teóricamente.

El nameserver autorizado es la última parada. Es el servidor que el propietario del dominio realmente configuró, a menudo a través del panel DNS de un registrador o un servicio como Route 53 o Cloudflare DNS. Este es el único servidor en toda la cadena que tiene la respuesta real y canónica en lugar de una copia cacheada o una referencia.

Tipos de registros que realmente encontrarás

Un registro A mapea un nombre a una dirección IPv4, AAAA hace lo mismo para IPv6. CNAME apunta un nombre a otro nombre en lugar de una IP, que es cómo las CDNs como Cloudflare o Fastly enrutan tráfico sin exponer IPs crudas. Los registros MX manejan el enrutamiento de correo, y los registros TXT transportan texto arbitrario, ahora usado más comúnmente para SPF, DKIM, y cadenas de verificación de dominio. Los registros NS le dicen al mundo qué servidores son autorizados para una zona, y ese es el tipo de registro que hace posible la delegación en primer lugar.

Dónde vive realmente el caché

El caché ocurre en múltiples capas simultáneamente: el navegador en sí (Chrome tiene su propio caché DNS visible en chrome://net-internals/#dns), el caché del resolver del SO, el router local, y el resolver recursivo en la parte superior. Por eso un cambio de DNS puede parecer que funciona instantáneamente en un dispositivo y tomar horas para mostrarse en otro — no estás golpeando el mismo caché.

Cuando bajas el TTL de un registro antes de una migración planeada, no estás acelerando nada inmediatamente. Solo estás reduciendo la ventana durante la cual datos obsoletos pueden persistir una vez que el cambio realmente ocurra. Hazlo al menos un ciclo de TTL antes, no cinco minutos antes del cambio.

Por qué esto importa para la solución de problemas

Cuando un sitio es inaccesible, dig +trace te dice exactamente qué capa está rota: un problema de raíz/TLD se ve completamente diferente a un servidor autorizado mal configurado o un caché obsoleto en tu propia máquina. Comparar dig example.com contra un resolver conocido y funcional, como dig example.com @1.1.1.1, aísla si el problema es tu resolver local o la configuración DNS real del dominio.

DNS se ve simple desde afuera porque normalmente se resuelve en menos de 100ms y nadie piensa en ello. Debajo, es un sistema de consulta distribuido, cacheado y jerárquico que ha estado funcionando prácticamente sin cambios en estructura desde los años 80, lo que es un argumento bastante bueno para lo bien que el diseño original resistió.

Si quieres profundizar en esto, Korra Studio tiene segmentos relacionados en DEFENSE_GRID cubriendo extensiones de seguridad de DNS, tunelización DNS como técnica de exfiltración, y construir tu propio resolver desde cero en Python.