dnsmasq Caché + DHCP: una configuración limpia que no entra en conflicto con tu sistema

El modelo mental: quién controla DNS y quién controla DHCP

Una implementación «limpia» de dnsmasq trata principalmente de límites. DNS y DHCP son protocolos separados, pero operativamente están pegados:
DHCP asigna direcciones (y servidores DNS), y DNS responde a las preguntas que tus clientes hacen cuando intentan usar esas direcciones.

Tu mayor fuente de dolor es dos componentes distintos creyendo que son los jefes:
un demonio reescribiendo /etc/resolv.conf, otro demonio enlazado al puerto 53, el DHCP del router todavía ejecutándose en segundo plano,
y algún cliente VPN bienintencionado metiendo reglas de DNS dividido en la mezcla.

Qué significa «no entrar en conflicto con tu sistema»

• Autoridad única para DHCP en un segmento L2 dado. Sin excepciones. No «casi».
• Propiedad clara de la resolución stub en los clientes: o bien systemd-resolved es el stub local, o lo es dnsmasq.
• Un único lugar para definir DNS ascendentes (o al menos uno por clase de clientes), con anulaciones previsibles.
• Registro que puedas activar cuando lo necesites, pero no un monumento permanente que se coma el disco por curiosidad.

dnsmasq puede desempeñar varios roles: reenviador/caché DNS, servidor DNS autoritativo para zonas locales, servidor DHCP,
servidor TFTP para PXE y más. El modo de fallo ocurre cuando hace la mitad de cada rol mientras algo más hace la otra mitad.
Ahí es cuando tienes «funciona en Wi‑Fi pero no en Ethernet» y «solo falla los martes».

Hechos interesantes y breve historia que realmente importa

• El objetivo de diseño de dnsmasq fueron redes pequeñas: un demonio, poca memoria, dependencias mínimas, comportamiento predecible bajo carga.
• El puerto 53 ha sido un campo de batalla desde los años 90: los «resolvers locales de caché» se hicieron populares porque la recursión ascendiente era lenta y frágil.
• La verdadera superpotencia de DHCP es centralizar la política: no solo direcciones, sino puerta de enlace predeterminada, servidores DNS, NTP y opciones específicas del proveedor.
• systemd-resolved normalizó el patrón de «resolver stub»: las aplicaciones consultan a un oyente local (127.0.0.53) y este reenvía hacia arriba con política.
• El caché DNS puede ocultar fallos ascendentes temporalmente, lo cual es agradable hasta que los TTL expiran y tu sistema «estable» se cae de golpe.
• El caché negativo (NXDOMAIN en caché) existe: almacenar «este nombre no existe» puede acelerar fallos—y también prolongarlos.
• El DNS dividido predates a la mayoría de clientes VPN: las empresas han hecho «las zonas internas se resuelven internamente» desde antes de que las laptops fueran de moda.
• El tiempo de concesión DHCP es una palanca: demasiado corto golpea tu servidor; demasiado largo retrasa la recuperación de asignaciones y cambios erróneos.
• Los dominios de búsqueda DNS son una trampa: una sola lista de búsqueda mala puede convertir una consulta en seis y hacer que la latencia parezca pérdida de paquetes.

Una idea parafraseada que deberías clavarte en el monitor: idea parafraseada de John Allspaw—la confiabilidad viene de entender cómo fallan los sistemas,
no de pretender que no fallarán. DNS es un sistema que falla de maneras creativas.

Elige una arquitectura (y mantenla)

Arquitectura A: dnsmasq controla caché DNS de LAN + DHCP; los clientes lo usan directamente

Esta es la más limpia para laboratorios domésticos y pequeñas oficinas: los clientes obtienen DHCP de dnsmasq y usan dnsmasq como su servidor DNS.
dnsmasq reenvía a resolvers ascendentes (tu ISP, resolvers públicos o un resolutor recursivo interno).

La ganancia operativa: una máquina es la fuente de la verdad sobre «qué hay en mi LAN», y puedes enseñarle nombres locales.
El riesgo operativo: si lo colocas en un portátil, te mereces lo que obtengas. Ponlo en algo aburrido.

Arquitectura B: systemd-resolved en clientes; dnsmasq solo DHCP (o solo DNS)

Esto funciona cuando estás en una flota corporativa donde systemd-resolved es estándar y los clientes VPN se integran con él.
En este modo, dnsmasq puede ofrecer DHCP y proporcionar servidores DNS, pero los clientes siguen usando su resolver stub local.

Es viable, pero también es como terminas con «el DNS es diferente según quién inició sesión por última vez». Puedes hacerlo.
Solo necesitas disciplina.

Arquitectura C: dnsmasq como caché local en cada máquina

