Es muy probable que tus dispositivos estén esquivando tu filtro DNS local ahora mismo
Montar tu propio filtro DNS genera una gran satisfacción. Instalas AdGuard Home, cargas listas de bloqueo cuidadosamente seleccionadas, apuntas el DHCP hacia tu propio servidor y ves pasar las consultas pensando: por fin controlo mi red.
La sorpresa es que no controlas casi nada. Es muy probable que tus dispositivos estén esquivando tu filtro DNS local ahora mismo.
Ese fue el golpe de realidad del debate. Hay dispositivos que ignoran el DHCP sin avisar. Un dispositivo Google Home envía sus peticiones DNS directamente a 8.8.8.8. Los navegadores tunelizan DNS mediante HTTPS (DoH), de modo que tu servidor ni siquiera llega a ver la consulta, y muchas aplicaciones de Android se saltan la resolución de nombres por completo conectándose directamente a direcciones IP fijas.
Ese dominio bloqueado que tan orgulloso estabas de haber interceptado quizá jamás pasó por tu servidor DNS. En cuanto comprendes eso, toda la idea de «tengo mi red blindada» empieza a tambalearse.
La ilusión del control
La configuración parecía perfecta al principio: AdGuard Home ejecutándose en local, listas de bloqueo activas y todo el tráfico apuntando a tu servidor DNS. Transmite una sensación limpia, centralizada y determinista.
Luego entra en juego la realidad técnica: servidores DNS incrustados en el firmware, DoH en el puerto 443, DoT en el puerto 853 y DoQ sobre UDP 853. Las consultas cifradas se cuelan por el mismo puerto que utiliza tu tráfico HTTPS ordinario. Las aplicaciones integran sus propios mecanismos de resolución y los dispositivos tratan tus asignaciones DHCP como una sugerencia opcional antes que como una regla.
De repente, tu servidor se queda esperando sin recibir nada: «Nadie me ha preguntado nada».
Esa es la parte inquietante. El filtrado DNS solo funciona si los clientes utilizan realmente tu servidor; si deciden ignorarlo, todo tu control se convierte en mero decorado.
La defensa en cinco capas
En lugar de resignarse, la respuesta fue subir el listón: una defensa estructurada en cinco capas basada en OPNsense, AdGuard Home y Unbound.
Las listas de bloqueo pasaron a ser solo una capa más. Se añadieron redirecciones NAT para obligar a las consultas DNS a volver al servidor local. Se bloquearon los puertos habituales de DNS cifrado. La lista de bloqueo de DoH de HaGeZi identificó los puntos de enlace conocidos de DNS cifrado y reglas de cortafuegos a nivel de IP interceptaron el tráfico que intentaba salir directamente.
Esto superó ampliamente el simple trasteo de homelab para convertirse en una contención activa. Aun así, hubo que tachar la palabra «todo» y cambiarla por «la mayoría», porque en redes nada queda cerrado al cien por cien.
«Tenemos 8.8.8.8 en casa»
Los comentarios se llenaron de ingenio. Una de las respuestas con más votos convirtió la situación en un chiste recurrente: «Tenemos 8.8.8.8 en casa». Otro usuario añadió: «¿Quieres 8.8.8.8? Claro, aquí tienes uno a solo un par de saltos».
Ahí es donde surge una solución brillante. Si los dispositivos se empeñan en comunicarse con 8.8.8.8, perfecto, dales 8.8.8.8; solo asegúrate de que esa dirección IP resida dentro de tu propia red local.
Varios usuarios explicaron cómo asignar 8.8.8.8/32 y 8.8.4.4/32 directamente a la interfaz de loopback de su router. Otros sugirieron crear una VLAN con 8.8.8.8/30 y un enrutamiento estático para que el router la trate como un siguiente salto local.
Es una maniobra elegante, ingeniosa y sumamente gratificante. El dispositivo cree que está hablando con Google cuando en realidad está consultando a tu propio servidor. Auténtica energía de superhéroe de internet, como bromeó un participante.
La objeción: esto puede romper cosas
El tono del debate cambió porque no todo el mundo considera la redirección forzada de DNS como un truco inocuo.
Un usuario advirtió de que reutilizar direcciones públicas aleatorias de IPv4 en redes internas a veces rompe servicios. Otro comentó que interceptar el tráfico generaba retardos notables e interrupciones en dispositivos de Google como Google Home y Chromecast.
Ese es el peaje. La interceptación agresiva puede elevar la latencia, los dispositivos inteligentes tienden a reintentar conexiones con insistencia y ciertos servicios esperan alcanzar infraestructuras muy concretas, comportándose de manera extraña cuando no lo consiguen.
Luego está la opción drástica: bloquear por completo el tráfico WAN saliente hacia 8.8.8.8. Cortarlo en el cortafuegos parece una medida limpia, pero los proveedores de DNS cifrado no se limitan a una única IP y, en cuanto DoH se camufla dentro del tráfico HTTPS habitual, el bloqueo por IP resulta tosco y arriesgado.
Meta, redes CDN y los límites del bloqueo
El análisis original no pretendía ofrecer una solución milagrosa y reconoció abiertamente lo que no es capaz de interceptar.
Meta, por ejemplo, empaqueta su DoH dentro de la infraestructura habitual de CDN de Facebook, de manera que bloquearlo con precisión sin romper Facebook o sus aplicaciones asociadas resulta prácticamente inviable.
Eso encaja con una tendencia más amplia. El DNS cifrado se está convirtiendo en el estándar por defecto. Los navegadores activan DoH de serie, los sistemas operativos experimentan con servidores cifrados y las grandes plataformas integran la resolución DNS directamente en sus flujos de tráfico.
Cuanto más cifrado y multiplexado está todo, más difícil resulta filtrar de manera quirúrgica. Bloquear DNS hoy implica arriesgarse a alterar el funcionamiento básico de aplicaciones legítimas.
El debate de fondo: privacidad frente a control parental y autonomía
Bajo el intercambio técnico subyace una discusión filosófica de gran calado.
Hay quien interpreta el DNS cifrado como un ataque directo al control de la red local. Si mantienes un filtro DNS para bloquear publicidad, frenar malware o aplicar control parental, DoH se percibe casi como un sabotaje.
Otros consideran que el DNS cifrado supone una gran victoria para la privacidad, ya que impide que los proveedores de internet (ISP) y los administradores de red espíen las consultas. Desde esa óptica, saltarse el servidor local es una medida de protección y no un acto malicioso.
Y luego está el grupo eminentemente práctico, a quien le da igual la ideología y solo pide que desaparezcan los anuncios y los dispositivos no fallen.
Un comentarista bromeó diciendo que al alojar el DNS en local nos convertimos en héroes de internet, como Netflix instalando servidores de caché en los ISP. Otro ironizó señalando que le estábamos ahorrando costes de tránsito a Google.
El humor maquilla una tensión real sobre quién debe ostentar el control de la resolución DNS: ¿el fabricante del equipo, el navegador, el proveedor de internet o el usuario? En un homelab, la inmensa mayoría responderá que el usuario. Internet, en su diseño actual, no siempre comparte esa postura.
La fragilidad de la «seguridad por defecto»
Resulta casi paradójico que cuanto más seguros y privados se vuelven los protocolos, más complicado resulta aplicar políticas locales.
DoH oculta el tráfico DNS dentro de HTTPS. Eso es excelente para esquivar la vigilancia de las operadoras y terrible para el filtrado local, a menos que decidas inspeccionar TLS, lo que abriría un dilema ético y técnico de otra dimensión.
Por eso acabas escalando con reglas de NAT, bloqueos de cortafuegos, redirecciones, trucos de direccionamiento IP y listas negras de endpoints DoH conocidos, asumiendo de antemano que solo atraparás la mayoría del tráfico.
Reconocer esa realidad con honestidad es fundamental, porque la ilusión de un control absoluto resulta mucho más peligrosa que la certeza de un control parcial.
Lo que nos enseña esta experiencia
Si algo deja claro todo este proceso, es que filtrar DNS ya no se resuelve con una única capa.
Apuntar el DHCP hacia tu servidor es solo el punto de partida básico. Los dispositivos modernos lo consideran opcional, los navegadores lo tratan como una sugerencia y muchas aplicaciones lo ignoran abiertamente.
Una protección con verdadero impacto exige interceptación a nivel de red, control de puertos, conocimiento de rangos IP y un mantenimiento constante de listas de servidores DoH. E incluso así, debes convivir con la imperfección.
El titular no era una exageración: es muy probable que tus dispositivos estén esquivando tu filtro DNS local en este instante. No es que hayas configurado mal tu red, ni que AdGuard o Unbound hayan fallado. Internet ha evolucionado y el control local del DNS dejó de venir garantizado por defecto.
Los desvíos existen; lo que queda por decidir es cuánto esfuerzo estás dispuesto a invertir para recuperar el control y cuántos fallos colaterales estás dispuesto a tolerar por el camino.
Blindar el tráfico DNS en 2026 exige bastante más que instalar un simple filtro. Tienes que definir quién manda de verdad en la resolución de nombres de tu red y estar dispuesto a defenderlo.