Por qué alojar tu propio resolver DNS Pi-hole en un VPS
Un resolver DNS autoalojado en un VPS no está reservado a los homelabs. En cuanto operas múltiples contenedores y servicios en el mismo servidor, se convierte en un punto de control de red central: cada consulta DNS pasa por Pi-hole antes de llegar a internet, lo que te da visibilidad y control que los resolvers públicos no pueden ofrecer.
El argumento para un VPS frente a una Raspberry Pi local es simple. El VPS funciona 24/7, es accesible desde cualquier nodo de tu red Docker o de tu mesh VPN, y no depende de la disponibilidad de tu red doméstica. Para un desarrollador que administra varios servidores o trabaja en remoto, esta es la ubicación lógica.
Lo que Pi-hole aporta concretamente a una stack autoalojada
- Bloqueo a nivel de red: cada consulta hacia dominios de publicidad, rastreo o malware se bloquea antes de que se establezca la conexión TCP — para todos los contenedores de la red Docker, sin modificar cada aplicación.
- Logs DNS centralizados: un único dashboard muestra todas las consultas DNS de tu infraestructura, facilitando el debug de una aplicación que contacta un servicio externo inesperado.
- Reducción del ancho de banda: las consultas bloqueadas no generan ninguna respuesta de red. En un VPS con cuota de ancho de banda, es un ahorro medible para stacks con mucho tráfico.
- Privacidad de las consultas DNS: al combinar Pi-hole con Unbound como resolver recursivo local, tus consultas ya no pasan por un resolver de terceros — consultan directamente los servidores DNS autoritativos.
- Integración con la stack autoalojada: Pi-hole actúa como servidor DNS local para tus servicios, permitiéndote crear entradas DNS personalizadas (
grafana.miserv.local) sin modificar/etc/hostsen cada máquina. - Listas de bloqueo comunitarias: el ecosistema Pi-hole es uno de los más ricos en listas de bloqueo mantenidas — Hagezi, oisd, Steven Black — actualizadas automáticamente.
- Actualización v6 no disruptiva: Pi-hole v6 mantiene compatibilidad con los clientes v5; la migración no interrumpe el servicio.
Novedades de Pi-hole v6 — qué cambia para los self-hosters
Pi-hole v6 fue anunciado el 18 de febrero de 2025 en pi-hole.net. Es una reescritura mayor, no una actualización incremental.
Eliminación de PHP y lighttpd. La versión 5 usaba lighttpd como servidor web y PHP para la interfaz de administración. En v6, el binario pihole-FTL integra directamente un servidor web basado en Lua. Resultado: la imagen Docker es más ligera, no hay dependencias separadas que gestionar, y la superficie de ataque se reduce.
Nueva API REST nativa. La API v6 está documentada y versionada. Expone estadísticas, gestión de listas y configuración directamente desde http://<ip>/api/. En una stack Docker Compose, esto permite automatizar la gestión de Pi-hole desde un script o desde n8n sin necesidad de workarounds.
Variables de entorno FTLCONF_*. El esquema de configuración ha cambiado. La variable WEBPASSWORD de v5 es reemplazada por FTLCONF_webserver_api_password. Todas las opciones de configuración FTL ahora se exponen via variables FTLCONF_<sección>_<clave>, haciendo el docker-compose.yml autocontenido y legible.
Modo Basic / Expert. La interfaz v6 separa los ajustes esenciales (modo Basic) de las opciones avanzadas (modo Expert). Para un despliegue en VPS, el modo Expert da acceso al control de la interfaz de escucha DNS y a los parámetros de seguridad.
Antigravity (listas de permitidos por suscripción). Como espejo de Gravity para listas de bloqueo, Antigravity permite suscribirse a listas de permitidos mantenidas por la comunidad — útil para evitar falsos positivos en dominios legítimos.
Desde el lanzamiento de v6 en febrero de 2025, han seguido varias actualizaciones: FTL v6.5 en febrero de 2026, FTL v6.6 en abril de 2026, FTL v6.6.1 en abril de 2026 con correcciones de seguridad. La imagen Docker oficial está etiquetada como 2026.06.0 para la última release de junio de 2026.
Requisitos previos del VPS
Pi-hole v6 está diseñado para ser ligero. Los requisitos son notablemente inferiores a los de un SIEM o una stack de monitorización.
Recursos mínimos recomendados:
- 512 MB de RAM son suficientes para uso moderado (pocos contenedores, menos de 10.000 peticiones/hora). Prevé 1 GB para uso intensivo o si activas el historial extendido de consultas.
- 1 vCPU es suficiente. Pi-hole FTL es un proceso único y eficiente.
- 4 GB de disco mínimo para la imagen y las bases de datos de consultas.
- Acceso root al VPS para gestionar Docker y la configuración de red.
Puertos de red a considerar:
- 53/UDP y 53/TCP: puerto DNS. No exponer públicamente — esta es la regla más importante de esta guía.
- 80/TCP y 443/TCP: interfaz web de administración, a exponer solo detrás de un reverse proxy con autenticación.
Requisitos de software:
- Docker Engine 24.0+ y Docker Compose v2 (comando docker compose, sin guión).
- Sistema operativo: Debian 12 o Ubuntu 22.04/24.04 LTS.
Comprobación previa — puerto 53:
En Debian/Ubuntu recientes, systemd-resolved escucha en el puerto 53. Es la causa número uno de fallo en el primer arranque de Pi-hole. Verifica y desactiva si es necesario:
ss -tlunp | grep ':53'
systemctl disable --now systemd-resolvedSi desactivas systemd-resolved, asegúrate de que /etc/resolv.conf apunte a un resolver funcional mientras haces el despliegue:
echo 'nameserver 1.1.1.1' > /etc/resolv.confDespliegue de Pi-hole v6 con Docker Compose: procedimiento completo
Preparar el servidor e instalar Docker
Actualiza el sistema e instala Docker Engine desde el repositorio oficial:
apt-get update && apt-get upgrade -y curl -fsSL https://get.docker.com | sh docker --version && docker compose versionActiva Docker al arranque y verifica que Docker Compose v2 responde (el comando es
docker compose, sin guión):systemctl enable --now dockerCrear la estructura de directorios
Crea un directorio dedicado y volúmenes persistentes para la configuración y las bases de datos de Pi-hole:
mkdir -p /opt/pihole/etc-pihole cd /opt/piholeEstos directorios persisten la configuración FTL, las listas Gravity y el registro de consultas. Sin ellos, cada recreación del contenedor comienza desde cero.
Escribir el docker-compose.yml de Pi-hole v6
Crea
/opt/pihole/docker-compose.ymlcon la siguiente configuración. Nota el uso deFTLCONF_webserver_api_password(variable v6) yFTLCONF_dns_listeningModepara el adaptador al bridge network de Docker:services: pihole: container_name: pihole image: pihole/pihole:2026.06.0 ports: - "127.0.0.1:53:53/tcp" - "127.0.0.1:53:53/udp" - "127.0.0.1:8080:80/tcp" environment: TZ: 'Europe/Paris' FTLCONF_webserver_api_password: 'cambia-esta-contraseña' FTLCONF_dns_listeningMode: 'ALL' FTLCONF_dns_upstreams: '1.1.1.1;8.8.8.8' volumes: - './etc-pihole:/etc/pihole' cap_add: - SYS_NICE restart: unless-stoppedPunto crítico:
127.0.0.1:53vincula el puerto DNS a la interfaz loopback del host únicamente. El resolver es accesible desde el propio servidor y desde la red Docker interna, pero no desde Internet.Arrancar Pi-hole y verificar su estado
Lanza el contenedor en segundo plano y verifica que está
healthy:docker compose up -d docker compose ps docker compose logs pihole | tail -30En el primer arranque, Pi-hole descarga las listas Gravity (pocos segundos). La interfaz web está disponible en
http://127.0.0.1:8080/admindesde el propio servidor. Si vesPi-hole blocking is enabled, el despliegue funciona.Configurar el DNS en la red interna de Docker
Para que tus contenedores usen Pi-hole como resolver DNS, define
dnsen cada servicio de tus otras stacks Docker Compose, o configura el demonio Docker globalmente.Opción A — por servicio (recomendado para stacks existentes):
services: mi-app: image: mi-imagen dns: - 172.17.0.1172.17.0.1es la IP de la pasarela de la red bridge Docker por defecto, que corresponde a la interfaz del host donde escucha Pi-hole.Opción B — demonio Docker global (/etc/docker/daemon.json):
{ "dns": ["172.17.0.1", "1.1.1.1"] }Reinicia Docker tras la modificación:
systemctl restart docker. El segundo resolver1.1.1.1es un fallback si Pi-hole está parado.Exponer el dashboard vía un reverse proxy HTTPS
Nunca expongas el dashboard de Pi-hole directamente en el puerto 80 público. Usa nginx como reverse proxy con un certificado Let's Encrypt:
server { listen 443 ssl; server_name pihole.your-domain.com; ssl_certificate /etc/letsencrypt/live/pihole.your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/pihole.your-domain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Obtén el certificado con Certbot:
certbot --nginx -d pihole.your-domain.com. La autenticación de Pi-hole (contraseña definida enFTLCONF_webserver_api_password) sigue siendo la única puerta de entrada.Asegurar el resolver contra la exposición pública
Un resolver DNS abierto en Internet es un vector de amplificación DDoS y puede ser usado por cualquiera. Verifica que el puerto 53 no sea accesible desde el exterior.
Verificación desde una máquina remota:
nmap -sU -p 53 <IP_DE_TU_VPS>El puerto debe estar
filteredoclosed. Si estáopen, tu resolver es público.Cerrar el puerto 53 con ufw:
ufw deny 53/udp ufw deny 53/tcp ufw allow from 172.16.0.0/12 to any port 53La regla
allow from 172.16.0.0/12permite las redes Docker internas mientras bloquea el tráfico externo.Añadir listas de bloqueo y activar la actualización automática
La interfaz de Pi-hole v6 > Lists permite añadir listas por URL. Listas recomendadas tras la instalación:
- Hagezi Multi Pro:
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/pro.txt
- oisd Big:https://big.oisd.nl/
- Steven Black Unified:https://raw.githubusercontent.com/StevenBlack/hosts/master/hostsTras añadirlas, lanza una actualización de Gravity:
docker exec pihole pihole -gPara automatizar la actualización semanal, añade una entrada cron en el host:
0 3 * * 0 docker exec pihole pihole -g >> /var/log/pihole-gravity.log 2>&1
Configuración post-instalación
Una vez Pi-hole operativo y tus servicios apuntando a él, algunos ajustes aumentan su utilidad diaria.
DNS personalizados para servicios internos. En Pi-hole > Local DNS, puedes crear registros A que resuelvan nombres locales: grafana.local → 127.0.0.1, n8n.local → 127.0.0.1. Esto sustituye modificar /etc/hosts en cada máquina.
Ajustar el nivel de logging. Por defecto, Pi-hole conserva 24 horas del registro de consultas. Para extender a 7 días o reducir para limitar el uso de disco: en Settings > System, modifica la opción Query log. En un VPS con almacenamiento limitado, desactivar los logs detallados (manteniendo las estadísticas) es una opción viable.
Dashboard y estadísticas. El dashboard v6 muestra en tiempo real: el porcentaje de consultas bloqueadas, los dominios más solicitados, los clientes más activos. Estos datos son útiles para identificar un contenedor que realiza peticiones inusuales.
Lista blanca para falsos positivos. Algunas listas de bloqueo son agresivas y bloquean dominios legítimos. Pi-hole > Domains > Allow permite añadir excepciones sin tocar las listas. Comprueba si algún servicio interno deja de funcionar tras activar una nueva lista.
Pi-hole v6 vs AdGuard Home — comparativa 2026
Desplace la tabla
| Criterio | Pi-hole v6 | AdGuard Home |
|---|---|---|
| Arquitectura | Binario FTL con servidor web Lua integrado — sin PHP ni lighttpd desde v6 (febrero 2025) | Binario Go único, multiplataforma (Linux, Windows, macOS, OpenWrt, FreeBSD) |
| DNS cifrado (DoH/DoT/DoQ) | No integrado — requiere contenedor sidecar Unbound o cloudflared para DoH/DoT | Integrado de forma nativa — DoH, DoT y DoQ disponibles sin configuración adicional |
| Huella de memoria | ~70-150 MB en funcionamiento normal, según volumen de consultas e historial activado | ~50-100 MB; algo más ligero en configuraciones simples sin historial extendido |
| Comunidad y listas | Ecosistema más amplio: cientos de listas compatibles (formato hosts y adblock), foros activos, documentación extensa | Compatible con listas en formato adblock (uBlock Origin); ecosistema en crecimiento pero más joven |
| API y automatización | API REST nativa documentada en v6; gestión completa vía variables `FTLCONF_*` | API REST disponible; configuración vía archivo YAML o interfaz web |
| Reglas por cliente | Filtrado por cliente (IP o nombre de red), sin reglas nativas granulares por dispositivo | Reglas por cliente y por grupo de forma nativa, controles parentales integrados |
Hardening: reglas que no hay que ignorar
Nunca expongas el puerto 53 públicamente. Este es el principal riesgo de un resolver DNS en un VPS. Un puerto 53 abierto permite a cualquiera usar tu servidor como resolver — y potencialmente como vector de amplificación DNS en un ataque DDoS. Comprueba regularmente con nmap -sU -p 53 <IP_VPS> desde el exterior.
Cambia la contraseña por defecto. La variable FTLCONF_webserver_api_password en el Compose debe contener una contraseña fuerte. Si la omites, Pi-hole genera una contraseña aleatoria y la muestra en los logs en el primer arranque — conveniente para pruebas, inaceptable en producción.
Actualiza la imagen regularmente. Las releases de Pi-hole v6 en 2026 incluyeron correcciones de seguridad (vulnerabilidad de escalada de privilegios local en abril de 2026, correcciones XSS en la interfaz web). Añade una verificación periódica:
docker compose pull && docker compose up -dSin DHCP en producción en un VPS. La función DHCP de Pi-hole está diseñada para redes locales. En un VPS no tiene utilidad, y activarla accidentalmente (cap_add: NET_ADMIN) puede crear conflictos de red con la infraestructura del host.
Solución de problemas: errores habituales
Estos son los problemas más frecuentes al desplegar Pi-hole v6 en un VPS, con causas exactas y soluciones.
1. El puerto 53 ya está en uso — bind: address already in use
Causa: systemd-resolved escucha en 127.0.0.53:53. Comprueba con ss -tlunp | grep ':53'. Solución: desactiva systemd-resolved (systemctl disable --now systemd-resolved) y reemplaza /etc/resolv.conf con un archivo estático apuntando a 1.1.1.1 durante el despliegue.
2. Las consultas DNS de los contenedores no pasan por Pi-hole
Causa: los contenedores usan el resolver predeterminado de Docker (127.0.0.11), no Pi-hole. Verifica desde un contenedor: docker exec <contenedor> cat /etc/resolv.conf. Si muestra 127.0.0.11, la opción dns: no está configurada en tu Compose o en /etc/docker/daemon.json.
3. Dashboard inaccesible tras el arranque
Causa habitual: el puerto 8080 está vinculado a 127.0.0.1 (no accesible desde el exterior) pero el reverse proxy aún no está configurado. Comprueba localmente: curl http://127.0.0.1:8080/admin/. Si responde, el problema está en el reverse proxy o el certificado TLS.
4. FTLCONF_webserver_api_password ignorada tras recrear el contenedor
Causa: Pi-hole almacena la configuración en /etc/pihole/pihole.toml. Si este archivo ya existe en el volumen ./etc-pihole con una contraseña antigua, la variable de entorno no lo sobreescribe. Solución: eliminar el archivo pihole.toml (pérdida de config) o cambiar la contraseña desde la interfaz web.
5. Fallo en la actualización de Gravity — Could not access the internet
Causa: el contenedor Pi-hole no puede resolver las URLs de las listas, generalmente porque FTLCONF_dns_upstreams no está configurado o el contenedor usa Pi-hole como su propio resolver (bucle). Verifica que FTLCONF_dns_upstreams apunte a un resolver externo (1.1.1.1;8.8.8.8) en tu Compose.
Integrar Pi-hole en tu stack de seguridad
Pi-hole es una capa de filtrado DNS, no un sistema de detección de intrusiones. Su alcance es preciso: actúa sobre las consultas de nombres de dominio antes de que se establezca la conexión. Complementa otras herramientas en lugar de reemplazarlas.
Combinado con Wazuh o CrowdSec, Pi-hole gestiona el filtrado preventivo mientras las otras herramientas analizan el comportamiento de red y del sistema en tiempo real. Un contenedor comprometido que contacta un dominio de command-and-control conocido será bloqueado por Pi-hole — y la ausencia de respuesta DNS puede disparar una alerta en Wazuh si has configurado la monitorización de logs de Pi-hole.
Combinado con NetBird o WireGuard, Pi-hole puede convertirse en el resolver DNS de toda tu red mesh VPN privada. Cada dispositivo conectado a la VPN se beneficia entonces del filtrado, incluso desde un puesto de trabajo remoto.
Para alojar Pi-hole en un VPS con acceso root completo, IPv4 dedicada y Docker preinstalado, consulta los planes VPS de ServOrbit. Pi-hole v6 funciona cómodamente en el plan de entrada — los recursos consumidos son modestos y dejan espacio para el resto de tu stack.
Artículos relacionados: actualizaciones de seguridad automáticas en VPS Debian/Ubuntu, red VPN mesh sin puertos abiertos con NetBird, Wazuh SIEM open source en VPS.
