¿Qué es DNS? Guía visual para principiantes sobre cómo los nombres de dominio se convierten en direcciones IP

Cuando escribes google.com o toolcluster.app en el navegador, una página web aparece al instante desde un servidor en algún rincón del mundo. Si te detienes a pensarlo, acaban de pasar varias cosas misteriosas en cadena.

  • Escribes toolcluster.app y aparece un artículo desde un servidor en algún lugar del mundo. Pero ¿de dónde salió la dirección (la dirección IP)?
  • Conectas un móvil al Wi-Fi y Google y YouTube funcionan al instante. ¿Quién está convirtiendo el nombre de dominio en una dirección IP entre bastidores?

La mayoría usamos esto sin pensar en ello. Pero, si rastreas el camino, encontrarás una guía telefónica distribuida tendida sobre todo Internet, trabajando sin descanso entre bastidores.

Los dispositivos en Internet no pueden hablar entre sí sin una dirección IP (la dirección numérica en la red) ─ consulta nuestro artículo anterior ¿Qué es una dirección IP?. Pero en el día a día no escribimos números como 192.168.1.10; usamos nombres fáciles como toolcluster.app. Lo que une ambos mundos es DNS (el sistema de nombres de dominio).

En este artículo desentrañaremos:

  • Qué es realmente DNS y por qué es necesario (§1)
  • Por qué los nombres de dominio se leen de derecha a izquierda (§2)
  • Qué pasa entre bastidores en una sola consulta ─ el viaje de 7 fases (§3)
  • Qué son realmente los registros DNS (§4)
  • La caché DNS y el TTL que sostienen el 90 % de Internet en silencio (§5)
  • La era del DNS cifrado con DoH/DoT (§6)
  • Cómo se relacionan los CDN y Apple Private Relay con DNS (§7)
  • Algunos comandos que puedes ejecutar tú mismo para observar DNS en tu PC (§8)

Iremos paso a paso con diagramas, sin asumir conocimientos previos.

💡 Consejo

Este artículo es la cuarta entrega de nuestra serie «Cómo funciona realmente un PC». Si la instalación es el apretón de manos entre el sistema operativo y una app, el reinicio es el SO restableciendo el estado acumulado y la dirección IP es el «domicilio» en la red, este artículo trata sobre el sistema que convierte esas direcciones en nombres que un humano puede recordar.

1. Qué es DNS ─ la «guía telefónica» de Internet

1-1. El trabajo de unir nombres y direcciones

Una guía telefónica es un libro para buscar el número de teléfono de una persona a partir de su nombre. En Internet, las piezas equivalentes son:

  • Nombre de dominio ─ el texto fácil de recordar, como el nombre de la persona (toolcluster.app)
  • Dirección IP ─ el número que las máquinas usan para comunicarse, como el número de teléfono (203.0.113.5)

La «guía telefónica» que une ambos es DNS (sistema de nombres de dominio ─ el sistema usado por todo Internet para convertir «nombres → direcciones»).

1-2. Por qué es necesario DNS

Si lo único que importara fuera la conectividad pura, bastaría con escribir direcciones IP. Pero DNS existe por tres razones:

  • Difíciles de recordar: toolcluster.app es muchísimo más fácil de retener que 203.0.113.5
  • Cambian con frecuencia: las IP cambian al migrar servidores o cambiar de proveedor cloud. Si los usuarios solo necesitan recordar el nombre, la dirección de fondo puede cambiar sin que se enteren
  • Reparto entre muchos servidores: vincular un nombre a varias IP y enviar a los usuarios a distintos servidores del mundo (esto es lo que hacen los CDN, lo veremos más adelante)

1-3. DNS no es una sola base de datos gigante

Este es el malentendido más habitual. La gente imagina «un cuartel general DNS en algún lugar del mundo que gestiona todos los dominios». En realidad, DNS es un sistema distribuido y jerárquico repartido por todo Internet.

tu navegador
        ↕
    Resolutor DNS (un "intermediario" que se encarga de la resolución de nombres por ti)
        ↕
   Flota de servidores DNS, repartidos por todo el mundo
        ├── Servidores raíz (".")
        ├── Servidores TLD (".app", ".com", etc.)
        └── Servidores de nombres autoritativos (operados por cada propietario de dominio)