Normalmente no vale la pena. Si lo haces, esencialmente creas N cachés pequeños con N conjuntos de reglas ascendentes.
La depuración se vuelve danza interpretativa.

Opinión: Para la mayoría de redes pequeñas, elige la Arquitectura A. Es más simple, depurable y puedes hacerla altamente fiable con casi ningún esfuerzo.

Broma #1: El DNS es como la política de oficina—todos juran que «no es su departamento», pero decide si algo se hace.

La configuración limpia de dnsmasq (caché DNS + DHCP) para una LAN

Supuestos para esta configuración:

• Servidor Linux ejecutando dnsmasq
• Interfaz LAN: eth0
• Subred LAN: 192.168.50.0/24
• IP de dnsmasq en LAN: 192.168.50.1
• Dominio local: lan
• DNS ascendentes: 1.1.1.1 y 9.9.9.9 (reemplaza según necesites)

Principios centrales incorporados en la configuración

• Enlazar explícitamente a la interfaz/IP de LAN para no convertirte accidentalmente en «DNS para el universo».
• No leer el estado de resolutor aleatorio a menos que lo hagas a propósito. Si dependes de /etc/resolv.conf, heredas su caos.
• Sé explícito respecto a tu dominio local y nombres locales.
• Registra solo lo que necesitas, y sabe cómo activarlo durante incidentes.

dnsmasq.conf (base limpia)

cr0x@server:~$ sudo tee /etc/dnsmasq.d/lan.conf >/dev/null <<'EOF'
# ---- Identity & safety rails ----
domain-needed
bogus-priv
no-hosts
no-resolv

# Bind only where we intend to serve
interface=eth0
listen-address=192.168.50.1
bind-interfaces

# ---- Upstream DNS ----
server=1.1.1.1
server=9.9.9.9

# ---- Local DNS behavior ----
domain=lan
local=/lan/
expand-hosts
cache-size=10000
neg-ttl=60

# If you want local names from /etc/hosts, do it intentionally:
addn-hosts=/etc/dnsmasq.hosts

# ---- DHCPv4 ----
dhcp-authoritative
dhcp-range=192.168.50.50,192.168.50.199,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,192.168.50.1
dhcp-option=option:domain-name,lan
dhcp-option=option:ntp-server,192.168.50.1

# Example static lease: MAC,IP,hostname,lease-time
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.50.10,nas,24h

# ---- Logging (keep default quiet; enable when diagnosing) ----
log-async=20
#log-queries
#log-dhcp
EOF

Unas notas que ahorran tiempo real:

• no-resolv significa «no confío en /etc/resolv.conf». Bien. No deberías, a menos que lo controles.
• bind-interfaces más listen-address impide la exposición accidental en interfaces VPN o puentes de Docker.
• dhcp-authoritative es cómo evitas que los clientes se aferren a concesiones obsoletas después de reconfigurar. Úsalo solo si eres realmente la autoridad DHCP para esa subred.
• cache-size=10000 es razonable en hardware moderno. Cachés diminutas convierten DNS en un amplificador de latencia.

Registros locales de hosts (separados intencionadamente)

cr0x@server:~$ sudo tee /etc/dnsmasq.hosts >/dev/null <<'EOF'
192.168.50.1   gw gw.lan
192.168.50.10  nas nas.lan
192.168.50.20  build build.lan
EOF

Mantener los nombres locales de dnsmasq fuera de /etc/hosts es una decisión operativa: reduce el acoplamiento accidental con el comportamiento del resolutor del sistema.
Cuando estás depurando a las 2 a.m., quieres menos piezas móviles, no más.

Habilitar y reiniciar

cr0x@server:~$ sudo systemctl enable --now dnsmasq
...output...

Si ves «failed», no adivines. Ve a la sección de tareas y verifica el enlace de puertos, la sintaxis de la configuración y servicios en conflicto.

Deja de pelear con el SO: systemd-resolved, NetworkManager, resolvconf

La raíz de la mayoría de luchas: el puerto 53 y /etc/resolv.conf

En muchas distribuciones modernas de Linux, systemd-resolved ejecuta un resolver stub en 127.0.0.53:53.
Eso está bien—hasta que intentas ejecutar dnsmasq en el mismo host y también enlazar el puerto 53 en 0.0.0.0 o en localhost.

La segunda pelea es /etc/resolv.conf. Puede ser:

• un archivo plano gestionado por ti,
• un enlace simbólico al archivo stub de systemd-resolved,
• gestionado por resolvconf,
• reescrito por NetworkManager,
• o todo lo anterior, brevemente, durante el arranque.

Patrón recomendado para un host servidor de dnsmasq

Si este servidor es tu caja DNS/DHCP de LAN, el enfoque más limpio es:

