Configura el DNS y verifica el router, el cliente y el navegador

E2Reproducido en una VM de laboratorio

Entorno aplicableProbado

Firmware

OpenWrt

Versión

25.12.6

Gestor de paquetes

apk

Equipo

VM x86

Última prueba en laboratorio 2026-10-20Registro de pruebas

Resultado

Podrás responder tres preguntas por separado:

• ¿Qué servidor DNS upstream usa el router?
• ¿Qué servidor DNS recibe un cliente desde OpenWrt?
• ¿El navegador evita el resolvedor del sistema mediante DoH?

Y podrás volver a un estado en el que se resuelvan nombres después de un cambio fallido.

Entorno aplicable

• OpenWrt 25.12.6, con dnsmasq + odhcpd por defecto; 25.12 usa apk y 24.10 usa opkg.
• Los comandos de inspección no necesitan paquetes adicionales. Si el dispositivo ejecuta unbound o https-dns-proxy, comprueba primero quién ocupa el puerto 53.
• Las etiquetas de menú y las claves de configuración son similares en 24.10, pero los comandos de paquetes difieren; no copies comandos apk en 24.10.

Ruta del DNS y responsabilidades

Lugar	Responsable por defecto	Qué comprobar
Upstream de la WAN	Cliente DHCP/PPPoE	cat /tmp/resolv.conf.d/resolv.conf.auto
Resolvedor del router	dnsmasq	nslookup openwrt.org 127.0.0.1
Anuncio en la LAN	opción 6 de DHCP de dnsmasq / RDNSS de odhcpd	el DNS que se muestra en un cliente
Navegador	resolvedor del sistema o DoH del navegador	el ajuste de DNS seguro del navegador

Diagnostica la capa antes de reemplazar los servidores DNS.

Antes de cambiar nada

Shell del routerRespalda la configuración de DHCP/DNS

cp /etc/config/dhcp /etc/config/dhcp.bak.$(date +%F)
uci export dhcp > /tmp/dhcp.before
uci show dhcp | grep -E 'dns|resolv|server|option'

Conserva una vía cableada en la LAN hacia LuCI/SSH. No hagas que la única vía de administración dependa del DNS que estás cambiando.

EsperadoExiste una copia de seguridad y sabes cómo restaurarla.

Pasos mínimos

Shell del routerLee el DNS upstream y los ajustes de dnsmasq

cat /tmp/resolv.conf.d/resolv.conf.auto
uci show dhcp.@dnsmasq[0]
uci show network.wan | grep -E 'peerdns|dns'

/tmp/resolv.conf.d/resolv.conf.auto lo escribe el cliente de la WAN. Comprueba el valor real de dhcp.@dnsmasq[0].resolvfile. Si noresolv='1', dnsmasq ignora ese archivo y usa su lista server.

EsperadoPuedes nombrar los valores actuales de resolvfile, server y noresolv.

LuCIDefine un DNS personalizado en la WAN (primer cambio más seguro)

Abre Red → Interfaces → WAN → Configuración avanzada:

1. Desmarca “Use DNS servers advertised by peer” (peerdns pasa a 0).
2. Añade los servidores DNS de confianza en “Usar servidores DNS personalizados”, por ejemplo 1.1.1.1 y 9.9.9.9.
3. Guarda y aplica; después reconecta la WAN si hace falta.

Esto interrumpe brevemente la WAN, pero deja intacta la estructura DHCP/DNS de la LAN, lo que facilita revertir.

EsperadoTras reconectar la WAN, el resolvedor upstream es el valor que definiste.

Shell del routerConfirma que dnsmasq escucha y cargó el nuevo upstream

netstat -lnp | grep ':53'
/etc/init.d/dnsmasq restart
logread -e dnsmasq | tail -20

Si dnsmasq no arranca, deja de cambiar opciones de DHCP. Usa el texto del error para encontrar un error de sintaxis o un conflicto de puerto.

EsperadoEl puerto 53 está a la escucha y el registro no muestra errores de configuración.

LuCIComprueba el DNS anunciado a los clientes

Abre Red → DHCP y DNS → Servidor DHCP → Configuración avanzada y revisa “DHCP Options”. Sin la opción 6, los clientes normalmente usan la dirección LAN del router como DNS. Con la opción 6, reciben directamente esa dirección.

No apuntes los clientes a una dirección que no esté escuchando en el puerto 53.

EsperadoEl cliente recibe la dirección LAN de OpenWrt, o la opción 6 explícita que pretendías.

Shell del routerEquivalente por CLI (opcional)

uci set network.wan.peerdns='0'
uci -q delete network.wan.dns
uci add_list network.wan.dns='1.1.1.1'
uci commit network
ifup wan
cat /tmp/resolv.conf.d/resolv.conf.auto

Después del cambio, usa logread -e dnsmasq para confirmar el nuevo upstream. Si los clientes siguen recibiendo el DNS antiguo, reinicia dnsmasq o revisa la opción 6 de DHCP.

Esperadoresolv.auto muestra 1.1.1.1 y las consultas funcionan.

Verifica desde los clientes

Shell del routerComprueba A y AAAA en el router

nslookup openwrt.org 127.0.0.1
nslookup -type=AAAA openwrt.org 127.0.0.1

EsperadoAmbas consultas devuelven respuesta sin agotar el tiempo de espera.

OrdenadorComprueba el DNS que el cliente recibió realmente

Linux:

resolvectl status
cat /etc/resolv.conf
nslookup openwrt.org

Windows:

