DNS: cómo tu navegador traduce un dominio en una dirección IP

⏱️ Lectura: 12 min

Cada vez que escribís una URL en el navegador, tenés menos de un segundo para que ese texto se convierta en una dirección IP antes de que arranque la conexión real. Ese proceso se llama resolución DNS y ocurre en segundo plano, sin que lo notes, miles de veces al día.

📑 En este artículo

1. TL;DR
2. Qué es la resolución DNS y por qué importa
3. Cómo funciona: el recorrido de una consulta DNS
   1. Por qué los servidores raíz no colapsan: anycast
4. Tipos de registros DNS
5. Ejemplos prácticos: inspeccionar una resolución DNS real
6. Cómo empezar: configurar tus propios registros DNS
7. Casos de uso reales
8. Caché y TTL: por qué un cambio tarda en propagarse
9. DNSSEC: profundizando
10. Comparativa: resolvers públicos
11. Errores comunes y buenas prácticas
12. Preguntas frecuentes
    1. ¿Qué diferencia hay entre un resolver recursivo y un servidor autoritativo?
    2. ¿Por qué a veces un cambio de DNS tarda horas en verse?
    3. ¿Es lo mismo DNS que DHCP?
    4. ¿DNSSEC reemplaza a HTTPS?
    5. ¿Qué es DNS sobre HTTPS (DoH)?
13. Referencias

Detrás de esa traducción hay una cadena de hasta cuatro servidores distintos, un sistema de caché con expiración programada y un protocolo que sigue las reglas que definió la RFC 1035 en 1987.

TL;DR

• Vas a entender los servidores que participan en cada consulta DNS: recursivo, raíz, TLD y autoritativo.
• Vas a saber diferenciar registros A, AAAA, CNAME, MX y TXT y cuándo usar cada uno.
• Vas a poder inspeccionar una resolución real con dig y leer la respuesta paso a paso.
• Vas a entender cómo funciona el caché DNS y por qué el TTL afecta cuánto tarda un cambio en propagarse.
• Vas a saber qué agrega DNSSEC y qué ataque concreto resuelve.
• Vas a poder configurar tus propios registros en un archivo de zona o en un panel de proveedor.
• Vas a saber diagnosticar NXDOMAIN, TTL vencido y subdomain takeover.

Qué es la resolución DNS y por qué importa

El Sistema de Nombres de Dominio (DNS) es la capa que traduce nombres legibles como programacion.example en direcciones IP como 192.0.2.10 o 2001:db8::1. Sin esa traducción, tendrías que memorizar una dirección numérica para cada sitio que visitás.

La resolución DNS no es un solo servidor respondiendo: es una cadena jerárquica de consultas. Esa jerarquía es lo que permite que millones de dominios coexistan sin que un único servidor central se sature ni se vuelva un punto único de falla.

Pensalo como la agenda de contactos de tu teléfono: vos guardás “Mamá” y el teléfono sabe que eso significa un número de diez dígitos. El DNS hace lo mismo a escala de internet, con la diferencia de que esa agenda es distribuida entre millones de servidores en vez de vivir en un solo dispositivo.

El protocolo nació en 1983, diseñado por Paul Mockapetris para reemplazar un archivo de texto único (HOSTS.TXT) que Stanford mantenía a mano y que ya no escalaba con el crecimiento de ARPANET, según recoge la entrada de Wikipedia sobre el sistema.

Cómo funciona: el recorrido de una consulta DNS

Cuando escribís programacion.example en la barra de direcciones, el navegador primero revisa su propio caché. Si no encuentra una respuesta vigente, delega la consulta al resolver recursivo configurado en tu sistema operativo o tu router, normalmente el de tu proveedor de internet o uno público como 1.1.1.1 o 8.8.8.8.

El resolver recursivo hace el trabajo pesado: primero le pregunta a uno de los servidores raíz, identificados históricamente con 13 letras, de la A a la M, aunque cada letra corresponde hoy a cientos de instancias físicas distribuidas con anycast. El servidor raíz no conoce la IP final, pero indica a qué servidor de la zona TLD (.com, .org, .example) preguntar.

El servidor TLD tampoco tiene la respuesta final: apunta al servidor autoritativo del dominio, que sí guarda el registro real. Recién ahí el resolver recursivo obtiene la IP, se la entrega al navegador y guarda una copia en caché durante el tiempo que indique el TTL (Time To Live) del registro.

Por qué los servidores raíz no colapsan: anycast

Trece letras no significan trece máquinas físicas. Cada servidor raíz usa anycast: la misma dirección IP se anuncia desde decenas de ubicaciones distintas alrededor del mundo, y el tráfico de red enruta automáticamente hacia la instancia más cercana. Así, aunque millones de resolvers consulten a la vez, ninguna ubicación concentra toda la carga.