• dnsmasq escucha en la IP de LAN (p. ej., 192.168.50.1) para los clientes
• el propio servidor puede usar o bien:
  • dnsmasq (apunta su resolutor a 127.0.0.1 o 192.168.50.1), o
  • systemd-resolved (y dnsmasq nunca enlaza 127.0.0.1:53)

Mi preferencia: dejar que el servidor use dnsmasq también, pero hacerlo deliberadamente. Si quieres systemd-resolved, mantén dnsmasq fuera del localhost.
Elige uno, documéntalo y sigue adelante.

Cómo coexistir con systemd-resolved (sin drama)

Opción 1 (común): dnsmasq sirve la LAN en 192.168.50.1; systemd-resolved se queda para la resolución stub local. No hay conflicto si dnsmasq no enlaza 127.0.0.1.
Eso es lo que consigue listen-address=192.168.50.1.

Opción 2 (si quieres dnsmasq como resolutor local): desactiva systemd-resolved y gestiona /etc/resolv.conf tú mismo.
Esto está bien en un servidor dedicado. Es mala idea en un portátil con software VPN que espera systemd-resolved.

Trampa de NetworkManager

NetworkManager puede ejecutar su propia instancia de dnsmasq para caché en el cliente. Eso no es lo mismo que tu dnsmasq de servidor,
pero puede confundir la depuración porque «dnsmasq está ejecutándose» podría referirse al equivocado.

Si tu servidor usa NetworkManager, sé explícito sobre el manejo de DNS (o deja que NM lo gestione o no lo hagas).
No lo dejes medio gestionado.

Broma #2: La forma más fácil de probar DNS es preguntar a tres personas cómo funciona—y ver cómo todas discrepan con seguridad.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

Estas son tareas operativas reales. Cada una incluye: un comando, qué significa la salida y qué decides a continuación.
Ejecútalas en el host de dnsmasq salvo que se indique lo contrario.

Tarea 1: Confirma que dnsmasq está en ejecución y no se está reiniciando

cr0x@server:~$ systemctl status dnsmasq --no-pager
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-12-31 09:12:01 UTC; 2h 10min ago
   Main PID: 1324 (dnsmasq)
      Tasks: 1 (limit: 18956)
     Memory: 6.4M
     CGroup: /system.slice/dnsmasq.service
             └─1324 /usr/sbin/dnsmasq -k

Significado: «active (running)» con un tiempo de actividad estable significa que el demonio no se está bloqueando/reiniciando.
Decisión: Si el tiempo de actividad es segundos/minutos, ve directamente a journalctl (Tarea 2) y a la prueba de configuración (Tarea 3).

Tarea 2: Lee los últimos errores de dnsmasq

cr0x@server:~$ sudo journalctl -u dnsmasq -n 80 --no-pager
Dec 31 09:11:59 server dnsmasq[1312]: failed to bind DHCP server socket: Address already in use
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Failed with result 'exit-code'.

Significado: Otro servidor DHCP ya está enlazado (a menudo isc-dhcp-server o tu router sigue ejecutándose en ese segmento).
Decisión: Identifica quién posee UDP/67 (Tarea 4) y mata/deshabilita el DHCP en conflicto en esa red. No «trabajes alrededor» de ello.

Tarea 3: Valida la sintaxis de la configuración de dnsmasq antes de reiniciar

cr0x@server:~$ sudo dnsmasq --test
dnsmasq: syntax check OK.

Significado: La sintaxis está bien; fallos en tiempo de ejecución probablemente sean enlace de puertos, permisos o entorno.
Decisión: Si obtienes «bad option» o un error de parseo de archivo, arréglalo antes de reiniciar—no juegues a la ruleta de configuración en producción.

Tarea 4: Comprueba quién escucha en los puertos DNS y DHCP

cr0x@server:~$ sudo ss -ulpn | egrep ':(53|67)\s'
udp   UNCONN 0      0             192.168.50.1:53        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=6))
udp   UNCONN 0      0               0.0.0.0:67        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=4))

Significado: dnsmasq posee UDP/53 en la IP de LAN y UDP/67 para DHCP.
Decisión: Si ves systemd-resolved en 0.0.0.0:53 u otro proceso en :67, tienes un conflicto que resolver antes que nada.

Tarea 5: Confirma que /etc/resolv.conf es lo que crees

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 31 08:58 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Este host está usando el resolver stub de systemd-resolved.
Decisión: Está bien si dnsmasq es solo para la LAN en 192.168.50.1. Si quieres que el propio host use dnsmasq, cambia la estrategia de resolutor deliberadamente.

Tarea 6: Verifica la accesibilidad de DNS ascendentes desde el servidor

