SincroDev DNS a Fondo: El Sistema de Nombres de Internet
Escribes google.com en tu navegador y mágicamente llegas al servidor correcto. Pero las computadoras no entienden nombres; necesitan direcciones IP como 142.250.185.46. El DNS (Domain Name System) es el traductor universal que hace posible la web tal como la conocemos.
Sin DNS, tendrías que memorizar direcciones IP para cada sitio. Imagina tener una agenda telefónica con millones de números que cambian constantemente. DNS resuelve este problema con un sistema distribuido, jerárquico y sorprendentemente elegante.
¿Por qué no simplemente un archivo gigante?
En los inicios de Internet (ARPANET), existía un archivo llamado HOSTS.TXT mantenido por el Stanford Research Institute:
# HOSTS.TXT - ¡Toda Internet en un archivo!
10.0.0.1 mit-ai
10.0.0.2 sri-nic
10.0.0.3 ucsb-mod
...Cada máquina descargaba este archivo periódicamente. Funcionó mientras había decenas de hosts. Pero cuando Internet creció, el sistema colapsó:
- Escalabilidad: El archivo crecía sin control
- Consistencia: Actualizaciones tardaban en propagarse
- Colisiones: ¿Quién decide si “mail” es tuyo o mío?
En 1983, Paul Mockapetris diseñó DNS para resolver estos problemas.
La jerarquía DNS
DNS organiza los nombres en un árbol invertido:
. (raíz)
│
┌───────────────┼───────────────┐
│ │ │
com org net ← TLDs (Top Level Domains)
│ │ │
┌───┴───┐ ┌───┴───┐ │
google amazon wikipedia gnu cloudflare
│ │ │ │ │
www aws www ftp www
mail s3 │ │
dns │ es apiCada nivel está administrado por diferentes entidades:
| Nivel | Quién lo administra | Ejemplo |
|---|---|---|
| Raíz (.) | ICANN / Root Server Operators | . |
| TLD | Registros (Verisign, PIR, etc.) | .com, .org, .es |
| Segundo nivel | Tú (compras el dominio) | tuempresa.com |
| Subdominios | Tú (configuras tu DNS) | mail.tuempresa.com |
Anatomía de una consulta DNS
Cuando tu navegador necesita resolver www.ejemplo.com:
Tu PC Internet
│
│ 1. "¿IP de www.ejemplo.com?"
│─────────────────────────────────► Resolver DNS (ISP/8.8.8.8)
│ │
│ │ 2. ¿Está en caché?
│ │ NO → consultar
│ │
│ │ 3. "¿Quién maneja .com?"
│ │────────────────► Root Server
│ │◄──── "Pregunta a a.gtld-servers.net"
│ │
│ │ 4. "¿Quién maneja ejemplo.com?"
│ │────────────────► TLD Server (.com)
│ │◄──── "Pregunta a ns1.ejemplo.com"
│ │
│ │ 5. "¿IP de www.ejemplo.com?"
│ │────────────────► NS de ejemplo.com
│ │◄──── "93.184.216.34"
│ │
│◄────────────────────────────────────────┤ 6. "Es 93.184.216.34"
│ │ (guarda en caché)
│
│ 7. Conectar a 93.184.216.34
│─────────────────────────────────────────────────────────► Servidor WebEste proceso se llama resolución recursiva y típicamente toma 20-120ms la primera vez. Las consultas posteriores usan caché y responden en <1ms.
Los 13 Root Servers
En la cima de la jerarquía están los servidores raíz, nombrados de la A a la M:
┌─────────────────────────────────────────────────────┐
│ Los 13 Root Servers │
├──────┬──────────────────────┬───────────────────────┤
│ Letra│ Operador │ Ubicación principal │
├──────┼──────────────────────┼───────────────────────┤
│ A │ Verisign │ Virginia, USA │
│ B │ USC-ISI │ California, USA │
│ C │ Cogent │ Virginia, USA │
│ D │ U. Maryland │ Maryland, USA │
│ E │ NASA │ California, USA │
│ F │ ISC │ California, USA │
│ G │ US DoD │ Ohio, USA │
│ H │ US Army │ Maryland, USA │
│ I │ Netnod │ Estocolmo, Suecia │
│ J │ Verisign │ Virginia, USA │
│ K │ RIPE NCC │ Amsterdam, Holanda │
│ L │ ICANN │ California, USA │
│ M │ WIDE Project │ Tokio, Japón │
└──────┴──────────────────────┴───────────────────────┘¿Solo 13 servidores para todo Internet? En realidad, cada “servidor raíz” es un cluster de cientos de máquinas distribuidas globalmente usando Anycast. Hay más de 1500 instancias físicas.
Tipos de registros DNS
DNS no solo mapea nombres a IPs. Almacena diferentes tipos de información:
Registros fundamentales
# A - Dirección IPv4
ejemplo.com. IN A 93.184.216.34
# AAAA - Dirección IPv6
ejemplo.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946
# CNAME - Alias (canonical name)
www.ejemplo.com. IN CNAME ejemplo.com.
# MX - Servidor de correo (con prioridad)
ejemplo.com. IN MX 10 mail1.ejemplo.com.
ejemplo.com. IN MX 20 mail2.ejemplo.com.
# NS - Servidores de nombres autoritativos
ejemplo.com. IN NS ns1.ejemplo.com.
ejemplo.com. IN NS ns2.ejemplo.com.
# TXT - Texto arbitrario (SPF, DKIM, verificaciones)
ejemplo.com. IN TXT "v=spf1 include:_spf.google.com ~all"Registros especiales
# SOA - Start of Authority (metadatos de la zona)
ejemplo.com. IN SOA ns1.ejemplo.com. admin.ejemplo.com. (
2024012801 ; Serial
7200 ; Refresh (2h)
3600 ; Retry (1h)
1209600 ; Expire (2 semanas)
86400 ) ; Minimum TTL (1 día)
# PTR - Resolución inversa (IP → nombre)
34.216.184.93.in-addr.arpa. IN PTR ejemplo.com.
# SRV - Servicio específico (puerto y prioridad)
_sip._tcp.ejemplo.com. IN SRV 10 5 5060 sip.ejemplo.com.
# CAA - Autorización de Certificados
ejemplo.com. IN CAA 0 issue "letsencrypt.org"Consultar registros con dig
# Registro A
$ dig ejemplo.com A +short
93.184.216.34
# Registro MX
$ dig ejemplo.com MX +short
10 mail1.ejemplo.com.
20 mail2.ejemplo.com.
# Todos los registros
$ dig ejemplo.com ANY
# Consulta con traza completa
$ dig +trace www.google.comTTL: el tiempo de vida
Cada registro tiene un TTL (Time To Live) que indica cuánto tiempo puede cachearse:
ejemplo.com. 300 IN A 93.184.216.34
│
└─ TTL: 300 segundos (5 minutos)El balance del TTL:
| TTL | Ventaja | Desventaja |
|---|---|---|
| Bajo (60-300s) | Cambios rápidos, failover ágil | Más consultas, más carga |
| Alto (86400s) | Menos tráfico, más rápido | Cambios tardan en propagarse |
Tip: Antes de una migración, baja el TTL a 60 segundos. Espera el TTL anterior. Haz el cambio. Cuando confirmes que funciona, sube el TTL de nuevo.
Caché DNS: las múltiples capas
Una consulta puede cachearse en varios niveles:
┌────────────────────────────────────────────────────────────┐
│ Tu navegador │
│ (caché interno) │
└─────────────────────────┬──────────────────────────────────┘
│ miss
┌─────────────────────────▼──────────────────────────────────┐
│ Sistema operativo │
│ (nscd, systemd-resolved) │
└─────────────────────────┬──────────────────────────────────┘
│ miss
┌─────────────────────────▼──────────────────────────────────┐
│ Router/Gateway │
│ (caché local) │
└─────────────────────────┬──────────────────────────────────┘
│ miss
┌─────────────────────────▼──────────────────────────────────┐
│ Resolver del ISP │
│ (o 8.8.8.8, 1.1.1.1) │
└─────────────────────────┬──────────────────────────────────┘
│ miss
┌─────────────────────────▼──────────────────────────────────┐
│ Servidores autoritativos │
│ (la fuente de verdad) │
└────────────────────────────────────────────────────────────┘Limpiar caché DNS
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux (systemd)
sudo systemd-resolve --flush-caches
# Chrome tiene su propio caché
# Visita: chrome://net-internals/#dnsDNS recursivo vs autoritativo
Es importante distinguir dos roles:
Servidor recursivo (Resolver)
- Recibe consultas de clientes
- Hace el trabajo de buscar la respuesta
- Cachea resultados
- Ejemplos: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), tu ISP
Servidor autoritativo
- Tiene la información oficial de una zona
- Responde “Yo soy la autoridad para este dominio”
- No hace consultas a otros servidores
- Ejemplos: ns1.tudominio.com, route53, cloudflare dns
Cliente ──► Resolver ──► Root ──► TLD ──► Autoritativo
(recursivo) (todos autoritativos)Zonas y delegación
Una zona es la porción del espacio de nombres que administras:
# Archivo de zona para ejemplo.com
$ORIGIN ejemplo.com.
$TTL 3600
@ IN SOA ns1.ejemplo.com. admin.ejemplo.com. (
2024012801 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
86400 ) ; minimum
; Servidores de nombres
@ IN NS ns1.ejemplo.com.
@ IN NS ns2.ejemplo.com.
; Glue records (IPs de los NS)
ns1 IN A 203.0.113.10
ns2 IN A 203.0.113.11
; Registros del dominio
@ IN A 93.184.216.34
www IN CNAME @
mail IN A 93.184.216.35
@ IN MX 10 mail.ejemplo.com.
; Subdominio delegado
blog IN NS ns1.bloghost.com.
blog IN NS ns2.bloghost.com.La última sección delega blog.ejemplo.com a otro servidor DNS.
DNSSEC: firmando el DNS
DNS original no tiene autenticación. Un atacante puede:
- Cache poisoning: Inyectar respuestas falsas en resolvers
- Man-in-the-middle: Interceptar y modificar respuestas
DNSSEC agrega firmas criptográficas:
┌───────────────────────────────────────────────────────────┐
│ Cadena de confianza │
├───────────────────────────────────────────────────────────┤
│ │
│ Root (.) │
│ │ firma │
│ ▼ │
│ .com (DS record apunta a DNSKEY de .com) │
│ │ firma │
│ ▼ │
│ ejemplo.com (DS record apunta a DNSKEY de ejemplo.com) │
│ │ firma │
│ ▼ │
│ www.ejemplo.com (RRSIG firma el registro A) │
│ │
└───────────────────────────────────────────────────────────┘Registros DNSSEC
# DNSKEY - Clave pública de la zona
ejemplo.com. IN DNSKEY 257 3 13 (base64...)
# DS - Digest del DNSKEY (en zona padre)
ejemplo.com. IN DS 12345 13 2 (hash...)
# RRSIG - Firma de un conjunto de registros
ejemplo.com. IN RRSIG A 13 2 3600 (firma...)Verificar DNSSEC
$ dig ejemplo.com +dnssec
# Buscar el flag "ad" (Authenticated Data)
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2DNS sobre HTTPS/TLS (DoH/DoT)
DNS tradicional viaja en texto plano por UDP puerto 53. Cualquiera puede ver qué sitios visitas.
DoT (DNS over TLS) - Puerto 853
Cliente ─────[TLS]───── Resolver
cifradoDoH (DNS over HTTPS) - Puerto 443
Cliente ─────[HTTPS]───── Resolver
como tráfico web normal# Consulta DoH con curl
curl -H "accept: application/dns-json" \
"https://cloudflare-dns.com/dns-query?name=ejemplo.com&type=A"Configurar en tu sistema
# systemd-resolved (Linux)
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com
DNSOverTLS=yes
# Firefox: Configuración → Privacidad → DNS sobre HTTPS
# Chrome: Configuración → Seguridad → Usar DNS seguroDNS como balanceador de carga
DNS puede distribuir tráfico entre servidores:
Round Robin
www.ejemplo.com. IN A 192.0.2.1
www.ejemplo.com. IN A 192.0.2.2
www.ejemplo.com. IN A 192.0.2.3El resolver rota el orden en cada respuesta.
Geolocalización
Servicios como Cloudflare o Route53 responden diferente según el origen:
Cliente en España → "www.ejemplo.com es 185.x.x.x" (servidor EU)
Cliente en USA → "www.ejemplo.com es 104.x.x.x" (servidor US)Health checks
DNS inteligentes solo devuelven IPs de servidores saludables:
Servidor 1: ✓ activo → incluido en respuesta
Servidor 2: ✗ caído → removido temporalmente
Servidor 3: ✓ activo → incluido en respuestaHerramientas de diagnóstico
dig (la navaja suiza)
# Consulta básica
dig ejemplo.com
# Solo la respuesta
dig ejemplo.com +short
# Traza completa (ver toda la jerarquía)
dig +trace ejemplo.com
# Consultar servidor específico
dig @8.8.8.8 ejemplo.com
# Ver tiempo de respuesta
dig ejemplo.com | grep "Query time"nslookup
nslookup ejemplo.com
nslookup -type=MX ejemplo.comhost
host ejemplo.com
host -t MX ejemplo.comwhois (información del dominio)
whois ejemplo.comErrores comunes y soluciones
| Error | Causa | Solución |
|---|---|---|
NXDOMAIN | Dominio no existe | Verificar ortografía, ¿expiró el dominio? |
SERVFAIL | Servidor no puede resolver | Problema en NS autoritativo o DNSSEC |
REFUSED | Servidor rechaza consulta | No tienes permiso o servidor mal configurado |
Timeout | Sin respuesta | Firewall, servidor caído, o red lenta |
# Diagnóstico rápido
dig ejemplo.com @8.8.8.8 # ¿Funciona con otro resolver?
dig ejemplo.com @ns1.ejemplo.com # ¿Responde el autoritativo?
dig +trace ejemplo.com # ¿Dónde falla la cadena?Conclusión
DNS es uno de los sistemas más críticos de Internet, y a la vez uno de los más subestimados. Sus características clave:
- Distribuido: No hay un único punto de falla
- Jerárquico: Escala infinitamente por delegación
- Cacheado: Millones de consultas por segundo sin colapsar
- Extensible: Nuevos tipos de registros sin romper compatibilidad
Cada vez que escribes una URL, esta maquinaria invisible traduce nombres legibles a direcciones IP en milisegundos. Y aunque funciona tan bien que lo damos por sentado, entender DNS es fundamental para cualquier desarrollador o administrador de sistemas.
La próxima vez que un sitio “no cargue”, ya sabes por dónde empezar a investigar: dig +trace dominio.com.
Este artículo es parte de la serie sobre Protocolos de Red.