sequenceDiagram
participant N as "Navegador"
participant R as "Resolver recursivo"
participant Raiz as "Servidor raiz"
participant TLD as "Servidor TLD"
participant A as "Servidor autoritativo"
N->>R: "resuelve programacion.example"
R->>Raiz: "responsable de .example"
Raiz-->>R: "redirige al servidor TLD"
R->>TLD: "responsable de programacion.example"
TLD-->>R: "redirige al autoritativo"
R->>A: "direccion IP de programacion.example"
A-->>R: "192.0.2.10"
R-->>N: "192.0.2.10, guardado en cache"

Tipos de registros DNS

Un dominio no guarda un solo dato: guarda una zona completa con distintos tipos de registros, cada uno con un propósito específico.

Registro	Qué resuelve	Cuándo usarlo
A	Dominio a dirección IPv4	Apuntar un dominio a un servidor con IPv4
AAAA	Dominio a dirección IPv6	Igual que A pero para redes IPv6, definido en RFC 3596
CNAME	Alias hacia otro dominio	Subdominios que apuntan a un servicio externo (CDN, hosting)
MX	Servidor de correo	Definir a dónde se entrega el email del dominio
TXT	Texto libre	Verificación de propiedad, SPF, DKIM
NS	Servidores autoritativos de la zona	Delegar la zona a un proveedor DNS específico

Ejemplos prácticos: inspeccionar una resolución DNS real

La forma más directa de ver la resolución DNS en acción es con dig, disponible en Linux y macOS (en Windows equivale a nslookup).

dig programacion.example A +short

Esa consulta devuelve solo la dirección IPv4 asociada al dominio, sin el resto de la metadata. Es el equivalente a preguntarle directamente al resolver: dame la IP y nada más.

Para ver el recorrido completo, con cada servidor intermedio, se usa el flag +trace:

dig +trace programacion.example

; <<>> DiG <<>> +trace programacion.example
;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
example.                172800  IN      NS      a.iana-servers.net.
programacion.example.   3600    IN      A       192.0.2.10

Cada línea representa una respuesta de un nivel distinto de la jerarquía: primero la raíz, después el TLD y por último el servidor autoritativo del dominio.

Si preferís resolver DNS desde código, Node.js expone el módulo nativo dns:

const dns = require('node:dns').promises;

async function resolverDominio(dominio) {
  const direcciones = await dns.resolve4(dominio);
  console.log(`${dominio} resuelve a:`, direcciones);
}

resolverDominio('programacion.example');

Este código usa el resolver del sistema operativo para obtener las direcciones IPv4 del dominio y las imprime en consola. Si el dominio no existe, la promesa rechaza con un error ENOTFOUND.

Cómo empezar: configurar tus propios registros DNS

Si administrás un dominio, configurar sus registros no requiere levantar un servidor propio: se hace desde el panel del proveedor DNS (Cloudflare, Route 53, el registrador del dominio) o editando un archivo de zona si administrás tu propio servidor autoritativo con software como BIND.

Un archivo de zona mínimo en formato BIND se ve así:

$TTL 3600
@   IN  SOA ns1.programacion.example. admin.programacion.example. (
        2026082001 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        3600 )     ; minimum TTL

@       IN  NS      ns1.programacion.example.
@       IN  A       192.0.2.10
www     IN  CNAME   programacion.example.
@       IN  MX  10  mail.programacion.example.

Ese archivo define quién es el servidor autoritativo (NS), la IP principal (A), un alias para www (CNAME) y el servidor de correo (MX). El SOA (Start of Authority) marca los tiempos de refresco entre servidores secundarios.

Los pasos generales, sin importar el proveedor, son los mismos: crear el registro con el tipo correcto, apuntar al valor (IP o dominio destino), definir el TTL y esperar a que se propague.

💡 Tip: antes de migrar un dominio a un nuevo proveedor, bajá el TTL de los registros existentes a 300 segundos un día antes. Así, si algo sale mal, el rollback se propaga en minutos y no en horas.

Casos de uso reales

Más allá de traducir un nombre a una IP, el DNS se usa como pieza de infraestructura en varios escenarios que probablemente ya usaste sin notarlo.

• Balanceo de carga con DNS round robin, un mismo dominio puede tener varios registros A distintos; el resolver devuelve las IPs en distinto orden en cada consulta, repartiendo tráfico entre servidores sin un balanceador dedicado.
• GeoDNS para CDNs, servicios como Cloudflare o Akamai responden con una IP distinta según la ubicación geográfica de quien consulta, para que el usuario se conecte al servidor más cercano.
• Failover automático, algunos proveedores DNS monitorean la salud del servidor detrás de cada registro y, si detectan una caída, dejan de devolver esa IP hasta que vuelva a responder.
• Subdomain takeover, un CNAME que apunta a un servicio externo dado de baja queda colgando; un atacante puede reclamar ese mismo nombre en el servicio externo y tomar control del subdominio.

Caché y TTL: por qué un cambio tarda en propagarse