cr0x@server:~$ dig +time=1 +tries=1 @1.1.1.1 example.com A
; <<>> DiG 9.18.24 <<>> +time=1 +tries=1 @1.1.1.1 example.com A
;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34
;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

Significado: El upstream es accesible y responde rápidamente.
Decisión: Si esto agota el tiempo, tu problema no es dnsmasq—es enrutamiento, firewall o fallo upstream. Arregla eso primero.

Tarea 7: Verifica que dnsmasq responda localmente (lado servidor)

cr0x@server:~$ dig +short @192.168.50.1 nas.lan
192.168.50.10

Significado: La resolución de nombres locales funciona.
Decisión: Si los nombres locales fallan, revisa local=/lan/, domain=lan, y que tu archivo addn-hosts sea legible.

Tarea 8: Verifica que el cache realmente esté funcionando

cr0x@server:~$ sudo kill -USR1 $(pidof dnsmasq)
cr0x@server:~$ sudo journalctl -u dnsmasq -n 30 --no-pager
Dec 31 11:18:10 server dnsmasq[1324]: cache size 10000, 8121/10000 cache insertions re-used unexpired cache entries.

Significado: Las entradas de caché se están reutilizando; dnsmasq está cumpliendo su función como caché.
Decisión: Si la reutilización está cerca de cero, los clientes pueden estar evitando dnsmasq, o los TTL son demasiado bajos, o no estás sirviendo a los clientes que crees.

Tarea 9: Observa las concesiones DHCP en vivo

cr0x@server:~$ sudo tail -n 20 /var/lib/misc/dnsmasq.leases
1735643551 11:22:33:44:55:66 192.168.50.73 laptop *
1735644012 aa:bb:cc:dd:ee:ff 192.168.50.10 nas *

Significado: Se están asignando concesiones. Los campos son: epoch de expiración, MAC, IP, hostname, client-id.
Decisión: Si un cliente no obtiene dirección y no está aquí, tienes un problema de alcance DHCP (VLAN, firewall, DHCP en conflicto).

Tarea 10: Confirma que el cliente recibió el servidor DNS correcto por DHCP

cr0x@server:~$ ipconfig getpacket en0
...output...

Significado: En macOS, esto muestra la oferta/ack DHCP incluyendo servidores DNS. En Linux, usa la Tarea 11.
Decisión: Si el servidor DNS no es 192.168.50.1, tus opciones DHCP están mal o otro servidor DHCP está ganando.

Tarea 11: En un cliente Linux, comprueba qué DNS se está usando

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
    Current Scopes: DNS
         DNS Servers: 192.168.50.1
          DNS Domain: lan

Significado: systemd-resolved está activo, pero usa dnsmasq como servidor DNS upstream para ese enlace. Eso es normal y saludable.
Decisión: Si muestra solo 127.0.0.53 sin upstream, te faltan DNS proporcionados por DHCP o configuración de NM.

Tarea 12: Verifica que un cliente pueda resolver a través de dnsmasq y mide la latencia

cr0x@server:~$ dig @192.168.50.1 example.com A +stats
...output...
;; Query time: 3 msec

Significado: Un tiempo de consulta bajo sugiere cache hit o upstream rápido. Si lo ejecutas dos veces, la segunda debería ser típicamente más rápida (cache hit).
Decisión: Si el tiempo de consulta es centenares de ms o hay timeouts, revisa la salud upstream, pérdida de paquetes, MTU/VPN, y si DNS está siendo interceptado.

Tarea 13: Comprueba si estás filtrando consultas DNS por la interfaz equivocada

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 53 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
10 packets captured

Significado: Ves tráfico DNS en la interfaz LAN. Si no ves ninguno mientras los clientes se quejan, no te están consultando a tu dnsmasq.
Decisión: Arregla las opciones DHCP o la configuración del resolutor del cliente. No afines dnsmasq para tráfico que nunca ve.

Tarea 14: Encuentra un servidor DHCP deshonesto en la LAN

cr0x@server:~$ sudo nmap --script broadcast-dhcp-discover -e eth0
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-31 11:41 UTC
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 2:
|     IP Offered: 192.168.50.120
|     DHCP Server Identifier: 192.168.50.1
|   Response 2 of 2:
|     IP Offered: 192.168.50.210
|     DHCP Server Identifier: 192.168.50.254

Significado: Dos servidores DHCP respondieron. Esa es tu historia de fallo antes de convertirse en incidente.
Decisión: Apaga DHCP en el router (192.168.50.254) o mueve dnsmasq a otra VLAN/subred. No ejecutes DHCP en duelo.

Tarea 15: Confirma que el firewall permite DHCP y DNS

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "eth0" udp dport { 53, 67 } accept
    iif "eth0" tcp dport 53 accept
  }
}

