Tu DNS no es tuyo: sigues reenviando cuando deberías estar resolviendo

"Siempre es el DNS."

Es el chiste más viejo de la administración de redes, y como todos los chistesviejos, es cierto más veces de las que quisiéramos.
Pero hay una variante que casi nadie cuenta: a veces no es tu DNS. Es el DNS de otro, el que decidiste usar sin pensarlo mucho, y sobre el que no puedes hacer absolutamente nada.
Son las ocho de la noche. El monitoreo está verde. Los suscriptores llaman porque no navegan. Y tú estás mirando la pantalla sin entender qué está fallando, porque técnicamente no está fallando nada que tú controles.

Y ese es exactamente el problema.

La falla de Cloudflare.

El 14 de julio de 2025, entre las 21:52 y las 22:54 UTC, el resolver 1.1.1.1 de Cloudflare quedó inalcanzable durante 62 minutos en todo el mundo. No fue un ataque. Los servidores DNS estaban sanos y respondiendo. Lo que ocurrió fue un error de configuración interna: un cambio activó una configuración latente que retiró de producción los prefijos que hacían alcanzable el servicio. Para el operador de red el resultado fue el mismo de siempre: resolución caída, suscriptores sin navegar, y nadie a quien llamar porque contractualmente no era cliente de nadie.

Un año después, Luis Aguilar —ingeniero con veinte años en telecomunicaciones y la última década formando técnicos de ISP en América Latina— abrió su masterclass Tu DNS no es tuyo con una demostración más cercana y más incómoda. Lanzó una consulta DNS desde su propia conexión hacia una dirección del rango 198.51.100.0/24. Ese rango está reservado para documentación técnica por el RFC 5737: no existe ningún servidor real en él, ni puede existir. La consulta devolvió respuesta.

Alguien más arriba en la cadena —su propio ISP— estaba interceptando el puerto 53 sin que él lo hubiera configurado, autorizado ni detectado antes de ese momento.

Dos incidentes. La misma raíz.

Quien operaba la red no controlaba su resolución.

Como resumió Aguilar al arrancar la sesión: "El DNS es lo que más veces he visto fallar en silencio, y lo último que alguien revisa."

Vamos a eso.

Cómo funciona el DNS realmente

El DNS es una base de datos distribuida organizada como un árbol invertido. En la cima están los servidores raíz, que solo conocen a los servidores de los dominios de nivel superior —los TLD: .com, .net, .ar —. Los TLD solo conocen a los servidores autoritativos de cada dominio. Y el autoritativo es el único que tiene la respuesta real: la IP de www.ejemplo.com.
Nadie conoce la lista completa. Cada nivel solo sabe a quién preguntar después.
Cuando tu red necesita resolver un nombre que no está en caché, un resolver recursivo —el motor que hace el trabajo real— desciende por ese árbol preguntando a cada nivel hasta llegar a la respuesta. Ese recorrido completo, en frío, implica entre seis y ocho intercambios y puede tomar entre 40 y 90 ms.
La buena noticia: ese coste se paga una sola vez por cada dominio, dentro del tiempo de vida de su registro en caché —el TTL, time to live—. Los registros NS de la raíz tienen un TTL de unos seis días. Los de los TLD, dos días. El único salto que se repite con frecuencia es la consulta al registro A del dominio, cuyo TTL suele estar entre 300 segundos y una hora.
Un resolver bien dimensionado sirve entre el 70 y el 85 % de las consultas desde memoria. Sin salir al exterior. El resto del tiempo —el 15 al 30 %— sí necesita ir a buscar la respuesta.
Sin resolver propio, ese porcentaje es el 100 %.
Y recuerda: una página web moderna dispara más de 20 consultas DNS antes de pintar el primer píxel. La latencia del DNS no es invisible. Es la antesala de todo lo que el suscriptor percibe como velocidad.

La ilusión de control: reenviar no es resolver

