DHCP y DNS: quién te da la IP y quién traduce los nombres

Antes de leer esto

• Direcciones IP y subredes
• Modelos OSI y TCP-IP

Conectas el portátil al Wi-Fi, escribes byte.black en el navegador y la web carga. Parece lo más normal del mundo, pero por detrás han trabajado dos servicios sin los que una red no se puede usar:

1. DHCP → le ha dado al portátil su IP, su máscara, su puerta de enlace y su DNS.
2. DNS → ha traducido byte.black a una dirección IP, que es lo único que entiende la red.

Los dos son de esos servicios que nadie nota hasta que fallan. Y cuando fallan, parece que “no hay internet” aunque la conexión esté perfecta.

DHCP: IPs automáticas

Sin DHCP (Dynamic Host Configuration Protocol), tendrías que configurar a mano la IP de cada móvil, portátil, tele o bombilla inteligente que entra en tu red. Con una casa normal ya sería un infierno; en un negocio con Wi-Fi para clientes, directamente imposible.

El servidor DHCP (normalmente el router) tiene un rango de IPs para repartir y, cuando un equipo se conecta, le presta una.

Cómo funciona: DORA

El intercambio tiene cuatro pasos, y se recuerda con la palabra DORA:

Equipo nuevo                                        Servidor DHCP
     │                                                     │
     │ 1. DISCOVER  "¿Hay algún DHCP por aquí?" (broadcast) │
     │ ──────────────────────────────────────────────────► │
     │                                                     │
     │ 2. OFFER     "Te ofrezco la 192.168.1.120"           │
     │ ◄────────────────────────────────────────────────── │
     │                                                     │
     │ 3. REQUEST   "Vale, me la quedo"                     │
     │ ──────────────────────────────────────────────────► │
     │                                                     │
     │ 4. ACK       "Confirmado, es tuya durante 24 h"      │
     │ ◄────────────────────────────────────────────────── │

El primer mensaje va por broadcast, porque el equipo todavía no tiene IP ni sabe dónde está el servidor. Todo viaja por UDP: el servidor escucha en el puerto 67 y el cliente en el 68.

Lo que reparte, además de la IP

En la respuesta no va solo la IP. El servidor también entrega:

1. Máscara de red → para que el equipo sepa cuál es su red.
2. Puerta de enlace → el router por el que salir.
3. Servidores DNS → a quién preguntar los nombres.
4. Tiempo de concesión (lease) → cuánto tiempo puede usar esa IP. Antes de que caduque, el equipo pide renovarla.

Esto es importante: si el DHCP entrega un dato mal, todos los equipos lo reciben mal. Un DNS equivocado en el DHCP y toda la red “se queda sin internet” de golpe.

IPs fijas y reservas

Hay equipos que conviene que tengan siempre la misma IP: servidores, impresoras, el NAS, las cámaras… Hay dos formas de conseguirlo:

1. IP estática → se configura a mano en el propio equipo. Tiene que quedar fuera del rango del DHCP, o tarde o temprano el DHCP se la dará a otro y tendrás un conflicto.
2. Reserva DHCP → en el servidor DHCP se asocia la MAC del equipo a una IP. El equipo sigue pidiéndola por DHCP, pero siempre recibe la misma. Es mi opción favorita para casi todo, porque la configuración queda centralizada en un solo sitio.

Mi regla para no liarme

En mis redes uso siempre el mismo reparto: de la .1 a la .99 para IPs fijas y reservas, y de la .100 en adelante para el DHCP. Sea la red que sea, sé de un vistazo si una IP es “de algo importante” o de un equipo de paso.

Cuando el DHCP falla

1. El equipo se pone una IP 169.254.x.x → no ha recibido respuesta del DHCP. Como vimos en Direcciones IP y subredes, es una IP APIPA y no sirve para salir a ningún sitio.
2. Dos servidores DHCP en la misma red → cada equipo se queda con el primero que responda, y unos acaban con una configuración y otros con otra. Pasa mucho al conectar un segundo router “tal cual sale de la caja” detrás del principal.
3. Se agota el rango → en una red con mucho móvil de paso (como un Wi-Fi de clientes) y concesiones largas, las IPs se acaban. La solución es un rango más grande o concesiones más cortas.

DNS: la agenda de internet

Las máquinas se encuentran por IP, pero las personas recordamos nombres. El DNS (Domain Name System) es el servicio que hace la traducción: le preguntas por byte.black y te responde con su IP.

Cómo se resuelve un nombre

El DNS es una jerarquía, como un árbol que se lee de derecha a izquierda:

                        . (raíz)
                ┌───────┼────────┐
               com     black     es        ← dominios de primer nivel (TLD)
                         │
                       byte                ← tu dominio
                         │
                        www                ← subdominio

Cuando tu equipo quiere saber la IP de www.byte.black, el proceso es este:

1. Tu equipo pregunta a su resolvedor DNS (el que le dio el DHCP: el router, Pi-hole, 1.1.1.1…).
2. Si el resolvedor ya lo tiene en caché, responde al momento.
3. Si no, pregunta a los servidores raíz → “los .black los lleva tal servidor”.
4. Pregunta al servidor del TLD .black → “byte.black lo lleva tal otro”.
5. Pregunta al servidor autoritativo de byte.black → “www.byte.black es tal IP”.
6. Guarda la respuesta en caché y te la devuelve.

Todo esto pasa en milisegundos, normalmente por UDP en el puerto 53.

Los registros que vas a usar

Cada dominio tiene una zona con sus registros. Los más habituales son estos:

Registro	Para qué sirve	Ejemplo
A	Nombre → IPv4	byte.black → 203.0.113.45
AAAA	Nombre → IPv6	byte.black → 2001:db8::45
CNAME	Alias de otro nombre	www.byte.black → byte.black
MX	Servidor de correo del dominio	byte.black → mail.byte.black
TXT	Texto libre (verificaciones, SPF, DKIM…)	"v=spf1 -all"
NS	Qué servidores llevan la zona	byte.black → ns1.proveedor.com
PTR	IP → nombre (resolución inversa)	203.0.113.45 → byte.black
CAA	Qué autoridades pueden emitir certificados	0 issue "letsencrypt.org"

El TTL y la caché

Cada registro lleva un TTL (Time To Live): los segundos que se puede guardar en caché antes de volver a preguntar. Por eso, cuando cambias la IP de un dominio, el cambio no se ve al instante en todas partes: hay resolvedores que todavía tienen la respuesta antigua guardada hasta que caduque el TTL.

Antes de una migración

Si vas a cambiar la IP de un servicio, baja el TTL del registro (por ejemplo, a 300 segundos) un día antes. Cuando hagas el cambio, todo el mundo verá la IP nueva en minutos y no en horas.

Probarlo tú mismo

nslookup byte.black            # Windows y Linux
dig byte.black A               # Linux, más detallado
dig byte.black MX +short       # solo el resultado
dig @1.1.1.1 byte.black        # preguntando a un DNS concreto

Y un clásico: antes de preguntar a ningún DNS, el equipo mira su archivo hosts (/etc/hosts en Linux, C:\Windows\System32\drivers\etc\hosts en Windows). Lo que pongas ahí manda sobre el DNS. Va genial para hacer pruebas, y es un dolor de cabeza si te olvidas de quitarlo.

En mi caso: el DNS secundario que se salta el Pi-hole

Cuando planifiqué la red con Pi-hole (un DNS local que bloquea publicidad y rastreadores), en mis notas lo dejé así: Pi-hole como DNS principal en el DHCP y, “por si acaso”, 8.8.8.8 como secundario. Parece lo más sensato: si el Pi-hole se cae, la red sigue funcionando.

Pero es un error muy típico. Los equipos no usan el secundario solo cuando falla el principal: muchos sistemas reparten las consultas entre los dos, o se quedan con el que responde más rápido. El resultado es que una parte de la publicidad pasa igualmente y en los registros del Pi-hole faltan consultas.

La solución buena es poner como DNS solo resolvedores que apliquen las mismas reglas: o dos Pi-hole sincronizados, o el Pi-hole solo. Y si quieres redundancia de verdad, la segunda instancia en otra máquina.

Errores típicos

• “No hay internet” cuando en realidad falla el DNS → prueba ping 1.1.1.1. Si responde pero ping byte.black no, la conexión va bien y lo que falla es el DNS.
• IPs fijas dentro del rango del DHCP → conflicto asegurado tarde o temprano.
• Dos servidores DHCP en la misma red → configuraciones mezcladas. Si conectas un router detrás de otro, desactívale el DHCP o ponlo en modo punto de acceso.
• Cambiar un registro DNS y esperar que se vea al momento → manda el TTL. Ten paciencia o baja el TTL antes.
• Olvidarte de una entrada en el archivo hosts → el equipo ignora el DNS para ese nombre y te vuelves loco buscando el fallo en otra parte.

Resumen

• DHCP → reparte IP, máscara, puerta de enlace y DNS de forma automática. Proceso DORA, por UDP 67/68.
• Para equipos importantes → IP fija fuera del rango o, mejor, reserva por MAC.
• DNS → traduce nombres a IPs mediante una jerarquía: raíz, TLD y servidor autoritativo. Normalmente por UDP 53.
• Registros clave → A, AAAA, CNAME, MX, TXT, NS, PTR y CAA. El TTL decide cuánto dura la caché.
• Si responde ping 1.1.1.1 pero no los nombres → es el DNS.

---

Siguiente: NAT y PAT Relacionado: Direcciones IP y subredes, Índice de Redes