Bloquear anuncios desde el DNS es una de las mejoras más agradecidas que puedes meter en una red doméstica. No arregla internet, tampoco hace milagros con YouTube o con todas las apps modernas, pero sí limpia bastante basura antes de que llegue a móviles, tablets, televisiones y cacharros que no admiten extensiones de navegador.
El problema es que se instala demasiado fácil.
Pones Pi-hole o AdGuard Home, cambias el DNS del router, ves el panel llenarse de consultas bloqueadas y te sientes razonablemente listo. A partir de ahí empiezan las pequeñas decisiones que importan más que el contenedor: dónde vive el DNS, quién lo respalda, qué pasa si reinicias el servidor, cómo resuelven los nombres internos, qué ve Tailscale, qué hacen los dispositivos IoT y cómo vuelves a internet si todo se tuerce.
He pasado por la fase de “esto lo arreglo con una Raspberry Pi”. También por la de meter DNS, reverse proxy, nombres internos y cacharreo de red en la misma máquina porque total, solo son contenedores. La conclusión es bastante poco glamourosa: el DNS doméstico tiene que ser aburrido. Si se vuelve interesante, normalmente es porque algo se ha roto.
Este es el diseño que usaría hoy para una casa real, con familia, servicios self-hosted y ganas de bloquear anuncios sin convertir cada mantenimiento en una caída de internet.
Qué quiero conseguir#
No busco una red perfecta. Busco una red que aguante el día a día.
Mis objetivos serían estos:
- bloquear anuncios y trackers a nivel DNS
- tener nombres internos previsibles para servicios del homelab
- poder resolver internet aunque el servidor principal esté apagado
- evitar que los dispositivos de casa dependan de un experimento
- mantenerlo lo bastante simple como para reconstruirlo en una tarde
El último punto pesa más de lo que parece. Si dentro de seis meses no recuerdas por qué añadiste una regla, por qué un cliente usa otro upstream o por qué el router reparte dos DNS distintos, el diseño ya te está cobrando intereses.
En mi caso separo mentalmente tres funciones: bloqueo DNS, nombres internos y resolución externa. Pi-hole y AdGuard Home sirven muy bien para la primera. Los nombres internos pueden vivir en el propio bloqueador, en el router o en un DNS más formal. La resolución externa puede ir a un proveedor público, al ISP o a Unbound.
La tentación es mezclarlo todo y llamarlo arquitectura. Yo prefiero poder explicar el flujo en una frase: los clientes preguntan al DNS local, el DNS local bloquea lo que toca, resuelve nombres de casa y manda el resto a upstreams fiables.
Si no puedo dibujarlo en una servilleta, probablemente me he pasado.
Pi-hole o AdGuard Home#
Pi-hole sigue siendo una opción muy sólida. Tiene comunidad, documentación, listas por todas partes y una interfaz que, aunque no sea preciosa, hace su trabajo. Me gusta para instalaciones donde quieres algo conocido, fácil de buscar y con mucho historial de uso doméstico.
AdGuard Home me gusta más como producto redondo. La interfaz es más cómoda, el manejo de clientes me parece más claro y trae soporte fácil para DNS-over-HTTPS y DNS-over-TLS hacia upstreams. También se siente menos envejecido cuando lo usas desde móvil.
No cambiaría un Pi-hole sano solo por aburrimiento. Ese es el tipo de decisión que en homelab parece productividad y muchas veces es procrastinación con logs. Si ya tienes Pi-hole funcionando, con reglas limpias y backups hechos, quédate ahí.
Si empezara desde cero, elegiría AdGuard Home para una casa normal. No porque Pi-hole sea peor, sino porque me parece más cómodo de administrar para el tipo de uso que tengo ahora: clientes por nombre, listas, rewrites, upstreams cifrados y una interfaz que no me da pereza abrir.
Lo que no haría es poner los dos activos a la vez sin un motivo claro. Tener Pi-hole y AdGuard Home con listas distintas, clientes distintos y respuestas distintas es una receta bastante buena para problemas intermitentes. Los problemas intermitentes tienen una cualidad preciosa: siempre parecen culpa de otra cosa.
Dónde colocaría el DNS#
No pondría el DNS principal en el servidor que reinicio para probar cosas. Parece obvio, pero es una de esas obviedades que se ignoran porque “solo será un momento”.
El DNS principal debería vivir en una pieza estable. Puede ser una Raspberry Pi con SSD, un mini PC pequeño, una VM en Proxmox con alta disponibilidad razonable o un contenedor en un host que no tocas cada dos días. No tiene que ser potente. Tiene que estar disponible.
Para una casa pequeña me gusta esta combinación:
- DNS principal en un mini PC o VM estable
- DNS secundario en el router, NAS o una segunda máquina pequeña
- upstream externo de emergencia documentado
- configuración exportada y guardada fuera del propio servidor
El DNS secundario no tiene que ser idéntico si eso complica demasiado. Puede ser una segunda instancia de AdGuard Home con la misma configuración exportada. Puede ser Pi-hole en otra máquina. Puede ser el router apuntando a un DNS público como respaldo. Lo importante es decidirlo antes de que el principal caiga.
Aquí hay un matiz importante: muchos routers reparten dos DNS por DHCP, pero los clientes no siempre los usan como tú imaginas. Algunos prueban el segundo si el primero no responde. Otros reparten consultas entre ambos. Otros cachean lo que les da la gana. Por eso no me gusta mezclar un DNS filtrado con uno sin filtrar como si nada. Si el segundo DNS es público, parte del tráfico puede saltarse el bloqueo incluso cuando el primero funciona.
Para bloqueo consistente, mejor dos DNS filtrados. Para resiliencia sencilla, acepto un DNS público como emergencia, sabiendo que perderé bloqueo durante una caída. En casa prefiero que internet funcione antes que ganar una pureza técnica que nadie me ha pedido.
Unbound: sí, pero con calma#
Unbound tiene buena prensa en homelabs porque suena a independencia. En vez de mandar todas las consultas a Cloudflare, Google o Quad9, resuelves tú mismo desde los servidores raíz. Eso reduce dependencia de un proveedor concreto y te enseña cómo funciona DNS desde dentro.
Lo uso con respeto, no con devoción.
Para una casa normal, un upstream fiable ya es suficiente. Quad9, Cloudflare, Control D, NextDNS o el DNS del ISP pueden funcionar bien según tus prioridades. Si quieres filtrado adicional de malware, Quad9 tiene sentido. Si quieres una configuración cómoda con perfiles, NextDNS es práctico. Si quieres aprender y no depender de un proveedor, Unbound es divertido y útil.
Lo que no haría es meter Unbound para luego olvidarme de que existe. Si el resolver local falla, va lento o responde raro, el culpable serás tú. No el proveedor externo.
Mi diseño preferido sería este:
| |
En AdGuard Home puedes configurar varios upstreams y modos de selección. En Pi-hole puedes apuntar a Unbound local y tener otro resolver si lo planteas con cuidado. Lo importante es probar qué ocurre cuando Unbound está caído. No basta con que el panel diga que está configurado.
La prueba buena es vulgar: paras Unbound, abres una web que no esté cacheada, miras logs y confirmas si hay salida o no. Si la casa se queda sin DNS, ya sabes lo que tienes. Mejor descubrirlo un martes por la tarde que un domingo con alguien intentando ver una serie.
Nombres internos sin pelea con .local#
El bloqueo de anuncios suele abrir la puerta al DNS interno. Ya que tienes un panel DNS, empiezas a crear nombres para servicios: nas, proxmox, homeassistant, vault, fotos, grafana. Tiene sentido. Lo que no tiene tanto sentido es hacerlo con cualquier dominio.
No usaría .local como dominio principal del homelab. Es tentador porque queda natural, pero .local está ligado a mDNS. En una red simple puede funcionar. En cuanto tienes VLANs, VPN, Tailscale, reverse proxy o clientes raros, empiezan las respuestas inconsistentes.
Prefiero home.arpa para nombres puramente domésticos o un subdominio de un dominio que controles, por ejemplo home.tu-dominio.com. La ventaja del subdominio propio es que encaja mejor si mezclas DNS interno y certificados. La ventaja de home.arpa es que está pensado para casa y no depende de comprar nada.
Elegiría una convención simple:
nas.home.arparouter.home.arpaha.home.arpavault.home.arpaproxy.home.arpa
No hace falta poner nombres preciosos. Hace falta que dentro de un año sepas qué es cada cosa. También evitaría exponer nombres internos que revelen demasiado si tienes capturas, logs o documentación pública. En el blog uso ejemplos genéricos por eso mismo.
DHCP: el punto donde se gana o se pierde#
Puedes tener el DNS perfecto y romperlo todo repartiendo mal DHCP.
El router suele ser quien entrega IP, puerta de enlace y DNS a los clientes. Si el router permite definir servidores DNS personalizados, ahí pondría las IPs de mis DNS internos. Si no lo permite, tienes tres opciones: usar DHCP en Pi-hole o AdGuard Home, cambiar de router o aceptar limitaciones.
No soy fan de mover DHCP fuera del router solo por capricho. Si el router hace DHCP bien, lo dejo. Si el router del operador es una caja cerrada que no permite nada serio, entonces sí tiene sentido que Pi-hole o AdGuard Home hagan DHCP. Pero eso convierte al DNS en una pieza todavía más crítica.
Mi regla: DHCP y DNS pueden vivir juntos si la máquina es estable y está bien respaldada. Si es un contenedor en el host donde hago pruebas, ni de broma.
También reservaría IPs para los servidores DNS. Nada de confiar en que “siempre coge la misma”. El DNS debe tener IP fija real o reserva DHCP clara. Si cambia, media casa empieza a mirar a una dirección muerta.
Listas de bloqueo: menos es más#
Al principio apetece añadir todas las listas que encuentras. Es una trampa.
Más listas no significan mejor bloqueo. Significan más falsos positivos, más dominios rotos y más tiempo persiguiendo por qué una app bancaria, una tele o una web de reservas no carga. En una red familiar, un falso positivo visible pesa más que diez trackers bloqueados de forma silenciosa.
Empezaría con listas conocidas y pocas. Mantendría una whitelist documentada. Y revisaría los bloqueos cuando alguien diga “esto no funciona”, sin convertir la conversación en una defensa filosófica del DNS limpio.
Hay dispositivos que son muy pesados. Smart TVs, móviles, apps de streaming y cacharros IoT pueden generar un volumen absurdo de consultas. Bloquear todo lo que parezca telemetría puede romper funciones raras. A veces compensa. A veces no.
La pregunta buena no es “cuánto puedo bloquear”. Es “qué puedo bloquear sin que la red se vuelva molesta”.
Backups de configuración#
Pi-hole tiene Teleporter. AdGuard Home tiene su configuración en ficheros y también se puede exportar de forma razonable. En ambos casos, quiero una copia fuera de la máquina.
No necesito un sistema enorme. Me basta con:
- exportación semanal de configuración
- copia en el NAS o repositorio privado
- nota breve con IPs, dominio interno y upstreams
- prueba de restauración cada cierto tiempo
Si el DNS principal muere, quiero levantar otro en media hora. No perfecto. Suficiente.
También guardaría una captura o texto con la configuración DHCP del router. Hay routers que son maravillosos hasta que tienes que recordar qué pantalla escondía los servidores DNS. El día que internet no funciona, navegar por una interfaz cutre desde el móvil no es precisamente el plan.
Mi arquitectura recomendada#
Para una casa con homelab pequeño, montaría esto:
| |
Si solo tienes una máquina, entonces haría algo más modesto:
| |
No bloquea de forma perfecta, pero evita que toda la casa caiga si reinicias el servidor. Para mí, en entorno familiar, ese compromiso es aceptable.
Si quieres consistencia total de bloqueo, monta dos DNS internos. Si quieres sencillez, acepta que el respaldo público saltará filtros. Lo que no haría es creer que una única instancia sin plan B es suficiente porque “nunca falla”. Falla. Todo falla justo cuando menos apetece.
Cómo lo probaría antes de darlo por bueno#
No considero terminado un DNS doméstico hasta probar fallos básicos.
Pruebas mínimas:
- reiniciar el DNS principal y ver si los clientes siguen navegando
- apagar Unbound y confirmar si hay fallback
- resolver un nombre interno desde LAN
- resolver el mismo nombre desde VPN si aplica
- probar móvil, portátil y tele
- comprobar logs cuando algo falla
- restaurar configuración en una segunda instancia
La tele es un buen detector de tonterías. Si los portátiles van bien pero la tele se queda tonta, algo tienes mal o demasiado agresivo. Los dispositivos domésticos no leen tus diagramas.
También revisaría qué pasa con IPv6. Muchas redes domésticas lo tienen a medias. Si tus clientes reciben DNS IPv6 del router o del operador, quizá estén saltándose tu DNS filtrado sin que lo notes. No hace falta desactivar IPv6 por sistema, pero sí entender quién reparte DNS en IPv4 e IPv6.
Lo que haría distinto si empezara hoy#
Empezaría por AdGuard Home o Pi-hole, no por Unbound. Primero bloqueo y visibilidad. Luego nombres internos. Luego respaldo. Después, si todavía tengo ganas, Unbound.
No mezclaría DNS con laboratorio. No pondría reglas sin anotar. No usaría .local para todo. No metería diez listas de bloqueo el primer día. Y no vendería a la familia que internet va mejor gracias al homelab hasta tener una forma clara de quitar el homelab de en medio.
Porque ese es el test definitivo: si apago el servidor principal, ¿la casa sigue pudiendo navegar?
Si la respuesta es no, no tienes una red doméstica sin anuncios. Tienes una red doméstica secuestrada por un contenedor útil.
Me gusta Pi-hole. Me gusta AdGuard Home. Me gusta Unbound cuando está bien entendido. Pero me gusta más poder reiniciar un servidor sin que nadie levante la cabeza desde el sofá para preguntar por qué no va internet.