Cada registro DNS lleva un TTL en segundos que le dice a cualquier resolver cuánto tiempo puede reusar esa respuesta sin volver a preguntar. Un TTL de 3600 significa que, durante una hora, cualquier resolver que ya haya consultado ese registro va a servir la respuesta guardada, aunque el registro haya cambiado en el servidor autoritativo.

Esto explica por qué cambiar el DNS nunca es instantáneo: no hay un único caché que limpiar, sino miles de resolvers recursivos alrededor del mundo, cada uno con su propio reloj de expiración.

flowchart TD
A["Resolver recibe la consulta"] --> B{"Tiene el registro en cache vigente"}
B -->|"Si, TTL vigente"| C["Responde desde cache"]
B -->|"No o TTL vencido"| D["Consulta al servidor autoritativo"]
D --> E["Guarda la respuesta y el nuevo TTL"]
E --> C

DNSSEC: profundizando

El diseño original de DNS no verifica que una respuesta venga realmente del servidor autoritativo: un atacante en la misma red puede inyectar una respuesta falsa antes de que llegue la real, un ataque conocido como DNS cache poisoning.

DNSSEC (DNS Security Extensions) resuelve esto firmando criptográficamente cada respuesta con un registro RRSIG, verificable contra la clave pública publicada en el registro DNSKEY de la zona padre. La cadena de firmas sube hasta la zona raíz, que actúa como ancla de confianza.

Podés verificar si un dominio tiene DNSSEC activo con:

dig programacion.example DNSKEY +short

Si el comando devuelve una o más claves, la zona firma sus registros. Si vuelve vacío, el dominio no implementa DNSSEC y su resolución es vulnerable a manipulación en tránsito, aunque siga funcionando igual para el usuario final.

⚠️ Ojo: DNSSEC protege la integridad de la respuesta, no la confidencialidad de la consulta. Alguien que observe el tráfico sigue viendo qué dominios resolvés, a menos que además uses DNS sobre HTTPS o DNS sobre TLS.

Comparativa: resolvers públicos

Resolver	IP	Ventaja	Limitación
Cloudflare	1.1.1.1	Enfoque declarado en privacidad, borra logs en 24 horas	No filtra contenido por defecto
Google Public DNS	8.8.8.8	Alta disponibilidad global	Registra telemetría más extensa
Resolver del ISP	Variable	Menor latencia si está cerca de tu red	Algunos inyectan anuncios en errores NXDOMAIN

Errores comunes y buenas prácticas

• NXDOMAIN, el dominio consultado no existe en ningún registro. Antes de asumir que el DNS está mal configurado, verificá que el dominio esté escrito correctamente y que la zona exista.
• TTL demasiado alto en producción, un TTL de 86400 (un día) en un registro que cambia seguido convierte cualquier migración en una espera larga. Bajalo antes de un cambio planeado.
• Olvidar el registro AAAA, si tu servidor tiene IPv6 pero solo publicás el registro A, estás dejando fuera a redes que priorizan IPv6, cada vez más comunes.
• CNAME en la raíz del dominio, el estándar no permite un CNAME conviviendo con otros registros en el apex (programacion.example sin subdominio); para eso existen alternativas como el registro ALIAS o ANAME de algunos proveedores.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: corré dig +trace tudominio.com en una terminal y seguí manualmente cada salto hasta encontrar el servidor autoritativo real de tu propio dominio.

Preguntas frecuentes

¿Qué diferencia hay entre un resolver recursivo y un servidor autoritativo?

El resolver recursivo hace las preguntas en nombre del cliente y no guarda los registros originales, solo una copia en caché. El servidor autoritativo es la fuente real: ahí vive el registro que administra el dueño del dominio.

¿Por qué a veces un cambio de DNS tarda horas en verse?

Porque distintos resolvers alrededor del mundo guardaron el registro anterior con TTLs distintos. Hasta que cada copia en caché expire, esos resolvers van a seguir devolviendo el valor viejo.

¿Es lo mismo DNS que DHCP?

No. DHCP asigna una dirección IP a un dispositivo dentro de una red local. DNS traduce nombres de dominio a direcciones IP en internet. Son protocolos distintos que suelen coexistir en la misma infraestructura.

¿DNSSEC reemplaza a HTTPS?

No. DNSSEC verifica que la respuesta DNS no fue alterada en tránsito. HTTPS cifra y verifica la conexión con el servidor una vez que ya tenés la IP. Son capas de seguridad complementarias, no sustitutas.

¿Qué es DNS sobre HTTPS (DoH)?

Un mecanismo que envía las consultas DNS cifradas dentro de una conexión HTTPS normal, para que un observador de la red no pueda ver en texto plano qué dominios estás resolviendo.

Referencias

• RFC 1035: especificación original del protocolo DNS, publicada por la IETF.
• IANA, servidores raíz: listado oficial de las 13 letras de servidores raíz y sus operadores.
• MDN Web Docs, glosario DNS: explicación de referencia orientada a desarrolladores web.
• Cloudflare Learning Center, qué es DNS: guía introductoria con diagramas del recorrido de una consulta.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Tyler en Unsplash