Problema

En muchos homelabs se configura pfSense como router/DHCP‑server y se delega un dominio interno (por ejemplo *.lan) para que los dispositivos accedan a recursos como SMB shares mediante nombres amigables (smb://servidor.lan). Cuando el servidor de almacenamiento es TrueNAS y se le asigna un hostname estático (slab), la resolución DNS suele funcionar sin problemas. Sin embargo, es frecuente que, sin intervención aparente, los nombres dejan de resolverse y sólo se accede a los recursos mediante la dirección IP (192.168.x.x). El síntoma típico es:

  • ping slab.lan o smb://slab.lan falla.
  • Acceso a la UI de TrueNAS funciona solo por IP.
  • Otros equipos en la LAN siguen obteniendo direcciones IP correctas del DHCP de pfSense.

Este tipo de interrupción afecta a cualquier servicio que dependa de nombres internos (Plex, backups, scripts) y suele generar confusión porque la configuración visible no ha cambiado.

Causa

Los fallos de DNS interno en un entorno pfSense‑TrueNAS pueden originarse en varios puntos:

  1. Entrada DNS desaparecida o sobrescrita

    • pfSense usa DNS Resolver (unbound) o DNS Forwarder (dnsmasq). Si la entrada está configurada como “Host Override” y el DHCP lease de TrueNAS se renueva, la regla puede ser eliminada automáticamente.
    • En TrueNAS, la opción “Inherit domain from DHCP” puede crear un segundo registro slab.lan que compite con el de pfSense.

  2. Conflicto entre mDNS/Avahi y el dominio .lan

    • TrueNAS y algunos clientes publican su hostname vía mDNS (slab.local). Si el router no reenvía o bloquea paquetes multicast, los clientes que dependen de mDNS pierden la resolución mientras que el DNS tradicional sigue sin registro.

  3. DHCP estático vs. dinámico

    • Si la IP del servidor se asigna dinámicamente y cambia, el registro DNS estático queda desfasado. La mayoría de los problemas aparecen justo después de un reinicio del servidor o del router.

  4. Reglas de firewall que bloquean el puerto 53 interno

    • pfSense, por defecto, permite tráfico DNS solo desde la LAN a la WAN. Una regla restrictiva o un Alias mal configurado puede impedir que los clientes consulten el resolver interno.

  5. Cache del resolver

    • Un TTL expirado o una entrada corrupta en la caché de unbound/dnsmasq puede servir una respuesta negativa indefinidamente. Reiniciar el servicio suele “curar” el problema, pero la causa raíz sigue latente.

Solución

1. Verificar que el hostname está registrado en pfSense

  1. Accede a Services → DNS Resolver (o DNS Forwarder).
  2. En la pestaña Host Overrides, crea o revisa una entrada para el servidor:
    • Host: slab
    • Domain: lan
    • IP address: la IP estática que deseas usar (ej. 192.168.0.10).
    • Guardar y aplicar cambios.

Si prefieres que pfSense genere la entrada automáticamente, habilita DHCP static mapping:

  • Services → DHCP Server → LAN → DHCP Static Mappings
  • Añade una nueva mapping con la MAC de la NIC de TrueNAS, asigna la IP deseada y escribe slab.lan en Hostname.

2. Asegurar que la IP del servidor sea estática

En TrueNAS, desactiva la obtención automática de IP y configura una IP estática dentro del rango de la LAN, fuera del pool DHCP. Esto elimina la posibilidad de que el lease cambie y rompa la entrada DNS.

3. Desactivar o redirigir mDNS si genera conflicto

  • En pfSense, ve a Services → Avahi (si está instalado) y habilita “Enable mDNS repeater” para que los paquetes multicast atraviesen la LAN.
  • Alternativamente, desactiva mDNS en TrueNAS (Servicios → Network → Avahi) si no lo necesitas.

4. Revisar firewall y reglas de NAT

  • En Firewall → Rules → LAN, asegúrate de que exista una regla que permita tráfico UDP/TCP 53 desde cualquier host LAN al IP de pfSense (usualmente 127.0.0.1 o la IP del router).
  • Si usas Aliases para “LAN_NET”, verifica que la regla incluya ese alias.

5. Limpiar la caché del resolver

# En pfSense (Shell)
service unbound restart   # para DNS Resolver
# o
service dnsmasq restart   # para DNS Forwarder

6. Validar la resolución desde varios clientes

  • En Windows: nslookup slab.lan 192.168.0.1
  • En Linux/macOS: dig @192.168.0.1 slab.lan

Si la respuesta muestra la IP correcta, el problema está resuelto.

7. Automatizar la consistencia

Añade un cron en TrueNAS o en pfSense que verifique que la IP del servidor coincide con la entrada DNS:

# En pfSense (Shell)
while true; do
  ip=$(ifconfig em0 | grep inet | awk '{print $2}')
  current=$(unbound-control lookup slab.lan | grep -oP '\d+\.\d+\.\d+\.\d+')
  if [ "$ip" != "$current" ]; then
    echo "IP mismatch, updating host override..."
    # comando para actualizar host override vía API o UI
  fi
  sleep 300
done

Este fragmento es opcional, pero evita que un reboot inesperado vuelva a romper la resolución.

Cuándo aplicar esta solución

  • Síntomas: nombres internos (*.lan) no se resuelven, solo IP funciona, los logs de pfSense muestran “NXDOMAIN” para el hostname del servidor.
  • Entorno: pfSense como router/DHCP, dominio interno .lan, al menos un servidor TrueNAS o similar que ofrece SMB/NFS.
  • No aplica: si el problema está en la WAN (p. ej., DNS externo caído) o si los clientes usan exclusivamente mDNS sin dominio .lan. En esos casos, la solución radica en la configuración del cliente, no del router.

Verificación

  1. Ping: ping slab.lan debe responder con la IP estática.
  2. SMB: en el explorador de archivos, escribe smb://slab.lan y verifica que la lista de shares aparece sin necesidad de IP.
  3. Plex: añade la ruta smb://slab.lan/ShareName y comprueba que Plex indexa los archivos.
  4. Logs: en Status → System Logs → DNS Resolver, busca entradas exitosas para slab.lan. No debe haber “NXDOMAIN”.

Si todos los pasos anteriores funcionan, la solución está completa.

Notas adicionales

  • TTL bajo: establece un TTL de 60 s en el host override para que los cambios se propaguen rápidamente en caso de futuros ajustes.
  • Respaldo de configuración: exporta la configuración de pfSense (Diagnostics → Backup & Restore) antes de modificar DNS Resolver/Forwarder.
  • Separar dominios: si utilizas varios sub‑dominios (lab.lan, media.lan), crea un Domain Override en pfSense apuntando a un servidor DNS interno (por ejemplo, el propio TrueNAS con dnsmasq) para evitar sobrecargar el resolver del router.
  • Monitorización: añade una alerta en Monit o Zabbix que verifique la resolución de slab.lan cada 5 min; un fallo disparará una notificación antes de que los usuarios noten el problema.

Con estos pasos, la resolución DNS interna en un homelab con pfSense y TrueNAS pasa de ser intermitente a ser predecible y fácil de mantener.