Configura Pi-hole o AdGuard Home: DNS Local para Sysadmins Linux
TL;DR — Lo que vas a tener al final
- Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
- Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
- Resultado: Servicio funcional y estable, documentado paso a paso.
- Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.
Por qué quieres un DNS local en 2026
El DNS recursivo de tu ISP entrega cada query a resolvers que registran tus visitas, venden datos a anunciantes y, en el mejor caso, no hacen nada raro. Un bloqueador DNS local corre en tu propia infraestructura (Raspberry Pi, mini-PC, LXC en el servidor del homelab) y filtra publicidad, trackers y dominios maliciosos antes de que la query salga de tu red. La diferencia: lo que el resto de tu casa hace con el celular, la smart TV o la consola queda cubierto sin instalar nada en cada dispositivo.
Ya cubrimos en Pi-hole vs AdGuard Home: comparativa honesta 2026 cuál de los dos proyectos te conviene según tu caso. Aquí vamos directo al plato: cómo instalar, configurar y dejar en producción un bloqueador DNS en Linux. Asumimos Debian 13 (Trixie) o Ubuntu 24.04 LTS como base, pero la receta funciona igual en Fedora 41+ y Arch.
Antes de empezar: qué necesitas
- Un servidor Linux con IP estática en la red local (ideal: 192.168.1.53 o similar)
- Acceso root o sudo sin contraseña (para editar
/etc/resolv.confy abrir el puerto 53) - Acceso al router para cambiar el DNS primario de la red
- 2 GB de RAM libres y 4 GB de disco (Pi-hole consume ~40 MB RAM, AdGuard Home ~80 MB)
- Docker + docker compose, OBLIGATORIO solo si vas por la opción contenerizada. La instalación nativa en systemd es perfectamente válida y recomendada para homelabs pequeños
Una nota importante sobre systemd-resolved: en Ubuntu 24.04 y Debian 12+ el resolver local (127.0.0.53) ocupa el puerto 53. Si vas a instalar Pi-hole o AdGuard Home de forma nativa, primero tienes que liberar el puerto o cambiar el resolver a 127.0.0.1 con cuidado. Más adelante en este artículo está el procedimiento exacto.
Opción 1: Pi-hole nativo (instalación clásica)
Pi-hole existe desde 2015 y sigue siendo la referencia para bloqueo DNS en homelabs. La instalación es un solo script que configura lighttpd, PHP-FPM, FTL (el daemon en C) y la base de datos SQLite. Nada mal para algo que corre en una Raspberry Pi Zero.
# Una sola línea, soporta Debian/Ubuntu/Fedora/Arch
curl -sSL https://install.pi-hole.net | bash
# Durante el wizard:
# - Upstream DNS: elige Quad9 (9.9.9.9) o Cloudflare (1.1.1.1) con DoH
# - Blocklists: deja las defaults (Steven Black + adsorption)
# - Web admin: yes
# - Lighttpd + PHP: yes (instala el stack completo)
# - Logging: yes (la query log es invaluable para debugging)
El instalador deja Pi-hole corriendo en http://<ip>/admin/ con password aleatoria que aparece al final. Guárdala y luego cámbiala desde la web. La configuración vive en /etc/pihole/: pihole-FTL.conf controla el daemon, setupVars.conf tiene los upstreams, y /etc/pihole/adlists.list es donde agregarás más listas de bloqueo después.
Para verificar que está escuchando y resolviendo:
# Verifica que el daemon responde
dig @127.0.0.1 soylinux.com +short
# Compara con un dominio bloqueado (debe devolver 0.0.0.0)
dig @127.0.0.1 doubleclick.net +short
# Salida esperada: 0.0.0.0
# Revisa estadísticas en vivo
pihole status
pihole -c -e # query log en vivo, útil para ver qué pide la smart TV a las 3 AM
Si dig @127.0.0.1 no responde, casi siempre es que systemd-resolved está ocupando el puerto 53. La solución limpia está en la sección de troubleshooting al final.
Opción 2: AdGuard Home nativo (instalación moderna)
AdGuard Home es el competidor más joven (2019) y trae cosas que Pi-hole todavía no tiene nativas: DoH y DoT salientes sin Cloudflared, filtrado por cliente (MAC o IP), interfaz responsive que sí funciona en el celular, y soporte oficial para parental control. Si tu red tieneChromebooks, smart TVs LG/Samsung y dispositivos IoT que pelean con el DNS, AdGuard Home suele ser menos fricción.
# Descarga el binario compilado (sustituye por la versión actual)
curl -sSL -o /tmp/agh.tar.gz
https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_amd64.tar.gz
tar -xzf /tmp/agh.tar.gz -C /opt
cd /opt/AdGuardHome
sudo ./AdGuardHome -s install # crea el unit file y arranca el servicio
# El primer arranque expone el wizard en http://<ip>:3000/
# Una vez configurado, el puerto de admin baja a 80 (o el que elijas)
# Cambia la interfaz de escucha a 0.0.0.0 si quieres administrarlo desde otra VLAN
AdGuard Home guarda su configuración en /opt/AdGuardHome/AdGuardHome.yaml (o donde lo configures). Es texto plano, perfecto para versionar en git y replicar entre servidores. Los archivos clave:
upstream_dns: resolvers externos. Usa DoH para cifrar la salida (https://dns.quad9.net/dns-query)filtering.json: listas de bloqueo, una por línea con URLsclients.json: reglas por IP o MAC (permite que el celular de tu hija use listas light, el server de la empresa use listas estrictas)
Para verificar:
# Test desde el server
dig @127.0.0.1 soylinux.com +short
# Test de cifrado DoH
curl -H "accept: application/dns-json"
"https://dns.quad9.net:5053/dns-query?name=example.com&type=A" | jq .
# Dashboard: http://&ip>/ (sin /admin/, distinto a Pi-hole)
Opción 3: Contenedor Docker (para LXC o VMs efímeras)
Si tu servidor ya corre Portainer, Yacht o Dockge, contenedorizar el bloqueador tiene sentido: configuración en compose, backups con el resto del stack, portabilidad entre servidores. La regla importante: el contenedor debe correr en red host (no bridge), porque necesita acceso directo al puerto 53 y al puerto 80/443 del host.
# /opt/pihole/docker-compose.yml
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
restart: unless-stopped
network_mode: host # <- CRÍTICO: red host para DNS en puerto 53
environment:
TZ: 'America/Montreal'
WEBPASSWORD: 'cambia-esto-a-algo-largo'
DNS1: '9.9.9.9'
DNS2: '149.112.112.112'
DNS_UPSTREAM: 'true' # Pi-hole usa los upstreams configurados en web admin
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq:/etc/dnsmasq.d'
logging:
driver: 'json-file'
options:
max-size: '10m'
max-file: '3'
Para AdGuard Home el compose es similar. Levanta y verifica:
docker compose up -d
sleep 5
dig @127.0.0.1 soylinux.com +short
# Si devuelve la IP real, el contenedor está resolviendo vía el host
Un detalle que se pasa por alto: cuando usas network_mode: host, el firewall de Docker NO aplica al contenedor. Eso es bueno para DNS, pero significa que el puerto 80/443 que expongas (la web admin) queda accesible desde la LAN. Si no quieres eso, cambia la red a bridge y mapea solo el 53, pero perderás la interfaz web salvo que pongas un reverse proxy delante.
Integración con el router y los dispositivos
El bloqueador solo es útil si los dispositivos de tu red lo usan. Hay tres formas de hacerlo, en orden de preferencia:
1. Cambiar el DNS en el router (cubre toda la red): entra a la administración del router, busca la sección LAN / DHCP / DNS, y cambia el DNS primario a la IP del bloqueador. El secundario déjalo en 1.1.1.1 o 9.9.9.9 (así si el bloqueador cae, internet sigue funcionando). En OpenWrt es Network > DHCP and DNS > DNS forwardings. En pfSense es Services > DNS Resolver > General Settings > DNS Query Forwarding.
2. DHCP estático por MAC: algunos routers (Ubiquiti, Mikrotik, OPNsense) permiten asignar DNS específico por MAC. Útil si quieres que la red IoT use el bloqueador pero la red de invitados use DNS directo para evitar problemas de compatibilidad con cast/streaming.
3. Configurar DNS por dispositivo (manual, no escalable): última opción. Útil solo para diagnóstico o para un equipo que no confía en el DNS del router.
Para validar que toda la red está usando el bloqueador, abre la web admin y revisa el panel Top Clients. Deberías ver todos los dispositivos de tu LAN. Si solo aparece el server, el router no está distribuyendo el DNS correcto o algún dispositivo tiene DNS hardcodeado (Chromecast y algunas smart TVs son famosos por esto).
Listas de bloqueo recomendadas para 2026
Las listas por defecto de Pi-hole y AdGuard Home son decentes pero dejan escapar bastante. Estas son las que mejor relación señal/ruido tienen en 2026, probadas en redes reales de 20-100 dispositivos:
| Lista | URL | Cobertura |
|---|---|---|
| Steven Black Unified | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts |
Ads + malware + fakenews (baseline, obligatoria) |
| AdGuard DNS Filter | https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt |
Trackers móviles y analytics avanzados |
| OISD (Full) | https://big.oisd.nl |
Dominios maliciosos y phishing actualizado diario |
| HaGeZi Multi Pro | https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/hosts/pro.txt |
Aggressive, falso positivos mínimos, LATAM-friendly |
| URLhaus | https://urlhaus.abuse.ch/downloads/hostfile/ |
URLs activas de distribución de malware |
Para Pi-hole, las pegas en /etc/pihole/adlists.list (una URL por línea) y luego corres pihole -g para descargar y compilar la base de datos de gravity. Para AdGuard Home, las pegas en Filters > DNS blocklists > Add blocklist > Add custom list desde la web.
Advertencia sobre listas grandes: HaGeZi Pro tiene ~700k dominios. Útil para tu red personal, pero si gestionas una red de 50+ personas (oficina, coworking) vas a romper sitios legítimos a diario. Empieza con Steven Black + OISD y solo agrega listas agresivas si tienes claro el costo de mantener falsos positivos.
Troubleshooting: cuando algo no funciona
systemd-resolved ocupa el puerto 53 y el bloqueador no arranca:
# Verifica quién está en el puerto
sudo ss -tlnp | grep :53
# Si es systemd-resolved, desactívalo
sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo "nameserver 9.9.9.9" | sudo tee /etc/resolv.conf
# En sistemas con Netplan (Ubuntu Server), también:
# /etc/netplan/01-netcfg.yaml -> dhcp4: no, nameservers: [9.9.9.9, 1.1.1.1]
sudo netplan apply
# Ahora sí: arranca el bloqueador
sudo systemctl start pihole-FTL # o AdGuardHome
El bloqueador corre pero los dispositivos siguen viendo publicidad:
- Verifica en la web admin que el cliente aparece en Top Clients. Si no está, el router no está entregando tu DNS como primario.
- Prueba desde el cliente con
nslookup example.com <ip-bloqueador>. Si responde, el problema es de configuración del router. Si no, es que el bloqueador no está accesible desde esa VLAN. - Revisa que no estés usando DNS over HTTPS directamente en el navegador (Firefox y Chrome lo permiten). Si el navegador sale por DoH, ignora tu bloqueador. La solución limpia: configura el bloqueador para que también haga DoH saliente y bloquea los DoH externos en el firewall.
Sitios legítimos bloqueados: el 80% son trackers de analytics o de chat en vivo. La solución: en Pi-hole Query Log > Whitelist el dominio exacto. En AdGuard Home, Filtering > Custom filtering rules > @@||dominio.com^. Para diagnosticarlo, abre la web admin en una laptop del cliente, navega al sitio que falla, y mira qué dominio aparece bloqueado en el log de los últimos 5 segundos.
Memoria o CPU excesiva: raro en homelabs. Si pasa, casi siempre es porque el log de queries está registrando millones de entradas. Configura rotación agresiva en pihole-FTL.conf: MAXDBDAYS=7 y FTL_DBFILE=/dev/shm/pihole-FTL.db (en RAM, no en SD si es Raspberry Pi).
¿Cuándo SÍ y cuándo NO?
Vale la pena cuando: tienes más de 5 dispositivos en la red, te molesta la publicidad en smart TV y consolas, gestionas un homelab, quieres logs de qué dispositivos hablan con qué servicios (útil para detectar C2 o exfiltración), o quieres DoH/DoT sin pagar un servicio comercial.
NO vale la pena cuando: vives solo con un celular y una laptop, toda tu navegación ya es por VPN con DNS propio, o usas Brave/Firefox con listas locales (uBlock Origin cubre el 95% de los casos en el navegador, el bloqueador DNS cubre los dispositivos donde no hay extensión posible).
Alternativas comerciales: NextDNS y ControlD ofrecen bloqueo DNS en la nube con panel web, sin servidor propio. Pierdes el control del log y dependes de un tercero, pero ganas no tener que mantener nada. Si tu única motivación es bloquear publicidad, probablemente NextDNS te da el mismo resultado con cero sysadmin.
Resumen
Un bloqueador DNS local en 2026 se instala en 10 minutos y cubre toda tu red en una hora. La elección entre Pi-hole y AdGuard Home es de gusto (recoge el comparativa que enlazamos arriba); ambos hacen el trabajo. Lo importante es tener uno y mantener las listas actualizadas: una lista de hace 12 meses deja escapar trackers nuevos que ya están en todas las webs.
Si tu red tiene más de 30 dispositivos o quieres reglas por cliente, ve directo a AdGuard Home. Si quieres simplicidad y una comunidad enorme, Pi-hole sigue siendo el camino.
Preguntas frecuentes
¿Por qué Configura Pi-hole o AdGuard Home: DNS Local para Sysadmins Linux es relevante para sysadmins Linux?
Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.
¿Qué necesito para empezar con Configura Pi-hole o AdGuard Home:?
Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.
¿Cuáles son los errores más comunes con Configura Pi-hole o AdGuard Home:?
Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.
¿Cuándo usar Configura Pi-hole o AdGuard Home: y cuándo una alternativa?
Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.
¿Cómo migro desde una configuración previa a Configura Pi-hole o AdGuard Home:?
Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.
Lee también
- Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
- Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
- Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
- Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
- Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
