Problema

En entornos domésticos o de pequeña oficina es frecuente delegar la resolución de nombres internos a un Pi‑hole instalado en un contenedor LXC. El objetivo es que cualquier dispositivo que consulte DNS obtenga tanto la filtración de publicidad como los registros locales (por ejemplo test.lan). Cuando los dispositivos siguen enviando consultas al router y el router reenvía a un servidor externo (Cloudflare, Google), los nombres internos no se resuelven y el navegador muestra “server IP address could not be found”. El síntoma típico es:

  • nslookup test.lan devuelve NXDOMAIN usando el DNS configurado por DHCP (p.ej. 1.1.1.1).
  • nslookup test.lan 192.168.0.115 (IP del Pi‑hole) devuelve la IP esperada.
  • Los logs de Pi‑hole muestran consultas desde los dispositivos, pero esas consultas provienen de la IP del router, no del cliente directo.

El problema no es la falta de registro en Pi‑hole; es que los clientes no están utilizando Pi‑hole como resolutor para los dominios locales.

Causa

Varias configuraciones pueden romper la cadena de resolución:

  1. DHCP del router no entrega la IP del Pi‑hole
    Muchos routers ignoran la opción “DNS primary” cuando también se habilita “DNS forwarding” o cuando el router tiene su propio servidor DNS interno. El cliente termina usando el DNS público (1.1.1.1) que no conoce los dominios .lan.

  2. Pi‑hole en LXC no escucha en la interfaz correcta
    Por defecto Pi‑hole escucha en 127.0.0.1. En contenedores, esa dirección solo es accesible desde dentro del contenedor. Si no se ha añadido 0.0.0.0 o la IP de la red LXC al archivo dnsmasq.d/01-pihole.conf, las peticiones externas son descartadas.

  3. Reglas de firewall / iptables en el host o en el contenedor
    Un filtro que bloquee el puerto 53 UDP/TCP desde la LAN impide que los clientes alcancen el servicio DNS del contenedor.

  4. Router configurado con DNS secundario externo
    Cuando el router intenta resolver un nombre que no está en su caché, envía la consulta al DNS secundario (8.8.8.8). Si la respuesta es NXDOMAIN, el cliente nunca vuelve a preguntar a Pi‑hole, incluso si Pi‑hole tiene un registro local.

  5. Cliente con DNS estático o caché
    Algunos dispositivos (Android, iOS) pueden mantener una caché de DNS o usar DNS over TLS/HTTPS hacia un servidor externo, ignorando la configuración DHCP.

Solución

1. Verificar que el router entregue la IP del Pi‑hole

  • Accede a la interfaz DHCP del router.
  • Desactiva cualquier opción “DNS relay” o “DNS proxy”.
  • Configura explícitamente DNS primary = 192.168.0.115 (IP del contenedor) y DNS secondary = 8.8.8.8 (opcional).
  • Guarda y reinicia el servicio DHCP o los clientes.

2. Asegurar que Pi‑hole escuche en la red LXC

Edita el archivo de configuración de dnsmasq dentro del contenedor:

nano /etc/dnsmasq.d/01-pihole.conf

Asegúrate de que exista una línea como:

interface=eth0
listen-address=127.0.0.1,192.168.0.115

Reinicia el servicio:

pihole restartdns

3. Comprobar reglas de firewall

En el host Proxmox y dentro del contenedor verifica que el puerto 53 esté abierto:

# En el host
iptables -L -n | grep 53

# En el contenedor
nft list ruleset | grep 53

Si falta la regla, añádela:

iptables -I INPUT -p udp -s 192.168.0.0/24 --dport 53 -j ACCEPT
iptables -I INPUT -p tcp -s 192.168.0.0/24 --dport 53 -j ACCEPT

4. Forzar la resolución local antes de la externa

Pi‑hole permite definir “Conditional Forwarding”. En la UI, ve a Settings → DNS → Conditional Forwarding y habilita:

  • Domain: lan (o el dominio que uses).
  • IP address of your router: 192.168.0.1.
  • Local network: 192.168.0.0/24.

Esto hace que cualquier consulta que no coincida con un registro local se envíe al router, evitando que el cliente recurra directamente a 8.8.8.8.

5. Eliminar caché y forzar uso de Pi‑hole en los clientes

En dispositivos Linux/macOS:

sudo systemd-resolve --flush-caches
sudo resolvectl dns eth0 192.168.0.115

En Android/iOS, desactiva “Private DNS” y reinicia la conexión Wi‑Fi.

6. Validar la cadena de resolución

Desde un cliente, ejecuta:

nslookup test.lan

La salida debe mostrar Server: 192.168.0.115 y la IP configurada. Si sigue apareciendo 1.1.1.1, revisa la tabla DHCP del router para confirmar que la opción DNS está siendo entregada.

Cuándo aplicar esta solución

  • Síntomas: dominios locales no se resuelven, nslookup usa DNS público, pero Pi‑hole muestra consultas entrantes.
  • Entorno: Pi‑hole en contenedor LXC/ Docker, router que gestiona DHCP, red LAN 192.168.x.x.
  • No aplicar: si el problema es exclusivamente de resolución externa (p.ej. bloqueos de ISP) o si el router ya está configurado como forwarder a Pi‑hole y los clientes usan DNS sobre TLS que ignora la configuración DHCP.

Código

# 1. Editar configuración de escucha
sed -i 's/^listen-address=.*/listen-address=127.0.0.1,192.168.0.115/' /etc/dnsmasq.d/01-pihole.conf

# 2. Reiniciar DNS
pihole restartdns

# 3. Abrir puertos en firewall del host
iptables -I INPUT -p udp -s 192.168.0.0/24 --dport 53 -j ACCEPT
iptables -I INPUT -p tcp -s 192.168.0.0/24 --dport 53 -j ACCEPT

# 4. Forzar DNS en un cliente Linux (ejemplo)
sudo resolvectl dns eth0 192.168.0.115
sudo resolvectl domain eth0 ~.

Verificación

  1. Comprobación de DHCP

    • En un cliente, ejecuta cat /etc/resolv.conf (Linux) o revisa la configuración de DNS en la UI del dispositivo. La primera línea debe ser nameserver 192.168.0.115.

  2. Prueba de resolución

    • nslookup test.lan → Server: 192.168.0.115 y la IP esperada.
    • dig +short test.lan @192.168.0.115 → IP del host interno.

  3. Logs de Pi‑hole

    • En la UI, la consulta debe aparecer bajo “Query Log” con la IP del cliente (no la del router).
    • Si sigue apareciendo la IP del router, revisa la opción “Conditional Forwarding” y la configuración del router.

  4. Acceso a servicios

    • Navega a http://test.lan o http://test2.lan. La página debe cargar a través de Nginx Proxy Manager o directamente al servidor Apache.

Notas adicionales

  • Cuando Pi‑hole se ejecuta en LXC, el contenedor comparte la interfaz de red del host. Si cambias la IP del contenedor, actualiza tanto la configuración DHCP del router como la línea listen-address en dnsmasq.
  • Algunos routers sobrescriben la opción DNS si detectan que el servidor responde con NXDOMAIN para dominios desconocidos. Configurar “Conditional Forwarding” evita ese comportamiento.
  • Si utilizas IPv6 en la red, añade la dirección IPv6 del contenedor a listen-address y verifica que el router entregue la opción DNS6.
  • En entornos con varios routers o puntos de acceso, asegúrate de que todos entreguen la misma IP de DNS; de lo contrario, los dispositivos pueden alternar entre resolutores y perder la resolución local.