Aquí es donde se desmonta el supuesto más común entre operadores de redes de acceso.
Tener Pi-hole activo no es tener control sobre la resolución.Tener AdGuard Home no es tener control sobre la resolución.Tener el DNS de RouterOS encendido tampoco lo es.
Esas herramientas son forwarders —reenviadores—, no resolvers. Funcionan como un intermediario postal: reciben la consulta, la pasan a otro —habitualmente 8.8.8.8 o 1.1.1.1— y devuelven la respuesta. Pueden filtrar contenido. Pueden aplicar listas de bloqueo. Pueden registrar quién consultó qué. Pueden poner su sello en el sobre.
Pero el cartero real sigue siendo ajeno.

La resolución —y con ella el control, la disponibilidad y la política de respuesta— la sigue haciendo un tercero que no tiene ninguna obligación contractual contigo ni con tus suscriptores.

Ahora bien, ¿y si cifras? DoH —DNS over HTTPS— y DoT —DNS over TLS— protegen el contenido de las consultas en tránsito. Eso está bien. Pero no cambian la arquitectura de dependencia.
Como señaló Aguilar durante la masterclass: "Cifrar el camino no es lo mismo que controlar el destino."
Solo cambia quién puede ver el historial de consultas de tus suscriptores en el camino. No elimina la dependencia del tercero que resuelve.
El contraste entre plataformas lo ilustra perfectamente: en el DNS Technitium, dejar el campo de forwarders vacío activa la recursión completa. En RouterOS, dejar ese campo vacío apaga el servicio. Son filosofías opuestas. Y explican por qué un MikroTik puede ser un borde de red excelente, pero nunca puede ser tu resolver.

Por qué un ISP necesita su propio resolver

Aguilar presentó cinco razones concretas para que un operador de acceso monte su propio resolver recursivo dentro de su sistema autónomo. Las presento en orden de solidez argumental, no de importancia técnica.

Pieza 1 — Latencia percibida y calidad de experiencia. La diferencia entre 40–90 ms con resolver externo y caché fría, y 0–2 ms con resolver propio y caché caliente, es la diferencia entre una experiencia fluida y una que el suscriptor describe como "lenta sin razón". Con más de 20 consultas DNS por página, el efecto se multiplica.
Pieza 2 — Resiliencia ante caídas externas. Ya lo viviste en julio de 2025 o lo vivirás. Son las ocho de la noche, el monitoreo está verde y los suscriptores llaman porque no navegan. Un resolver propio con caché activa habría seguido respondiendo la mayoría de las consultas durante esos 62 minutos desde memoria. Sin depender de nadie.
Pieza 3 — Visibilidad por suscriptor antes del NAT. La consulta DNS llega a tu resolver con la IP de origen del suscriptor intacta, antes de que el NAT la enmascare. Eso permite correlacionar consultas con abonados individuales: diagnóstico de soporte, detección de equipos infectados, análisis de consumo por zona. En el momento en que esa consulta sale de tu AS hacia un tercero, la visibilidad se pierde: el resolver externo solo ve la IP pública de tu red, no la de cada cliente.
Una precisión honesta: esta visibilidad también la da un forwarder, porque el log se genera al recibir la consulta, no al resolverla. Lo que un resolver propio agrega es todo el resto —latencia, resiliencia y control de la política.
Pieza 4 — Cumplimiento regulatorio. Las regulaciones de telecomunicaciones en varios países de América Latina exigen bloquear dominios específicos. Con un resolver propio y RPZ —Response Policy Zones—, ese control es granular, auditable y está en tus manos. No en las de un proveedor que puede cambiar su política de bloqueo sin avisarte.
Pieza 5 — Diagnóstico de soporte en tiempo real. Cuando un suscriptor llama porque "una página no carga", poder consultar el log del resolver propio y responder en segundos si la falla es DNS o es otra cosa —eso es soporte de primer nivel competente. Sin eso, escala todo al NOC.
Una nota de honestidad que Aguilar dejó caer, y vale la pena repetir: el argumento del ahorro en tránsito de Internet no vende, porque no es real. Una consulta DNS pesa aproximadamente 80 bytes. El ahorro en la factura de tránsito es ruido estadístico. "No salen a Internet es cierto; ahorras tránsito es exagerado." Usarlo resta credibilidad a los cinco argumentos anteriores, que sí se sostienen.