Significado: DNS y DHCP están permitidos en la interfaz LAN.
Decisión: Si UDP/67 está bloqueado, DHCP no funcionará. Si UDP/53 está bloqueado, la mayoría de DNS no funcionará. Arregla las reglas antes de tocar dnsmasq.

Tarea 16: Prueba la ruta de solicitud DHCP desde un cliente (Linux)

cr0x@server:~$ sudo dhclient -v -r eth0
...output...
cr0x@server:~$ sudo dhclient -v eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.50.73 from 192.168.50.1
DHCPREQUEST for 192.168.50.73 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.50.73 from 192.168.50.1
bound to 192.168.50.73 -- renewal in 19958 seconds.

Significado: El cliente recibe ofertas/acks de tu servidor dnsmasq.
Decisión: Si ves ofertas de otro servidor, tienes DHCP en conflicto. Si no ves ofertas, es L2/VLAN/firewall.

Guion rápido de diagnóstico

Cuando DNS/DHCP está roto, no quieres un debate filosófico. Quieres un bucle cerrado: verifica autoridad, verifica accesibilidad, verifica la ruta cliente.
Aquí está el orden que encuentra el cuello de botella más rápido.

Primero: establece quién está a cargo

1. Ejecuta la Tarea 14 (broadcast DHCP discover). Si hay dos servidores DHCP, detente. Arregla eso primero.
2. En el host de dnsmasq, ejecuta la Tarea 4 (quién posee los puertos 53 y 67). Si dnsmasq no está enlazado como esperas, detente. Arregla conflictos de enlace.
3. En un cliente, ejecuta la Tarea 11 (resolvectl status o equivalente) para ver qué servidor DNS está usando realmente.

Segundo: verifica que el servidor esté sano

1. Tarea 1 + Tarea 2: estado del servicio y logs. Si está rebotando, no toques los clientes aún.
2. Tarea 3: comprobación de sintaxis. Esto atrapa los fallos de «cambié una línea a medianoche».
3. Tarea 6: accesibilidad de DNS ascendentes. Si upstream está caído, el caché puede enmascararlo brevemente; no te dejes engañar.

Tercero: verifica la ruta de paquetes

1. Tarea 13: tcpdump en la interfaz LAN para tráfico DNS. Sin paquetes significa que los clientes no te están preguntando.
2. Tarea 16: handshake DHCP desde un cliente. Si no hay DHCPOFFER, es L2/VLAN/firewall.
3. Tarea 15: comprobación de reglas de firewall.

Cuarto: aislar «lento» de «roto»

1. Tarea 12: dig +stats dos veces. La primera llamada prueba upstream; la segunda prueba el caché.
2. Tarea 8: estadísticas de caché vía USR1. Confirma que el caché se está usando.

Este guion es deliberadamente aburrido. Ese es el punto: evita perder tiempo en la capa equivocada.

Errores comunes: síntoma → causa raíz → solución

1) «DHCP funciona, pero DNS se queda sin respuesta al azar»

Síntoma: Los clientes obtienen una IP, pero la resolución de nombres es intermitente o lenta.

Causa raíz: Los clientes no están usando dnsmasq para DNS (opción DHCP incorrecta) o están usando un resolver ascendente roto vía política de VPN.

Solución: Verifica que DHCP haya entregado option:dns-server,192.168.50.1 (Tarea 10/11). Luego verifica que el tráfico llegue a dnsmasq (Tarea 13). Si hay DNS dividido por VPN, decide si la VPN debe anular el DNS de LAN y configura el reenvío dividido explícitamente.

2) «dnsmasq no arranca: address already in use»

Síntoma: systemd muestra que dnsmasq falló; los logs mencionan errores de bind.

Causa raíz: systemd-resolved (u otro servidor DNS) tiene el puerto 53, o otro servidor DHCP tiene el puerto 67.

Solución: Usa la Tarea 4 para identificar el proceso. Si solo necesitas dnsmasq en la IP de LAN, configura listen-address=192.168.50.1 y evita localhost. Si necesitas localhost también, desactiva el servicio en conflicto intencionalmente.

3) «Los clientes obtienen la puerta de enlace por defecto incorrecta»

Síntoma: Algunos clientes pueden resolver nombres pero no alcanzar Internet u otras VLAN.

Causa raíz: dhcp-option=option:router mal configurado, o servidor DHCP en conflicto entregando otra puerta de enlace.

Solución: Ejecuta la Tarea 14 para localizar el DHCP deshonesto. Luego corrige option:router. Confirma en el cliente usando la inspección del paquete DHCP (Tarea 10/16).

4) «Los nombres locales no se resuelven, pero los externos sí»

Síntoma: example.com se resuelve bien; nas.lan no.