Por ejemplo, los únicos servidores que realmente conocen la dirección de toolcluster.app son los servidores de nombres autoritativos de toolcluster.app, situados en algún rincón del mundo. Cualquier otro servidor solo puede decir «yo no, pregunta allí». DNS consiste, en esencia, en repartir el trabajo y pasar la pregunta hasta encontrar la respuesta.

2. La jerarquía de los nombres de dominio ─ se leen de derecha a izquierda

2-1. Como una dirección postal, la parte derecha es la «más amplia»

Un nombre de dominio como www.toolcluster.app funciona igual que una dirección postal: cuanto más a la derecha, más amplio el alcance.

www . toolcluster . app .
└─┬─┘  └────┬─────┘ └┬┘ └← el "." final suele omitirse, pero representa la raíz
  sub-      segundo   TLD
  dominio   nivel

Igual que una dirección postal en español va desde lo más concreto («número → calle → ciudad → provincia → país») con la unidad más grande al final. El punto final tantas veces omitido (.) representa la mayor unidad de todas: la raíz.

2-2. Cuatro niveles, cada uno con su «responsable»

La jerarquía DNS tiene cuatro niveles:

  • Raíz (.): lo más alto de Internet. Operada como 13 grupos de servidores en todo el mundo
  • TLD (Top Level Domain): .com, .app, .jp, etc. Operados por Verisign, Google y otros
  • Dominio de segundo nivel: la parte toolcluster de toolcluster.app. La responsabilidad recae en quien compra el dominio
  • Subdominio: la parte www de www.toolcluster.app. El propietario puede partirlo libremente

Cada nivel tiene su propio responsable (el servidor de nombres autoritativo ─ el servidor que «realmente conoce» la IP de los dominios bajo su responsabilidad). El viaje de la consulta funciona descendiendo desde el nivel más alto y siguiendo la cadena de responsabilidad hasta llegar a la respuesta.

.                            ← raíz (".")
├── com                      ← TLD
├── app                      ← TLD ★ a partir de aquí preguntamos al equipo de ".app"
│    └── toolcluster         ← segundo nivel ★ aquí vive el NS autoritativo
│         └── www            ← subdominio
├── jp
└── ...

3. ★ El viaje de la resolución de nombres ─ 7 fases

Aquí está el corazón del artículo. Desde el momento en que escribes toolcluster.app hasta que tu navegador tiene la dirección IP en mano, ¿qué está pasando realmente? Lo seguimos en 7 fases.

3-1. Cronología de las 7 fases

Cada fase tarda de unos pocos a unos pocos cientos de milisegundos. Si en cualquier punto entre 1 y 6 hay un acierto de caché, todas las fases siguientes se omiten (más en §5).

  1. 1Comprobar la caché del navegador¿Se ha resuelto este dominio muy recientemente? El navegador mira primero su tabla interna.
  2. 2Preguntar al stub resolver del SOSi el navegador no lo tiene, se pregunta al pequeño cliente DNS integrado en el SO (el stub resolver). El SO también tiene su propia caché.
  3. 3Enviar al resolutor DNSSi el SO tampoco lo tiene, la pregunta se envía a un resolutor DNS externo (el de tu ISP, 8.8.8.8, 1.1.1.1, etc.).
  4. 4Preguntar a un servidor raízEl resolutor pregunta a la raíz: «¿quién se encarga de .app?»
  5. 5Preguntar al servidor TLDEl resolutor pregunta al servidor TLD .app (que la raíz le ha indicado): «¿quién se encarga de toolcluster.app?»
  6. 6Preguntar al servidor de nombres autoritativoPor último, el resolutor pregunta al NS autoritativo de toolcluster.app: «¿cuál es la IP de www.toolcluster.app?»
  7. 7La respuesta vuelve al navegadorLa respuesta hace el camino de vuelta resolutor → SO → navegador, y se cachea en cada capa por la que pasa.

Truco para recordarlo: «Navegador → SO → Resolutor → Raíz → TLD → Autoritativo → Vuelta». Desde que pulsas Enter hasta que llega la respuesta, cada consulta pasa por estas 7 paradas (la mayoría se cortocircuitan por la caché, pero la ruta completa es esta).

3-2. Iterativa vs recursiva ─ «¿quién es el que va dando vueltas?»

Si observas con atención esas 7 fases, te darás cuenta de que en realidad hay dos estilos distintos de consulta.

  • Consulta recursiva: tú (el navegador/SO) le pides al resolutor DNS «devuélveme solo la respuesta final». El resolutor hace por ti los pasos 4–6
  • Consulta iterativa: el resolutor DNS le pregunta a cada servidor «dime solo a quién debería preguntar a continuación». El resolutor va saltando de servidor en servidor, recogiendo la respuesta paso a paso