Lo que ocurre realmente en una consulta DNS

Durante la masterclass, Aguilar capturó en vivo el tráfico que genera una sola consulta a "www.gov.uk" desde su resolver.
El cliente vio una línea: un nombre y una dirección IP, en 117 ms.
El resolver ejecutó unos cuarenta intercambios DNS. Habló con los autoritativos de Neustar, con Google Cloud DNS, con AWS Route 53, con Fastly y con Verisign. Validó la cadena DNSSEC completa pidiendo los registros DS y DNSKEY. Recibió una respuesta truncada que no cabía en UDP y tuvo que reintentar por TCP. Y resolvió por separado los nombres de cinco servidores autoritativos que llegaron sin glue records, repartidos en cinco dominios de primer nivel distintos.
Cinco organizaciones y una validación criptográfica, para una pregunta.
"El cliente preguntó una vez. El resolver, cuarenta veces."
Eso es lo que un resolver propio ejecuta en cada consulta que no está en caché. Eso es lo que un forwarder delega, invisible, a un tercero.

Qué plataforma corresponde a tu escala

No existe una plataforma ganadora en abstracto. La elección depende de tu escala y de la capacidad real de tu equipo. Como resumió Aguilar: "Ninguna plataforma gana en abstracto: busca la que corresponde a tu escala, no la mejor de la fila."
Unbound. Motor de referencia. Sin interfaz gráfica, pensado para línea de comandos y automatización. Huella de 30–60 MB. El candidato para ISPs con NOC técnico y múltiples POPs.
BIND9. El más antiguo y documentado. Puede operar como recursivo y autoritativo en el mismo equipo. Huella de 80–200 MB. Indicado cuando también hospedas zonas propias firmadas con DNSSEC.
Technitium. Interfaz web completa, configuración sin editar archivos de texto. Huella de 150–250 MB. La opción más accesible para ISPs locales con NOC pequeño o con rotación de personal técnico.
Pi-hole / AdGuard Home. Aquí hay que ser honesto: no son resolvers. Son filtros de contenido. El patrón correcto es usarlos al frente como capa de filtrado con Unbound detrás como motor recursivo. La documentación oficial de Pi-hole ya incluye esa guía. Casi nadie la sigue.
RouterOS DNS. Caché de borde. Útil para reducir consultas repetidas desde los CPE, pero sin capacidad de recursión completa. Nunca debe ser el resolver único de una red de acceso.

Compruébalo tú mismo: seis comandos

Nada de lo anterior hay que creerlo. Todo se comprueba, y lo que sigue funciona sobre cualquier red desde una terminal.

En Linux y macOS necesitas "dig", que viene en el paquete "dnsutils" o "bind-utils". En Windows no existe "dig" de fábrica: usa "Resolve-DnsName" desde PowerShell, o instala las herramientas de BIND.

1 · ¿Quién te está respondiendo?
"dig google.com +stats"
Mira la última línea de la salida, la que empieza con "SERVER:". Esa es la dirección que realmente te contestó. No siempre es la que creías tener configurada.
En PowerShell:
"Resolve-DnsName google.com"

2· ¿Tu red resuelve o reenvía?
Esta es la pregunta central del artículo, y la respuesta no está en ningún panel de configuración: está en el tráfico. Desde el host donde corre tu resolver, abre una captura:
"tcpdump -ni any port 53 and not net 192.168.0.0/16"
Y desde otra sesión, consulta un dominio que nunca hayas visitado:
"dig @127.0.0.1 dominio-inventado-4471.net"
Si en la captura ves tráfico hacia servidores raíz, TLD o autoritativos, tu servidor está resolviendo. Si solo ves un flujo hacia 8.8.8.8 o 1.1.1.1, está reenviando.