Causa raíz: Falta local=/lan/ o domain=lan incorrecto; el archivo de hosts local no se está leyendo; o el dominio de búsqueda del cliente no está establecido.

Solución: Valida las respuestas locales de dnsmasq (Tarea 7). Asegúrate de que DHCP entregue option:domain-name,lan. Si no quieres dominios de búsqueda, enseña a los usuarios a usar FQDNs como nas.lan y sigue adelante.

5) «Después de un cambio, nada se actualiza por horas»

Síntoma: Cambiaste un registro o upstream, pero los clientes siguen recibiendo respuestas antiguas.

Causa raíz: TTLs y cachés (caché de dnsmasq, cachés de clientes, cachés de navegador), además de tiempos de concesión DHCP largos para cambios de servidor DNS.

Solución: Reduce los TTLs para registros que planeas mover. Para emergencias, reinicia dnsmasq (borra caché) y renueva las concesiones DHCP de los clientes. No uses permanentemente concesiones DHCP de 5 minutos para «arreglar» la gestión de cambios.

6) «DNS parece bien desde el servidor, roto desde los clientes»

Síntoma: dig @192.168.50.1 funciona en el servidor, pero los clientes tienen timeouts.

Causa raíz: Firewall bloqueando UDP/53, enlace en la interfaz incorrecta, aislamiento por VLAN, o el cliente no apunta al servidor.

Solución: Tarea 15 (firewall), Tarea 4 (binding), Tarea 13 (tcpdump), luego verifica las opciones DHCP en el cliente.

7) «El DNS se rompe solo cuando la VPN está conectada»

Síntoma: Los nombres corporativos internos se resuelven, pero los nombres de LAN dejan de hacerlo (o viceversa).

Causa raíz: Políticas de DNS dividido que anulan, o el cliente VPN cambia el orden de resolutores/dominios de búsqueda.

Solución: Decide la política: ¿la VPN debe anular todo o solo ciertos dominios? Implementa el reenvío dividido en dnsmasq usando dominios específicos server=/corp.example/10.0.0.53, o deja que systemd-resolved lo gestione y mantén dnsmasq puro para clientes LAN.

Tres mini-historias corporativas desde las trincheras

Incidente causado por una suposición equivocada: «El router es solo un router»

Una oficina mediana se mudó a un nuevo local. El contratista de red dejó un atractivo aparato de router/firewall.
El equipo interno montó una pequeña VM Linux para ejecutar dnsmasq porque querían nombres consistentes para kits de desarrollo e impresoras.
Asumieron que el aparato era «solo enrutamiento» y que el antiguo servicio DHCP se había desactivado durante el corte.

Todo funcionó por la mañana. Por la tarde, las pantallas de la sala de conferencias empezaron a caer de la red.
Algunos portátiles obtuvieron el servidor DNS esperado. Otros obtuvieron la configuración DNS por defecto del appliance.
La gente culpó al Wi‑Fi. La gente siempre culpa al Wi‑Fi.

La pista fue aburrida: aparecieron dos puertas de enlace por defecto diferentes en las configuraciones de cliente, dependiendo de quién renovó la concesión por última vez.
El appliance aún estaba ejecutando DHCP en la misma VLAN, entregando su propia puerta de enlace y opciones DNS.

La solución no fue ingeniosa. Ejecutaron un broadcast DHCP discover, confirmaron dos respondedores y desactivaron DHCP en el appliance.
Luego forzaron una renovación de concesión en los dispositivos problemáticos. La «aleatoriedad» desapareció al instante.

La lección: nunca asumas que el appliance de borde no está haciendo DHCP. Verifícalo. A los appliances les encantan las funciones como a los niños les encantan los rotuladores.

Optimización que salió mal: «Reducir consultas upstream casi a cero»

En otra organización, un equipo afinó el caché de dnsmasq agresivamente y añadió listas de dominios de búsqueda para «mejorar la usabilidad».
Su idea era simple: caché grande, comportamientos de TTL largos y un dominio de búsqueda para que la gente tipeara nombres cortos.
También habilitaron el registro de consultas permanentemente porque «es útil». Y lo fue.

Dos semanas después, los informes de incidentes mostraron inicios de sesión lentos a aplicaciones SaaS, fallos intermitentes al resolver ciertos dominios,
y periodos de alta espera de IO en la VM. La CPU estaba bien. La NIC estaba bien. El disco estaba triste.

El registro permanente de consultas produjo una alta tasa de churn en journald y en el almacenamiento subyacente.
La lista de dominios de búsqueda multiplicó las consultas: errores tipográficos y nombres cortos se expandieron en múltiples búsquedas fallidas por intento.
El caché negativo hizo el resto—respuestas NXDOMAIN temporales upstream se quedaron más tiempo del que el equipo esperaba.

