El DNS de casa suele empezar como una tontería.
Pones Pi-hole o AdGuard Home para quitar anuncios, cambias el DNS en el router, ves que funciona y te vienes arriba. Luego añades cuatro nombres locales: nas.local, proxmox.local, homeassistant.local, grafana.local. Después llega Tailscale, un reverse proxy, algún servicio expuesto con HTTPS, una VLAN para IoT, otra para laboratorio y quizá un Unbound porque has leído que resolver tú mismo mola más.
Un día algo deja de resolver. O resuelve distinto según el dispositivo. O el móvil funciona por WiFi pero no por VPN. O Home Assistant ve dispositivos que el portátil no ve. O un contenedor intenta hablar con otro y acaba preguntando a un DNS externo por un nombre interno que no debería salir de casa.
Ahí descubres que el DNS no era una tontería. Era la fontanería.
Y como toda fontanería, solo recibe atención cuando huele mal.
mi regla: DNS aburrido, red feliz#
En un homelab doméstico, el DNS tiene que ser simple, predecible y fácil de reconstruir.
No me interesa montar una arquitectura preciosa si luego nadie en casa puede navegar cuando reinicio una VM. Tampoco quiero depender de magia repartida entre el router, Pi-hole, AdGuard, Unbound, Docker, Tailscale, el NAS y cuatro ficheros hosts olvidados.
Mi diseño ideal separa tres funciones:
- Bloqueo y panel cómodo para consultas domésticas.
- Resolución de nombres internos.
- Resolución externa estable.
Pi-hole y AdGuard Home encajan muy bien en la primera parte. Permiten bloquear dominios, ver consultas, crear reglas y entender quién pregunta qué. Para casa, esa visibilidad es oro.
Los nombres internos deberían vivir en un sitio claro. Puede ser el propio Pi-hole, AdGuard Home, el router si es decente o un DNS más formal si el homelab ya tiene tamaño. Lo importante es no repartir nombres a mano por todos lados.
La resolución externa puede ir a servidores públicos, al ISP o a Unbound como resolver recursivo local. Unbound está bien, pero no lo metería solo para sentirme más puro. Si lo uso, tiene que aportar algo real y no convertirse en otra pieza opaca.
Pi-hole o AdGuard Home#
Pi-hole es el clásico. Lleva años funcionando, tiene mucha comunidad y hace bien lo que promete. Si quieres bloqueo DNS, listas, panel sencillo y documentación por todas partes, sigue siendo una opción muy razonable.
AdGuard Home me gusta porque se siente más moderno en algunas cosas. La interfaz es cómoda, el manejo de clientes es agradable y para muchas casas resulta más directo. También integra bien DNS-over-HTTPS y DNS-over-TLS si quieres jugar con eso.
No creo que haya un ganador universal. Los dos sirven. La decisión debería depender menos de internet discutiendo y más de cómo lo vas a mantener.
Si ya tienes Pi-hole funcionando y sabes dónde están tus reglas, no cambiaría por aburrimiento. Si empiezas desde cero y quieres una experiencia algo más pulida, probaría AdGuard Home. Si gestionas varias redes o quieres más control fino, miraría con calma cómo cada uno trata clientes, upstreams, rewrites y logs.
Lo que no haría es poner ambos activos sin una razón clara. Tener dos DNS domésticos con reglas distintas es una forma elegante de fabricar problemas intermitentes. Y los problemas intermitentes son los peores, porque siempre parecen culpa de otra cosa.
Unbound: útil, pero no obligatorio#
Unbound como resolver local tiene encanto. En vez de enviar todas tus consultas a un DNS público, tu servidor pregunta siguiendo la cadena DNS. Puede mejorar privacidad frente a un proveedor único y te da control local. También puede cachear respuestas.
Pero conviene bajar el entusiasmo.
Para una casa normal, usar un upstream fiable ya resuelve el problema. Cloudflare, Quad9, Google, el ISP o el que prefieras. No hace falta convertir cada consulta DNS en una declaración filosófica.
Unbound merece la pena si quieres aprender, reducir dependencia de un proveedor concreto o tener una capa propia bien entendida. No merece la pena si lo vas a instalar, copiar una configuración de internet y olvidarte de que existe.
También hay que entender una cosa: Unbound no arregla un mal diseño interno. Si tus clientes no llegan bien al DNS, si el DHCP reparte servidores distintos, si tus dominios locales están duplicados o si usas .local para todo, Unbound no te salva. Solo añade otra habitación al laberinto.
Mi enfoque sería: primero Pi-hole o AdGuard Home estable. Luego nombres internos ordenados. Luego, si apetece y tiene sentido, Unbound detrás.
el problema de .local#
.local parece perfecto para casa. Es corto, fácil y queda natural. El problema es que .local está asociado a mDNS, no a tu DNS interno clásico.
mDNS funciona muy bien para descubrir dispositivos en la misma red local. Impresoras, altavoces, algunos servicios domésticos y cacharros varios lo usan. Pero no está pensado para ser el dominio oficial de tu homelab con varias VLANs, VPN, reverse proxy y servicios que tienen que resolver de forma consistente.
Cuando usas nombres tipo servidor.local, puedes entrar en una zona gris. Algunos dispositivos preguntan por mDNS. Otros preguntan al DNS normal. Otros cambian de comportamiento según sistema operativo, red o estado de ánimo, que en informática doméstica a veces parece una variable real.
Por eso prefiero no usar .local como dominio interno principal.
Usaría algo como home.arpa, que está reservado para redes domésticas, o un subdominio de un dominio que controles, por ejemplo home.tu-dominio.com. Si tienes un dominio propio, un subdominio interno te da mucho margen. Puedes tener DNS interno para casa y DNS público solo para lo que quieras exponer.
Lo importante es elegir uno y ser consistente.
DHCP: el sitio donde se gana o se pierde media batalla#
El DNS doméstico se rompe muchas veces en el DHCP.
Si el router reparte un DNS, una VLAN reparte otro, Tailscale mete el suyo, Docker usa otro y el portátil conserva uno antiguo, luego no hay manera humana de razonar qué está pasando.
La pregunta básica es: ¿qué DNS recibe cada cliente?
En una casa simple, el router puede repartir como DNS la IP de Pi-hole o AdGuard Home. Ese servidor filtra, resuelve nombres internos y manda el resto hacia fuera. Fácil.
Si tienes VLANs, la cosa cambia. Puede que quieras que IoT use el DNS filtrado pero no pueda llegar a servicios internos. Puede que laboratorio resuelva nombres distintos. Puede que invitados solo usen DNS externo. Todo eso está bien, pero tiene que estar escrito en algún sitio.
Yo evitaría que los clientes puedan saltarse el DNS interno si la red depende de él. No por obsesión de control, sino porque algunos dispositivos ignoran el DHCP y usan DNS propios. Para bloqueo de anuncios es molesto. Para nombres internos puede ser directamente confuso.
También pondría IP fija o reserva DHCP al servidor DNS. Parece una obviedad, pero el día que el DNS cambia de IP y media red sigue apuntando a la antigua, te acuerdas.
nombres internos: menos creatividad, más orden#
Los nombres internos deberían ser aburridos.
proxmox.home.arpa, nas.home.arpa, ha.home.arpa, dns.home.arpa, router.home.arpa. No hace falta bautizar cada máquina como si fuera una nave espacial si luego tienes que recordar dónde vive cada cosa.
A mí me gusta separar nombres de máquinas y nombres de servicios.
Una máquina puede llamarse nodo1.home.arpa. Un servicio puede llamarse paperless.home.arpa. Si Paperless se mueve a otra VM, el nombre del servicio no cambia. Esto parece una tontería hasta que empiezas a mover cosas entre Proxmox, Docker, NAS y Kubernetes.
Para servicios con HTTPS, intentaría usar nombres que luego pueda cubrir con certificados de forma limpia. Un wildcard interno con un dominio propio puede simplificar mucho. Si no quieres complicarte, al menos no mezcles nombres imposibles, IPs directas y accesos distintos según el día.
Lo que evitaría es llenar cada cliente de entradas en /etc/hosts. Sirve para salir de un apuro. Como estrategia, envejece fatal.
Tailscale, VPN y DNS partido#
Cuando entra una VPN mesh como Tailscale, el DNS se vuelve más interesante.
Puedes querer que desde fuera de casa se resuelvan nombres internos. Puedes querer que solo algunos dispositivos usen el DNS de casa. Puedes querer acceder a servicios por nombres bonitos sin exponerlos a internet. Todo eso es posible, pero hay que decidirlo.
El error típico es activar MagicDNS, poner un DNS interno, añadir dominios de búsqueda y esperar que todo funcione igual desde dentro y desde fuera. A veces funciona. A veces no. Y cuando no, el fallo puede estar en Tailscale, en el cliente, en el DNS interno, en el firewall o en que el servicio realmente no escucha donde crees.
Mi forma de pensarlo es esta: dentro de casa, DNS interno normal. Fuera de casa, Tailscale puede enviar consultas de ciertos dominios al DNS de casa. Eso permite resolver home.arpa o un subdominio interno sin mandar todo el tráfico DNS por ahí.
Si necesito acceso crítico desde fuera, pruebo con móvil en datos, no desde la misma WiFi. Parece básico, pero todos hemos dado por bueno algo que solo funcionaba porque seguíamos dentro de la red.
alta disponibilidad doméstica para DNS#
El DNS es tan básico que apetece ponerlo en alta disponibilidad. Tiene sentido, pero sin pasarse.
Si tu único DNS vive en una VM y reinicias el nodo, la casa puede quedarse sin resolución. Quizá durante dos minutos. Quizá justo cuando alguien está viendo algo. La Ley de Murphy tiene buen gusto.
La solución sencilla es tener dos DNS internos. Por ejemplo, AdGuard Home en una VM principal y otro en una máquina pequeña, NAS o nodo secundario. El DHCP reparte ambos. Si cae uno, el otro responde.
Pero cuidado: dos DNS tienen que tener reglas sincronizadas o al menos una configuración parecida. Si cada uno responde distinto para nombres internos, vuelves al infierno intermitente.
Otra opción es dejar el router como DNS secundario para internet, pero entonces los nombres internos pueden fallar cuando el cliente salta al secundario. Depende de cuánto te importe.
Para una casa, me gusta tener un DNS principal con bloqueo y nombres internos, y un secundario simple que replique lo esencial. No hace falta montar una plataforma bancaria. Hace falta que reiniciar Proxmox no rompa YouTube, la domótica y el acceso al NAS.
cómo lo documentaría#
El DNS necesita documentación mínima. No una novela. Una página.
Apuntaría:
- Dominio interno elegido.
- Quién hace DHCP por cada red.
- Qué DNS recibe cada VLAN.
- Dónde viven los registros internos.
- Upstreams externos.
- Si hay Unbound, dónde está y cómo se comprueba.
- Qué pasa con Tailscale o VPN.
- Cómo levantar un DNS secundario si el principal muere.
Esta página vale más que muchas horas de debugging futuro. Porque el DNS se toca poco, pero cuando se toca suele ser en mal momento.
mi diseño recomendado#
Para una casa con homelab medio, montaría algo así:
- Dominio interno: home.arpa o subdominio propio.
- DHCP centralizado en router o firewall, no repartido al azar.
- AdGuard Home o Pi-hole como DNS principal.
- DNS secundario ligero en otro equipo.
- Rewrites o registros internos para servicios, no ficheros hosts sueltos.
- Unbound solo si quiero esa capa y la entiendo.
- Tailscale configurado para resolver solo el dominio interno cuando estoy fuera.
- .local reservado para mDNS y dispositivos que lo usan por su cuenta.
Con eso tienes una base sana. No perfecta, pero sana.
la conclusión práctica#
El DNS interno no es glamuroso. Nadie enseña capturas de una zona DNS ordenada como si fuera un rack nuevo. Pero cuando está bien hecho, todo lo demás parece más estable.
Pi-hole y AdGuard Home son buenas herramientas. Unbound puede tener sentido. Tailscale ayuda muchísimo. Pero la herramienta no compensa un diseño confuso.
Mi consejo sería empezar por lo aburrido: un dominio interno correcto, DHCP claro, registros centralizados, dos DNS si la casa depende de ello y una documentación corta. Si después quieres afinar privacidad, DoH, Unbound o split DNS más elegante, perfecto.
Primero que resuelva. Luego que sea bonito.