TramoTipo de consultaSignificado
Cliente ↔ ResolutorRecursiva«Dame la IP final»
Resolutor ↔ Raíz / TLD / AutoritativoIterativa«¿A quién pregunto ahora?»

Es decir, el único que va dando vueltas es el resolutor. Tú solo tienes que decir «resolutor, encárgate tú». Este diseño es lo que hace que Internet se sienta tan rápido como se siente.

4. Tipos de registros DNS

DNS no solo devuelve «nombre → IP». Un dominio tiene asociado todo tipo de información en forma de registros, cada uno con su propio tipo. Estos son los 8 más importantes.

RegistroEn una líneaEjemplo
Adominio → IPv4toolcluster.app A 203.0.113.5
AAAAdominio → IPv6toolcluster.app AAAA 2001:db8::1
CNAMEalias de otro dominiowww.toolcluster.app CNAME toolcluster.app
MXa dónde llega el correotoolcluster.app MX 10 mail.example.com
TXTtexto libre (SPF / DKIM, etc.)toolcluster.app TXT "v=spf1 -all"
NSquién es autoritativo para esta zonatoolcluster.app NS ns1.cloudflare.com
PTRIP → dominio (resolución inversa)5.113.0.203.in-addr.arpa PTR toolcluster.app
SOAmetadatos de la zona(TTL, email del administrador, etc.)

A y AAAA son la pareja IPv4/IPv6, y los sitios modernos suelen configurar ambos. CNAME significa «alias», así que al definir www.toolcluster.app como alias de toolcluster.app, basta con actualizar una IP y los dos nombres se actualizan a la vez.

MX, TXT y NS aparecen cuando servicios distintos de la Web se enganchan a un dominio. Si quieres correo, configuras MX; para autenticación de dominio y prevención de suplantación, pones SPF/DKIM/DMARC dentro de registros TXT ─ ese es el manual estándar.

5. Caché DNS y TTL ─ el héroe silencioso de Internet

Si recorriéramos las 7 fases del §3 en cada conexión, los servidores raíz se hundirían bajo cientos de millones de consultas por segundo. En la práctica, la caché lo absorbe casi todo y la mayoría de las búsquedas terminan en la fase 1, 2 o 3.

5-1. La caché tiene muchas capas

caché interna del navegador
        ↓ si falla
caché del stub resolver del SO
        ↓ si falla
caché del resolutor DNS (ISP / 8.8.8.8 / 1.1.1.1)
        ↓ si falla
el viaje real: raíz → TLD → autoritativo

Cuantas más capas hay, menos carga sube por arriba (raíz y TLD).

5-2. TTL ─ cuándo tirar la caché

Cada registro lleva asociado un TTL (Time To Live ─ el número máximo de segundos durante los que se puede cachear el registro). Si TTL = 300, la caché puede reutilizarse durante 5 minutos; pasados esos minutos, hay que descartarla y volver a consultar.

  • Configurar el TTL más largo → menos carga arriba, pero los cambios de IP tardan más en propagarse
  • Configurar el TTL más corto → los cambios se propagan rápido, pero hay más consultas hacia arriba

El manual clásico antes de migrar un servidor es «bajar el TTL a 60 segundos primero, y luego migrar» ─ es justamente esta propiedad en acción.

5-3. La «propagación de DNS» en realidad no es propagación

En las migraciones de sitios oirás muchas veces la frase «esperando a que DNS se propague». Suele entenderse mal: en realidad solo significa «esperando a que las cachés del mundo expiren». El nuevo registro no se está difundiendo literalmente por todo el planeta.

  • ✗ Idea equivocada habitual: la nueva IP se propaga a todos los servidores DNS del mundo
  • ✓ Realidad: cada resolutor vuelve a consultar al NS autoritativo en cuanto el TTL de su caché vieja expira

Por eso, bajar el TTL con antelación acelera la «propagación». Una vez que entiendes el mecanismo es obvio; sin entenderlo, esta fase parece quedarse esperando a que pase la suerte.

💡 Consejo

A veces «borrar la caché del navegador no lo arregla, pero otro PC lo ve bien». Casi siempre es porque tu resolutor DNS (el del ISP o el del router) sigue con la caché vieja. Las cachés que sobreviven incluso a ipconfig /flushdns en Windows suelen resolverse reiniciando el router o cambiando a otro servicio DNS.