«Optimizaban» hasta crear un cuello de botella: el sistema pasaba tiempo escribiendo logs sobre búsquedas que no deberían existir.
El servidor DNS era correcto. Simplemente estaba ocupado narrando su propia vida.

La solución: desactivar log-queries permanente, mantenerlo como una palanca para incidentes y recortar los dominios de búsqueda.
Mantuvieron un tamaño de caché razonable, pero dejaron de intentar hacer el DNS invisible mediante ingenios.

Práctica aburrida pero correcta que salvó el día: «Enlazar explícitamente, documentar la propiedad»

Una compañía financiera operaba una pequeña flota de servidores en oficinas satélite. Cada sucursal tenía un dnsmasq local que proveía DHCP y caché DNS
porque los enlaces WAN eran poco fiables y las aplicaciones sensibles a la latencia eran comunes.
El estándar de configuración era aburrido: dnsmasq enlazado solo a la interfaz LAN, resolutores ascendentes explícitos,
y DHCP autoritativo en exactamente una VLAN por sucursal.

Un día, un despliegue de VPN de emergencia añadió una nueva interfaz de túnel a cada servidor. De repente, muchos servicios empezaron a enlazarse
a interfaces extra. Así es como «solo interno» se convierte en «accesible desde lugares que no imaginaste».

A dnsmasq no le importó. Ya estaba fijado a la IP de LAN con listen-address y bind-interfaces.
No empezó a responder DNS en la interfaz VPN, y no filtró nombres locales al lugar equivocado.

Otros servicios se comportaron mal y tuvieron que parchearse rápidamente. DNS y DHCP siguieron funcionando, silenciosamente, en segundo plano.
Las oficinas notaron los cambios de VPN; no notaron que sus servicios núcleo de red permanecieran estables.
Eso es un cumplido que no aparece en un sistema de tickets.

La lección: la práctica aburrida—enlaces explícitos, upstreams explícitos, propiedad explícita—rinde frutos justo cuando tu entorno cambia bajo tus pies.

Listas de verificación / plan paso a paso

Plan A: Desplegar dnsmasq como caché DNS de LAN + servidor DHCP (recomendado)

1. Elige el límite de autoridad.
   Decide qué subred(es) servirá dnsmasq para DHCP. Desactiva DHCP en otros lugares de ese segmento.
2. Elige el ámbito de escucha.
   Escoge la IP e interfaz LAN. Usa listen-address y bind-interfaces.
3. Escribe una configuración mínima.
   Empieza con la configuración base de este artículo. Evita la proliferación de funciones.
4. Prueba la sintaxis.
   Ejecuta dnsmasq --test antes de reiniciar.
5. Inicia el servicio y verifica puertos.
   Usa ss -ulpn para confirmar que dnsmasq posee UDP/53 y UDP/67 como corresponde.
6. Verifica ofertas DHCP.
   Usa un cliente con dhclient -v o ejecuta un broadcast DHCP discover.
7. Verifica respuestas DNS.
   Prueba tanto nombres locales (p. ej., nas.lan) como nombres externos.
8. Activa el registro solo cuando lo necesites.
   Mantén log-queries comentado por defecto; actívalo durante incidentes y luego apágalo.
9. Documenta como si fueras a olvidarlo.
   Una página: qué subredes se sirven, dónde vive la configuración, quién posee los DNS ascendentes y cómo detectar DHCP deshonesto.

Plan B: Migrar de «DHCP del router» a dnsmasq sin un corte sorpresa

1. Reduce temporalmente el tiempo de concesión DHCP del router (p. ej., unas horas) un día antes de la migración.
2. Levanta dnsmasq en modo «solo DNS» primero (no habilites DHCP todavía). Valida el comportamiento DNS.
3. Programa una ventana corta de corte.
4. Desactiva DHCP en el router.
5. Habilita DHCP en dnsmasq con dhcp-authoritative y opciones correctas.
6. En algunos clientes de prueba, renueva concesiones y verifica DNS/puerta de enlace.
7. Observa el archivo de concesiones y los logs durante la primera hora. Espera que algunos clientes se aferren a concesiones obsoletas; fuerza renovaciones según sea necesario.
8. Restaura tiempos de concesión sensatos (p. ej., 12h o 24h) tras estabilizar.

Plan C: Hazlo resistente (sin convertirlo en un proyecto)

• Pon dnsmasq en un host estable (pequeña VM, NUC o servidor de bajo consumo) con UPS si te importa su continuidad.
• Mantén la configuración en un repositorio. Incluso un repo git privado en la caja es mejor que «creo que lo cambié el mes pasado».
• Haz copias de /etc/dnsmasq.d y de los archivos de concesiones si los mapeos estáticos importan.
• Monitorea: estado del servicio, latencia de consultas (dig sintético) y pérdida de paquetes en la LAN.