3 · ¿Alguien intercepta tu puerto 53?
"dig @198.51.100.77 google.com"
Esa dirección pertenece a TEST-NET-2, un rango reservado por el RFC 5737 para documentación. Ahí no existe ni puede existir un servidor DNS.
Si obtienes silencio o un timeout, probablemente nadie intercepta. Si obtienes una respuesta, alguien en la ruta está capturando el puerto 53 y respondiendo en lugar del destino.
No es una prueba perfecta —algunos operadores descartan estos rangos antes de que el paquete salga, lo que produce un falso negativo—, pero no tiene falsos positivos: si responde, hay interceptación.

4 · Compara tiempos entre resolvers
dig @8.8.8.8 google.com | grep "Query time" dig @1.1.1.1 google.com | grep "Query time" dig @77.88.8.1 google.com | grep "Query time"
El tercero es el DNS público de Yandex, alojado principalmente en Rusia. Desde América Latina debería tardar entre 200 y 300 ms. Si responde en 15, alguien mucho más cercano contestó por él.
Es un indicio, no una prueba: muchos resolvers públicos usan anycast y responden rápido de forma legítima. La prueba concluyente es la del punto 3.

5 · Los tres roles, en tres comandos
dig @8.8.8.8 google.com → un resolver público dig @ns1.tudominio.com tudominio.com → tu autoritativo, por su zona dig @ns1.tudominio.com google.com → el mismo, por una zona ajena
El tercero devuelve REFUSED. Eso no es una falla: es exactamente lo que define a un servidor autoritativo. Responde por los dominios que hospeda y rechaza el resto, porque no es un resolver.

El patrón completo, de punta a punta

Antes de cerrar, el resumen de arquitectura para tenerlo claro:

1. Resolver recursivo propio dentro de tu AS —Unbound, BIND9 o Technitium según tu escala— con caché dimensionada, TCP/53 abierto y ACL cerrada a tu rango de direcciones.

2. Capa de filtrado opcional al frente —Pi-hole o AdGuard Home— apuntando al resolver propio como upstream, no a 8.8.8.8.

3. RouterOS DNS en el borde como caché local para los CPE, apuntando al resolver propio, no a un tercero.

4. DHCP de los CPE entregando la IP de tu resolver, no la de nadie más.

5. Segundo resolver para redundancia y una ventana de parches definida en el calendario, no en la lista de pendientes.

Sin el paso 4, los pasos 1 al 3 son infraestructura que no llega al suscriptor.

Las tres decisiones que separan tener un resolver de operar uno

1. Elegir la plataforma que corresponde a tu escala real, no la que aparece primero en el tutorial de turno. Unbound si tienes NOC técnico. Technitium si necesitas que cualquier persona del equipo pueda operar sin editar archivos a mano.

2. Auditar tu tránsito antes de desplegar. El test de 198.51.100.0/24 tarda diez segundos y puede cambiar completamente tu conversación con tu proveedor de tránsito. Hazlo hoy.

3. Cambiar el DHCP de los CPE el mismo día que pones el resolver en producción. No al día siguiente. No cuando termines de probar. El mismo día. Si no cambias lo que el suscriptor recibe, el resolver es un ejercicio de laboratorio.

Al cierre de la masterclass, Aguilar volvió al principio con la frase que resume la tesis entera:
"Tu DNS no es tuyo. Todavía."
La diferencia entre "todavía" y "ya" no es técnica. Es una decisión operativa. Las herramientas existen, son maduras, están documentadas y la mayoría son código abierto.

De entenderlo a dominarlo
Esto fue el mapa.
El terreno se camina con el resolver instalado, la captura de tráfico abierta y una consulta al rango 198.51.100.0/24 que —esta vez— no devuelve respuesta.
Saber distinguir reenviar de resolver, elegir la plataforma que corresponde y conocer los errores que tumban un resolver en producción es la mitad del trabajo.
La otra mitad se hace con el teclado.

La grabación completa de la masterclass está disponible en el canal de YouTube de Ekoinos.