6. DoH / DoT ─ la era del DNS cifrado

Hasta ahora hemos asumido en silencio que «las consultas DNS viajan por la red en texto claro». Y durante mucho tiempo así fue. Pero en los años 2020 la marea está cambiando.

6-1. El problema del DNS en texto claro

En texto claro, tus consultas DNS son visibles para cualquiera en la misma red.

  • El operador del Wi-Fi público puede ver claramente «qué intentas visitar» (los nombres de dominio)
  • El ISP puede construir un historial de navegación a nivel de dominio
  • Un atacante intermedio podría falsificar registros y redirigirte a un sitio falso (DNS spoofing)

6-2. Llegan DoH y DoT

La respuesta es DoH (DNS over HTTPS) y DoT (DNS over TLS). Ambas cifran la consulta DNS.

ProtocoloFormato en la redVisibilidad en la red
TradicionalUDP/53 (texto claro)las consultas son totalmente visibles
DoTTLS/853 (puerto dedicado)cifrado, pero «esto es DNS» sigue siendo visible
DoHHTTPS/443 (igual que la Web)se mezcla con el tráfico web normal

6-3. Cómo se usa hoy

Los principales navegadores (Firefox / Chrome / Safari) usan DoH automáticamente bajo ciertas condiciones. En el lado corporativo, esto introduce un nuevo reto: «¿cómo gobernamos DoH?» ─ porque los filtros parentales y los sistemas de detección de intrusiones miraban el DNS.

Este tema merece un artículo propio, así que por ahora quédate con la idea general: «el DNS se está cifrando, y eso tiene consecuencias».

7. CDN y DNS ─ la astuta «mentira» del «servidor más cercano»

Para terminar, dos aplicaciones reales de DNS que sostienen el rendimiento de la Web moderna.

7-1. Los CDN devuelven «el más cercano» con GeoDNS

Si resuelves google.com desde distintos países, recibirás IP diferentes según dónde estés. El servidor de nombres autoritativo mira la ubicación de origen y la ruta de red de la consulta y devuelve la IP del servidor más cercano. A esto se le llama GeoDNS (operar el DNS para que devuelva respuestas geográficamente óptimas). CDN (redes de distribución de contenido) como Cloudflare y Akamai operan esto a gran escala.

un usuario en Tokio → IP del servidor edge de Tokio
un usuario en Nueva York → IP del servidor edge de Nueva York

Mismo dominio, respuestas distintas ─ así es como DNS va hoy mucho más allá de una «simple guía telefónica».

7-2. Apple Private Relay también pivota sobre DNS

En iOS / macOS, Apple Private Relay es un servicio que reparte tus consultas DNS y tu tráfico web entre dos relays para que ninguna parte por sí sola pueda correlacionarlos. El punto de partida de «ni siquiera Apple ve lo que navegas» es justamente el cifrado y la separación del DNS.

Así, DNS va más allá de la simple resolución de nombres y se convierte en una bisagra tanto para la privacidad como para la optimización de la entrega.

8. Observa DNS en tu propio PC

Una vez seguida la teoría, vale la pena tocarlo con las manos. Un uso más profundo merece su propio artículo, así que aquí solo mostramos los dos comandos mínimos que necesitas.

8-1. dig (Linux / macOS)

dig-example
dig toolcluster.app

De toda la salida, lo que te interesa es lo que hay debajo de ;; ANSWER SECTION:.

;; ANSWER SECTION:
toolcluster.app.    300    IN    A    203.0.113.5

300 es el TTL, A es el tipo de registro y 203.0.113.5 es la IP. En cuanto sepas leer esos tres números, los conocimientos de §4 y §5 se convierten en memoria muscular.

8-2. nslookup (Windows / multiplataforma)

nslookup-example
nslookup toolcluster.app

La línea Server: muestra «el resolutor DNS que estás usando ahora mismo»; la línea Address: muestra «la IP del dominio».

8-3. Vaciar la caché

  • Windows: ipconfig /flushdns
  • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • Linux (systemd): sudo systemd-resolve --flush-caches

dig da para mucho más, pero eso es para otro artículo. Para este, con «escribir una línea y aprender a leer la respuesta» es suficiente.

Resumen ─ la esencia en 4 líneas