Preguntas frecuentes

1) ¿Debería desactivar systemd-resolved en los clientes?

Normalmente no. En flotas gestionadas y portátiles con clientes VPN, systemd-resolved suele ser el punto de integración.
Déjalo correr y solo asegúrate de que use tu dnsmasq como servidor DNS upstream para el enlace de la LAN.

2) ¿Debería desactivar systemd-resolved en el servidor dnsmasq?

Si dnsmasq es dedicado y quieres que también sea el resolutor del propio servidor, desactivar systemd-resolved puede simplificar las cosas.
Pero no es obligatorio—solo asegúrate de que dnsmasq no enlace localhost si systemd-resolved lo posee.

3) ¿Por qué usar no-resolv y entradas server= explícitas?

Porque /etc/resolv.conf suele ser gestionado por otros componentes y puede cambiar durante el arranque, la conexión VPN o cambios de enlace.
Los upstreams explícitos hacen el comportamiento predecible y la depuración más rápida.

4) ¿Qué tamaño de caché debería usar?

Para redes pequeñas, 5.000–20.000 suele ser suficiente. Si tienes poca RAM, uno más pequeño también está bien—solo no esperes milagros.
Mide usando estadísticas USR1 y la latencia de consultas antes y después.

5) ¿Puede dnsmasq hacer DNS dividido?

Sí. Puedes reenviar dominios específicos a resolutores ascendentes concretos usando server=/corp.example/10.0.0.53.
Mantenlo explícito y documentado, porque tu yo del futuro no recordará por qué solo un dominio se comporta distinto.

6) ¿Cómo sé si los clientes están evitando dnsmasq?

Ejecuta tcpdump en la interfaz del servidor para UDP/53 (Tarea 13). Si los clientes se quejan y no ves tráfico, no te están consultando.
Luego comprueba la configuración DNS del cliente (Tarea 11) y las opciones DHCP.

7) ¿Es seguro ejecutar dnsmasq en un host que también ejecuta Docker o Kubernetes?

Puede serlo, pero debes enlazar dnsmasq a la interfaz/IP prevista. Los stacks de contenedores crean interfaces extra,
y «escuchar en todas partes» se convierte en «responder DNS donde no deberías». Usa listen-address y bind-interfaces.

8) ¿Qué hay de IPv6 (SLAAC, RA, DHCPv6)?

dnsmasq puede ayudar con IPv6, pero IPv6 introduce más piezas móviles (anuncios de router, DHCPv6, DNS vía RDNSS).
Si estás empezando, estabiliza IPv4 primero. Luego añade IPv6 deliberadamente y prueba con capturas de paquetes.

9) ¿Debería habilitar la validación DNSSEC en dnsmasq?

Solo si entiendes los modos de fallo y tienes tiempo para depurarlos. DNSSEC puede mejorar la integridad,
pero las malas configuraciones y los upstreams rotos pueden crear incidentes de «todo está caído» que parecen problemas de red.

10) ¿Puedo ejecutar dos servidores dnsmasq para redundancia?

Para caché/reenviador DNS, sí—los clientes pueden tener múltiples servidores DNS. Para DHCP, la redundancia es más complicada.
Puedes dividir rangos o usar mecanismos de failover DHCP con otro software, pero dnsmasq por sí solo no es una solución HA de DHCP empresarial completa.
Para redes pequeñas, una segunda máquina de reserva fría y buenas copias de seguridad suelen ser la respuesta pragmática.

Próximos pasos que puedes hacer hoy

Si quieres que dnsmasq se comporte, deja de permitir que negocie la autoridad con lo que sea que esté instalado.
Elige la arquitectura, enlaza a la interfaz correcta, haz explícitos los DNS ascendentes y asegúrate de que DHCP tenga un único propietario.
Eso es el 80% de la historia de fiabilidad.

1. Ejecuta la comprobación de DHCP deshonesto (Tarea 14) en tu LAN y elimina dobles servidores.
2. Implementa la configuración base y valida puertos (Tarea 4) y sintaxis (Tarea 3).
3. Verifica la ruta del cliente: handshake DHCP (Tarea 16) y servidor DNS activo (Tarea 11).
4. Usa el registro como herramienta bajo demanda, no como estilo de vida.
5. Escribe quién posee qué: qué equipo es DHCP, qué equipo es DNS y cómo se ve lo «normal».

No necesitas una pila sofisticada para tener nombres y direcciones fiables. Necesitas una caja aburrida que haga su trabajo y un sistema que no la desafíe.