Por ejemplo, nosotros hemos instalado vía Docker el conocido  Pi‑hole, porque —aunque parezca mentira— todavía no lo habíamos puesto en marcha en ninguno de nuestros sistemas. Y este NAS, que va a estar encendido prácticamente todo el tiempo y cuyo consumo adicional es insignificante, es el lugar perfecto para hacerlo. Conviene recordar que Pi‑hole actúa como un filtro DNS inteligente, bloqueando publicidad, rastreadores y dominios maliciosos antes siquiera de que lleguen a nuestros dispositivos, lo que mejora la privacidad y acelera la navegación. Por todo ello, este parece el mejor momento para probarlo a fondo antes de desplegarlo también en nuestro domicilio madrileño.

A nivel de router lógicamente es necesario redirigir todas las peticiones de DNS al Pi-hole. En el caso de que el NAS estuviese apagado las peticiones irían de forma automáticva al segundo DNS (1.1.1.1 de Cloudfare).

Para no alargar esta revisión hasta el infinito y más allá, hemos creado en GitHub un repositorio con todos los ficheros de configuración, ejemplos, datos y resultados que estamos utilizando en esta prueba. De este modo, cualquier lector interesado puede consultar, descargar o adaptar nuestras configuraciones sin tener que rebuscar entre capturas o fragmentos sueltos.

Por ejemplo, aquí tenéis acceso a la configuración del docker‑compose optimizado para funcionar en este NAS de UGREEN. Conviene recordar que UGREEN utiliza lo que ellos llaman Proyectos, un sistema que no funciona mal, pero que complica un poco la vida a los puristas que preferimos herramientas “genéricas” como docker‑compose. Aun así, con un par de ajustes, todo encaja y funciona como debe.

Por otra parte, conviene mencionar un detalle importante: UGREEN utiliza el puerto 53 para sus máquinas virtuales, precisamente el mismo puerto que emplea Pi‑hole para ofrecer su servicio DNS. Esto no es un problema grave, pero sí un aspecto a tener en cuenta, ya que obliga a ajustar la configuración para evitar conflictos entre ambos servicios y asegurarnos de que Pi‑hole pueda funcionar con normalidad dentro del NAS. En GITHUB está explicado en detalle la forma de «liberar» el puerto 53 de UGOS para que pueda ser usado por Pi-hole.

Para completar la instalación de Pi‑hole en nuestro NAS de UGREEN hemos optado por utilizar un conjunto de listas de bloqueo muy equilibrado entre eficacia y estabilidad. En concreto, hemos añadido la conocida lista unificada de StevenBlack, la versión Small de OISD —centrada en publicidad y rastreadores— y dos listas avanzadas de HaGeZi (Pro y TIF), que amplían la protección frente a dominios maliciosos y contenido no deseado. Con esta combinación obtenemos un filtrado DNS muy completo sin penalizar el rendimiento.

Con Pi‑hole funcionando como DNS principal del sistema, el NAS filtra de forma continua todo el tráfico saliente, bloqueando casi una quinta parte de las peticiones gracias a una base de más de dos millones de dominios catalogados. En la práctica, esto se traduce en una navegación más limpia, menos rastreadores y una reducción notable de ruido en la red, algo especialmente útil en un entorno donde conviven servicios, contenedores y dispositivos domóticos que generan consultas constantes.

Una mejora especialmente interesante sería disponer de información detallada sobre qué dispositivos de nuestra red generan las consultas DNS y cuáles de ellas terminan siendo bloqueadas. Pi-hole ofrece precisamente este tipo de estadísticas, pero en nuestra instalación, con el FRITZ!Box como router principal, obtener una identificación fiable y completa de cada dispositivo no resulta tan sencillo como nos gustaría. El router tiende a actuar como intermediario de las consultas DNS, por lo que buena parte de la información que llega a Pi-hole aparece asociada al propio FRITZ!Box en lugar del equipo que originó realmente la petición. Es un aspecto que tenemos pendiente de estudiar con más detalle, ya que disponer de estadísticas individuales permitiría saber no solo cuánto bloquea Pi-hole, sino también qué dispositivos y aplicaciones son los que generan mayor cantidad de tráfico susceptible de filtrado.