ipconfig /all
nslookup openwrt.org

macOS:

scutil --dns
nslookup openwrt.org

EsperadoEl DNS del cliente coincide con la configuración DHCP/estática y resuelve un nombre.

OrdenadorComprueba si el navegador evita el router

Chrome/Edge: chrome://settings/security o “Privacidad y seguridad → Seguridad → Usar DNS seguro”. Firefox: Ajustes → Privacidad y seguridad → DNS sobre HTTPS. Si DoH está activado, puede que no se use el resolvedor del sistema en absoluto; eso parece que “el DNS del router no surtió efecto”.

EsperadoDoH está desactivado durante la prueba, o sabes exactamente a dónde apunta.

OrdenadorComprueba la resolución IPv6 y RA/RDNSS

nslookup -type=AAAA openwrt.org
ip -6 route

No deduzcas que el DNS IPv6 funciona a partir de un resultado IPv4 cuando el upstream no tiene prefijo IPv6.

EsperadoAAAA resuelve cuando existe upstream IPv6; si no, anota la condición que falta.

Ramas de fallo y recuperación

Las páginas no cargan, pero el ping por IP funciona

Sospecha primero del DNS:

1. Comprueba el resolvedor del cliente: resolvectl status, ipconfig /all o scutil --dns.
2. Comprueba el puerto 53 y los registros de dnsmasq en el router: netstat -lnp | grep ':53', logread -e dnsmasq.
3. Comprueba el DoH del navegador y desactívalo temporalmente.
4. Comprueba si la opción 6 de DHCP tiene una dirección incorrecta.

LuCI/SSH no es accesible

Deja de cambiar el DNS. Conecta un cliente por cable a la LAN, asígnale una dirección estática en la misma subred y confirma que la puerta de enlace es la dirección LAN de OpenWrt. Restaura desde la consola o por SSH:

cp /etc/config/dhcp.bak.YYYY-MM-DD /etc/config/dhcp
uci commit dhcp
/etc/init.d/dnsmasq restart

Si cambiaste el DNS de la WAN, restaura el DNS upstream automático:

uci set network.wan.peerdns='1'
uci -q delete network.wan.dns
uci commit network
ifup wan

El DNS de la WAN cambió, pero los clientes siguen usando el resolvedor antiguo

Comprueba si resolv.auto cambió y después si dnsmasq cargó el nuevo upstream:

cat /tmp/resolv.conf.d/resolv.conf.auto
logread -e dnsmasq | tail -20
/etc/init.d/dnsmasq restart

Si resolv.auto no cambió, revisa network.wan.dns y peerdns. Si los clientes siguen recibiendo el DNS antiguo, revisa la opción 6 de DHCP y el DoH del navegador.

dnsmasq no arranca

Lee el error en lugar de reiniciar repetidamente:

logread -e dnsmasq | tail -50
dnsmasq --test

Las causas habituales son otro resolvedor que ocupa el puerto 53, un error de sintaxis o un upstream inaccesible. Restaura primero la copia de seguridad y vuelve a introducir los ajustes personalizados uno por uno.

Prueba E2 en laboratorio (2026-10-20)

• Entorno: PVE 9.2.2 con una sola NIC; VM 200 con OpenWrt 25.12.6; WAN 192.168.50.77/24, LAN 192.168.1.1/24.
• Línea base: resolv.auto era nameserver 192.168.50.1; nslookup openwrt.org 127.0.0.1 devolvió A/AAAA.
• Personalizado: peerdns=0 + network.wan.dns=1.1.1.1; resolv.auto cambió a nameserver 1.1.1.1; las consultas siguieron funcionando.
• Fallo: se definió como upstream de dnsmasq la dirección inaccesible 192.0.2.1; una consulta aleatoria a .example.com devolvió connection timed out; no servers could be reached; eliminar noresolv/server y restaurar peerdns=1 recuperó la resolución.
• Cliente: el DHCP en netns recibió 192.168.1.116/24, DNS 192.168.1.1; dig @192.168.1.1 openwrt.org funcionó; ping 192.168.50.1 funcionó.
• No probado: DoH del navegador, upstream IPv6/RA/RDNSS, clientes LAN físicos, estabilidad a largo plazo.

Fuentes y revisión

• Esta página tiene una reproducción E2 en laboratorio; el DoH del navegador y el upstream IPv6 siguen sin probarse y no deben describirse como verificados.
• Evidencia: docs/dns-e2-run.md y tests/recipes/dns-25.12-x86.md.
• Actualiza testedVersions y lastVerifiedAt cuando cambie el menú o la versión; no pongas comandos opkg de 24.10 en un procedimiento de 25.12.

Registro de pruebasEstado: Reproducido en laboratorio (E2)

Entorno

PVE 9.2.2 con una sola NIC; VM 200 con OpenWrt 25.12.6; cliente DHCP en netns

Receta

tests/recipes/dns-25.12-x86.md

Fecha

2026-10-20

Resultado

DNS de la WAN 192.168.50.1 → 1.1.1.1 aplicado; el upstream defectuoso agotó el tiempo de espera; la recuperación funcionó; DNS DHCP del cliente 192.168.1.1, resolución correcta

Reproducido en laboratorio (E2); sin revisión independiente ni prueba en una red física. El E3 sigue necesitando hardware real.

Fuentes

• Configuración de DHCP y DNS en OpenWrt
• dnsmasq en OpenWrt
• Notas de la versión OpenWrt 25.12
• Gestor de paquetes apk de OpenWrt