DNS - Cómo funciona realmente la guía telefónica de internet
Escribe example.com en tu navegador y el sitio aparece casi al instante. Pero los ordenadores no se comunican usando nombres de dominio, sino direcciones IP (por ejemplo, 93.184.216.34). El sistema que traduce los nombres de dominio en direcciones IP es el DNS (Domain Name System).
DNS fue propuesto en 1983 por Paul Mockapetris en los RFC 882/883, reemplazando el archivo HOSTS.TXT que se mantenía manualmente. En aquel momento, internet constaba de solo unos cientos de hosts, y un único archivo de texto gestionado por SRI-NIC mapeaba cada nombre de host. DNS resolvió las limitaciones de escalabilidad de ese enfoque con un sistema distribuido y jerárquico que sigue siendo uno de los componentes de infraestructura más críticos de internet.
El primer paso en el proceso de qué sucede cuando escribes una URL es precisamente esta resolución de nombres DNS.
El proceso de resolución - Cuatro etapas de consulta
Cuando tu navegador necesita la dirección IP de www.example.com, se realizan hasta cuatro etapas de consultas.
- Verificación de caché local: primero se comprueba la caché del sistema operativo, luego la del navegador. Si has visitado el dominio recientemente, la respuesta se encuentra aquí
- Consulta al resolver recursivo: si la caché falla, la consulta va a un resolver recursivo, normalmente el servidor DNS de tu ISP o un resolver público como el 8.8.8.8 de Google o el 1.1.1.1 de Cloudflare
- Consulta al servidor raíz: si la caché del resolver también falla, consulta a un servidor raíz para saber qué servidor autoritativo gestiona el TLD
.com - Consulta al servidor autoritativo: el servidor TLD
.comresponde con el servidor autoritativo deexample.com, que finalmente devuelve la dirección IP
Toda esta cadena se completa normalmente en 20-120 milisegundos. Cuando la caché acierta, la resolución tarda menos de 1 milisegundo.
Consultas recursivas vs. iterativas
La consulta de tu navegador al resolver es recursiva: el cliente dice "dame la respuesta final" y el resolver hace todo el trabajo. En cambio, las consultas del resolver a los servidores raíz y autoritativos son iterativas: cada servidor responde con "no lo sé, pero pregunta a este otro servidor", sin asumir la responsabilidad de la respuesta final. Esta división del trabajo es lo que permite a DNS escalar a miles de millones de consultas diarias.
Caché DNS - El equilibrio entre velocidad y frescura
Si cada consulta DNS tuviera que recorrer toda la cadena desde los servidores raíz, internet se paralizaría. La caché es lo que hace que DNS sea eficiente a escala global.
Cada registro DNS lleva un valor TTL (Time To Live), especificado en segundos, que dicta cuánto tiempo puede almacenarse en caché. Un TTL de 3600 significa que el registro se reutiliza durante una hora antes de que el resolver deba consultar de nuevo.
- TTL corto (60-300 segundos): los cambios DNS se propagan rápidamente. Usado por CDNs y configuraciones de conmutación por error. La contrapartida es un mayor volumen de consultas a los resolvers
- TTL largo (3600-86400 segundos): reduce la carga de los resolvers y acelera la resolución. La contrapartida es que los cambios en los registros DNS tardan más en surtir efecto mientras persisten las cachés obsoletas
La expresión "propagación DNS" se usa comúnmente pero es técnicamente inexacta. Los cambios DNS no se "propagan" por internet. Lo que realmente ocurre es que la caché de cada resolver expira según el TTL, y el resolver obtiene el registro actualizado en la siguiente consulta. Reduciendo el TTL antes de hacer un cambio, puedes acelerar la velocidad con la que el nuevo registro se ve a nivel mundial.
Servidores raíz - La cúspide de internet
En la cima de la jerarquía DNS se encuentran 13 clústeres de servidores raíz, etiquetados de la A a la M. Un error común es pensar que solo hay 13 servidores físicos. En realidad, la tecnología Anycast distribuye más de 1.700 instancias por todo el mundo, garantizando acceso de baja latencia desde prácticamente cualquier lugar.
Los servidores raíz están coordinados por ICANN, y cada clúster es operado por una organización diferente. A y J son gestionados por Verisign, B por USC-ISI, K por RIPE NCC y M por el Proyecto WIDE (centrado en la Universidad de Keio en Japón), entre otros.
La información que almacenan los servidores raíz es sorprendentemente simple: registros de delegación para dominios de nivel superior. "Las consultas para .com van a este servidor autoritativo. Las consultas para .jp van a aquel otro." El archivo completo de la zona raíz ocupa aproximadamente 2 MB, un conjunto de datos notablemente pequeño para un sistema que sustenta toda la internet.
Tipos de registros DNS
DNS admite una variedad de tipos de registros, cada uno almacenando un tipo diferente de información.
| Registro | Propósito | Ejemplo |
|---|---|---|
| A | Dominio a dirección IPv4 | example.com → 93.184.216.34 |
| AAAA | Dominio a dirección IPv6 | example.com → 2606:2800:220:1:... |
| CNAME | Alias de dominio | www.example.com → example.com |
| MX | Designación de servidor de correo | example.com → mail.example.com (prioridad 10) |
| TXT | Datos de texto (SPF, DKIM, verificación de dominio) | "v=spf1 include:_spf.google.com ~all" |
| NS | Designación de servidor DNS autoritativo | example.com → ns1.example.com |
| SOA | Información de gestión de zona (número de serie, intervalo de actualización) | NS primario, correo del administrador, número de serie |
Los registros TXT fueron diseñados originalmente como un contenedor genérico para texto arbitrario, pero hoy se utilizan intensamente para la autenticación de correo electrónico (SPF, DKIM, DMARC) y la verificación de propiedad de dominios. Tanto Google Search Console como la emisión de certificados Let's Encrypt dependen de la verificación mediante registros TXT. El registro CNAME también merece atención: es el mecanismo detrás de por qué ya no es necesario escribir "www" en la mayoría de los sitios web, ya que crea un alias del subdominio www al dominio raíz.
Seguridad DNS y el camino por delante
DNS fue diseñado en 1983 sin consideraciones de seguridad. Las consultas y respuestas se envían en texto plano, lo que significa que tu ISP o cualquier persona en la misma red puede ver exactamente qué dominios estás resolviendo.
Han surgido dos tecnologías para abordar esto: DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT). DoH envuelve las consultas DNS dentro de HTTPS, haciéndolas indistinguibles del tráfico web normal. DoT cifra las consultas a través de un puerto dedicado (853) usando TLS.
DNSSEC (DNS Security Extensions) es otra tecnología crítica. Utiliza firmas digitales para verificar la autenticidad de las respuestas DNS, previniendo el envenenamiento de caché y los ataques de intermediario. Sin embargo, la adopción de DNSSEC sigue siendo baja: incluso entre los dominios .com, solo alrededor del 3% tiene DNSSEC habilitado. La fragilidad del DNS sigue siendo un desafío que impacta directamente en la seguridad de toda la internet. Para comprobar si tus consultas DNS se filtran a resolvers no deseados, puedes ejecutar una prueba de fuga DNS en IP確認さん.
Para quienes deseen construir una base sólida en DNS y redes, los libros sobre redes informáticas son un excelente punto de partida.