Ha sido un artículo largo, pero la esencia cabe en 4 puntos.

  • DNS = el conversor de nombres a direcciones. Funciona sobre una red de servidores repartidos por el mundo
  • Los nombres de dominio son jerárquicos y se leen de derecha a izquierda, y cada nivel tiene un responsable (el servidor de nombres autoritativo)
  • La caché y el TTL sostienen aproximadamente el 90 % de Internet. La «propagación de DNS» no es propagación; es esperar a que los TTL caduquen
  • Conocer DoH/DoT y CDN es lo que te permite entender cómo se comporta Internet hoy

Con este esqueleto en mente, planificar la migración de un sitio, aislar latencias raras y leer noticias relacionadas con DNS pasan a ser tareas del mismo tipo.

Para la dirección de red en sí, consulta ¿Qué es una dirección IP?; para el puente entre el SO y el software, ¿Por qué el software no funciona sin instalación?; y para resetear el estado acumulado por el SO, ¿Por qué un reinicio arregla las cosas?. Leídos en conjunto, las «cañerías invisibles» del PC y de Internet empiezan a conectarse en una imagen tridimensional y única.

FAQ

Q1. ¿Qué puedo hacer cuando el DNS me parece lento?

A. Los dos primeros sospechosos son la caché y la elección del resolutor. Si vaciar la caché local (ipconfig /flushdns en Windows, los equivalentes en otros sistemas) no ayuda, cambiar el resolutor DNS a uno público como 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) o 9.9.9.9 (Quad9) suele acelerarlo. También puedes cambiarlo desde el router de casa. Ojo: los sitios con un TTL largo pueden parecer «igual de lentos para todos» por motivos del servidor, así que conviene comprobar si otras personas notan la misma lentitud.

Q2. ¿Qué es el archivo hosts? ¿Cómo se relaciona con DNS?

A. El archivo hosts es una libreta de direcciones local que el SO consulta antes que DNS. En Mac/Linux vive en /etc/hosts; en Windows, en C:\Windows\System32\drivers\etc\hosts. Si añades una línea como 127.0.0.1 myapp.local, el tráfico hacia myapp.local va a tu propia máquina sin tocar DNS. Se usa habitualmente al desarrollar o para bloquear sitios concretos. Como va por delante de DNS, una edición errónea puede dejarte preguntándote «¿por qué no llego a este sitio?».

Q3. ¿Qué pasa entre comprar un dominio y verlo en la Web?

A. Hay aproximadamente 3 pasos. (1) Compras el dominio en un registrador (Namecheap, Cloudflare Registrar, etc.); la base de datos del TLD se actualiza con tu registro. (2) Indicas los servidores de nombres autoritativos (NS) en el panel del registrador ─ o usas los tuyos propios o usas un DNS gestionado como Cloudflare DNS o Route 53. (3) En esos NS autoritativos configuras registros A o CNAME apuntando a la IP de tu servidor. A partir de ahí, los resolutores de todo el mundo recogerán el nuevo registro a medida que sus TTL expiren.

Q4. 8.8.8.8 vs 1.1.1.1 ─ ¿cuál debería usar?

A. Ambos son resolutores DNS públicos, gratuitos y estables. La velocidad suele estar empatada al margen de diferencias regionales, así que la elección depende de la política y las funciones extra. 8.8.8.8 (Google) aporta infraestructura masiva y un largo historial; 1.1.1.1 (Cloudflare) se apoya en compromisos de privacidad como «logs eliminados en menos de 24 horas». Si quieres filtrado (bloquear contenido para adultos, etc.), 1.1.1.3 (Cloudflare for Families) y 9.9.9.9 (Quad9, bloquea dominios maliciosos) son opciones. Para uso personal o doméstico, 1.1.1.1 es una opción segura por defecto; para uso empresarial donde quieras SLA y soporte, apoyarte en el DNS de tu ISP o en un servicio de pago resulta más práctico.

Q5. ¿Activar DoH rompe la seguridad corporativa?

A. Medio cierto; medio ya resuelto. La seguridad corporativa antigua se basaba en «mirar el DNS para bloquear dominios sospechosos», y DoH oculta el DNS dentro de HTTPS, lo que debilita ese enfoque. Pero los entornos empresariales modernos lo compensan con agentes de endpoint en el PC o forzando DoH a través de un resolutor interno. Para uso personal no hay grandes riesgos, pero en un PC de empresa, no actives DoH por tu cuenta ─ es probable que choque con la política corporativa.

Comments

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *