Qué es una búsqueda DNS y por qué la utilizan las redes
Qué es una búsqueda DNS, cómo funcionan las etapas de resolución y por qué ese momento es un control práctico de seguridad y rendimiento en redes WiFi compartidas.
Published 24 de octubre de 2026
Una búsqueda DNS es la forma en que un resolutor encuentra la información asociada a un nombre de dominio legible por humanos, casi siempre una dirección IP. El proceso clásico comprueba la información local, localiza los mejores servidores, les consulta una respuesta y, a continuación, devuelve y almacena en caché el resultado.
Es posible que esté leyendo esto en la red WiFi de un hotel, colegio u hospital tras pulsar en un sitio conocido. Su dispositivo está conectado, pero antes de que la página pueda cargarse, la red necesita encontrar dónde se aloja ese sitio. Piense en el DNS como un directorio distribuido que ayuda a su dispositivo a localizar servicios, no solo como una guía telefónica de sitios web.
Esa distinción es importante en una red WiFi compartida. El resolutor que gestiona una búsqueda puede afectar a la rapidez con la que se abre una página, si un dominio está bloqueado y si la red del establecimiento puede ver o gestionar la consulta. El cifrado, la autenticidad, la aplicación de directivas y el anonimato son propiedades independientes, y confundirlas puede llevar a decisiones de seguridad erróneas.
Índice de contenidos
- Qué hace realmente una búsqueda DNS
- Fases dentro de una búsqueda DNS
- La jerarquía que permite la escalabilidad de las búsquedas
- Por qué una búsqueda DNS es un punto de aplicación de políticas
- Lo que realmente cambia el DNS cifrado
- Cuando una búsqueda DNS falla en una red WiFi compartida
- Cómo elegir un DNS de protección a continuación
Qué hace realmente una búsqueda DNS
Un invitado pulsa un enlace en la red WiFi de un hotel. El navegador conoce el nombre de dominio, pero los dispositivos de red enrutan el tráfico mediante direcciones IP. Una búsqueda DNS consiste en que el solucionador encuentre la información asociada a ese nombre legible por humanos, la mayoría de las veces una dirección IP, para que el dispositivo pueda empezar a acceder al servicio.
Una guía telefónica es una analogía inicial útil, pero el DNS se parece más a un directorio distribuido en vivo. Diferentes tipos de registros admiten la entrega de correo, alias, descubrimiento de servicios, búsquedas inversas y otras funciones de red. El DNS no se limita a mapear nombres de sitios web a direcciones, sino que ayuda a las aplicaciones a encontrar una amplia variedad de servicios de red.
Las especificaciones fundamentales del DNS aparecieron en noviembre de 1987, cuando el Internet Engineering Task Force publicó la RFC 1034. Ese documento describía un algoritmo de cuatro etapas: comprobar la información local, buscar los mejores servidores, consultarlos hasta que llegue una respuesta y devolver y almacenar en caché el resultado cuando sea adecuado (RFC 1034). El almacenamiento en caché es importante porque un resolutor puede tener ya una respuesta útil de una solicitud anterior.
Una consulta de directorio, no una solicitud de página
Cuando su dispositivo solicita un nombre, no le está pidiendo al DNS que le entregue la página web. Le está pidiendo información que ayude a la aplicación a llegar al servicio correspondiente. A continuación, el navegador utiliza la respuesta como parte de su proceso de conexión.
En la red WiFi para invitados, esto convierte a la búsqueda en un punto de decisión compartido muy útil. El resolutor ve el nombre solicitado antes de devolver una dirección, por lo que los operadores de red pueden aprovechar ese momento para aplicar directivas. Para obtener una visión práctica de cómo los problemas de DNS pueden afectar a la disponibilidad, consulte esta guía para evitar el tiempo de inactividad causado por fallos de DNS.
Comprender el proceso le ayuda a rastrear adónde va una búsqueda, ver por qué las respuestas en caché pueden ser más rápidas y reconocer qué puede y qué no puede controlar el DNS en una red WiFi compartida. La velocidad, las directivas, el cifrado y los fallos de búsqueda están relacionados, pero no son el mismo problema.
Etapas dentro de una búsqueda DNS
El huésped de un hotel escribe example.com en un navegador y pulsa intro. La página aún no se ha cargado. Antes de que pueda hacerlo, el nombre pasa por una secuencia fija de búsquedas y, en una red WiFi compartida, cada paso ofrece a la red del establecimiento una nueva oportunidad para observar o dirigir la solicitud.
El stub resolver del dispositivo inicia la secuencia entregando una consulta recursiva a un resolvedor con caché. Un establecimiento, un proveedor de internet o un servicio DNS independiente pueden operar ese resolvedor, y la elección importa porque determina quién ve la consulta en primer lugar.
Acierto de caché o fallo de caché
El resolutor de almacenamiento en caché comprueba primero su memoria. Un registro que sigue siendo válido se devuelve directamente, un acierto de caché que omite todos los intercambios ascendentes. Un registro no encontrado o caducado es un fallo de caché, y el resolutor procede a trabajar a través de la jerarquía DNS: un servidor raíz lo dirige al dominio de nivel superior correcto, un servidor TLD lo dirige al servidor de nombres autoritativo del dominio y ese servidor de nombres devuelve el registro.
Para un sitio web, la respuesta suele ser un registro A que contiene una dirección IPv4 o un registro AAAA que contiene una dirección IPv6. Otros tipos de registro cubren tareas como el enrutamiento de correo y los alias.
Las etapas también plantean diferentes cuestiones. El cifrado decide quién puede leer la consulta en tránsito. La autenticidad decide si la respuesta procede del operador del dominio. Las políticas deciden si el solucionador la devuelve o no. El anonimato decide qué partes conocieron el nombre en primer lugar.
El TTL mantiene actualizadas las respuestas en caché
Cada conjunto de registros incluye un tiempo de vida (TTL), el tiempo máximo que un resolutor puede conservarlo. El resolutor debe descartar el registro al caducar, lo que permite que las direcciones y políticas actualizadas vuelvan a circular.
El fallo de caché de un huésped alimenta la caché para los visitantes que vienen detrás. Los TTL cortos permiten que los cambios surtan efecto antes; los TTL largos reducen las búsquedas repetidas hacia arriba. Los operadores de zona eligen un punto intermedio en ese equilibrio y todos en la red compartida heredan el resultado.
Algunas redes insertan un paso de reenvío dentro de esta secuencia, enviando consultas a otro solucionador en lugar de recorrer la jerarquía directamente. Este recorrido sobre cómo cambia ese trayecto con el reenvío DNS explica dónde se produce el desvío.
La jerarquía que permite escalar las búsquedas
La jerarquía DNS divide la responsabilidad. En la cúspide se encuentran las identidades de los servidores raíz, que dirigen a los solucionadores hacia el dominio de nivel superior correcto. Los servidores TLD gestionan dominios como .com y .org, mientras que los servidores autoritativos de cada dominio proporcionan los registros para los nombres dentro de ese dominio.
La imagen habitual de 13 servidores raíz puede llevar a engaño. Existen 13 identidades definidas históricamente, etiquetadas de la A a la M, gestionadas por 12 organizaciones independientes. No son simplemente 13 ordenadores físicos. El enrutamiento Anycast permite servir las mismas identidades desde más de 900 instancias distribuidas en todo el mundo, lo que ayuda a que las consultas lleguen a una instancia cercana y favorece la resiliencia (resumen de ICANN sobre servidores raíz).
Cómo se desarrolló el sistema raíz
El sistema raíz creció a medida que cambiaban las necesidades de la red. El primer servidor raíz se instaló en el Information Sciences Institute de la Universidad del Sur de California en 1984. El sistema contaba con cuatro servidores en 1985, siete en 1987, nueve en 1993 y 13 en 1997. Hoy en día, el sistema raíz utiliza tanto IPv4 como IPv6. Un análisis técnico identifica 26 puntos finales de dirección principales, 13 para cada protocolo, junto con las instancias Anycast distribuidas.
Estas cifras describen diferentes partes del diseño. Las 13 identidades son los nombres reconocibles de los servidores raíz; los puntos de conexión de direcciones admiten IPv4 e IPv6; las instancias distribuidas ayudan a prestar servicio desde ubicaciones de todo el mundo. Perder el acceso a una instancia no es lo mismo que perder una identidad raíz en todas partes.
Ese diseño es la razón por la que una búsqueda puede parecer local incluso cuando depende de un sistema global y multinivel. El resolutor puede alcanzar una instancia cercana, mientras que la jerarquía continúa distribuyendo la responsabilidad entre los operadores raíz, TLD y autoritativos.
Por qué una búsqueda DNS es un punto de aplicación de políticas
Un portátil conectado a la red WiFi de un hotel consulta al resolutor de la red sobre un dominio antes de poder acceder a cualquier contenido. Esa solicitud pasa a través de equipos que controla el establecimiento, lo que convierte a la búsqueda en el último punto de decisión compartido antes de que el dispositivo continúe por su cuenta. Un servicio de DNS de protección puede responder con normalidad, denegar la consulta o devolver una respuesta que no lleve a ninguna parte. Si no se devuelve una dirección útil, por lo general la conexión nunca se inicia.
Esa posición es la que otorga a las políticas DNS su alcance en las redes de invitados. Los teléfonos y portátiles de los visitantes raras veces cuentan con software de gestión, por lo que el establecimiento no puede instalar controles en el propio dispositivo. El resolutor es el único punto de control por el que ya pasan todos los dispositivos. Las políticas aplicadas allí pueden bloquear dominios asociados con phishing, malware o tráfico de comando y control, aplicar categorías como contenido para adultos o apuestas, y activar la configuración de Safe Search.
El momento adecuado refuerza el argumento. La aplicación de políticas se produce en la fase de solicitud, antes de que la aplicación reciba una dirección a través de ese solucionador. Para conocer las protecciones que operan en otras capas de la red, consulte esta guía para proteger su red empresarial de Microsoft 365.
Lo que las políticas de DNS pueden y no pueden cubrir
La aplicación de directivas DNS rige la resolución de nombres, y las conexiones pueden eludirla. Una aplicación podría reutilizar una dirección en caché, contactar directamente con una IP, acceder a un servicio que nunca utilizó un nombre DNS o enviar consultas a través de un resolvedor cifrado que el establecimiento no asignó.
Por lo tanto, los operadores evalúan el comportamiento del DNS cifrado, las cachés de las aplicaciones y el tráfico de IP directa junto con el filtrado. El filtrado DNS funciona como una capa dentro de un conjunto más amplio de controles. Una guía sobre el filtrado DNS y cómo se aplican las directivas a las búsquedas cubre la función de filtrado con detalle.
La política es también solo un eje de confianza. Si un dominio está permitido, si una respuesta es auténtica y si alguien puede leer la consulta en tránsito son cuestiones independientes, que se responden mediante mecanismos diferentes.
Las respuestas negativas también merecen atención. Un resolutor puede almacenar en caché una respuesta NXDOMAIN, que indica que el dominio solicitado no existe, en lugar de volver a preguntar a los servidores de nivel superior por el mismo nombre inexistente. El RFC 8020 describe el concepto de corte NXDOMAIN, en el que una respuesta negativa validada establece también que los nombres subordinados al dominio inexistente tampoco existen (RFC 8020). Las directrices más recientes del IETF recomiendan almacenar en caché también los fallos de resolución, reduciendo así las consultas repetidas inútiles.
Lo que realmente cambia con el DNS cifrado
Un huésped se conecta al WiFi de un hotel y visita un sitio web. La búsqueda de DNS es uno de los últimos puntos de decisión compartidos antes de la conexión: el dispositivo pregunta a un resolutor qué dirección utilizar y el resolutor puede aplicar las reglas del establecimiento. Cifrar esa solicitud cambia quién puede leerla en tránsito. Por sí solo, no cambia lo que el resolutor puede ver ni hace que el huésped sea anónimo.
El dispositivo envía su consulta a un solucionador recursivo, que busca la respuesta y la devuelve. DNS over HTTPS (DoH) cifra la conexión entre el dispositivo y ese solucionador. Alguien que monitorice la red WiFi tendrá más dificultades para leer o modificar la consulta, pero el solucionador seguirá recibiendo el dominio solicitado.
DNSSEC aborda una cuestión independiente: permite a un resolutor de validación comprobar la autenticidad y la integridad de los datos DNS firmados. No cifra la consulta. El cifrado, la autenticidad, la aplicación de políticas y el anonimato son propiedades totalmente distintas.
El dilema en redes WiFi compartidas
Un navegador que utiliza DoH puede enviar consultas a un resolutor elegido por el propio navegador o por el usuario, en lugar del resolutor asignado por un hotel, colegio, centro sanitario u operador de WiFi público. Eso puede limitar lo que ve el establecimiento y qué reglas de DNS puede aplicar. También puede dificultar la resolución de problemas si la red del recinto depende de su propio resolutor.
La diferencia práctica es clara: DoH protege la consulta en su trayecto hacia el solucionador; no oculta la consulta a dicho solucionador. DNSSEC ayuda a verificar las respuestas firmadas. Un establecimiento solo puede aplicar políticas DNS cuando las consultas pertinentes pasan a través de un solucionador que controla o con el que se ha integrado, y ninguna de las dos tecnologías hace que un usuario sea anónimo.
Cuando una búsqueda DNS falla en un WiFi compartido
Dos invitados se conectan al mismo WiFi de un hotel. Uno abre un sitio web habitual; el otro ve un error, aunque ambos dispositivos indican que están conectados. La diferencia puede estar en la ruta de búsqueda, en la caché del dispositivo o en el resolutor que utiliza cada cliente.
Un resolvedor puede resultar inaccesible, devolver una respuesta incompleta o ser incapaz de resolver un nombre que solo existe dentro de la red de una organización. Una red también puede bloquear el tráfico DNS tradicional sobre UDP o el puerto TCP 53, o devolver deliberadamente un fallo porque la directiva bloquea el dominio solicitado.
Separe los síntomas antes de cambiar la configuración
Considere el portal interno de un colegio que funciona a través del resolutor designado por el centro, pero no a través de un resolutor público externo. Es posible que el colegio utilice un DNS de horizonte dividido (split-horizon DNS), donde los nombres internos solo están disponibles a través del resolutor de la red. Cambiar la configuración de DNS de un dispositivo podría hacer que un sitio web público se cargue mientras se interrumpe el acceso al portal interno.
El DNS cifrado puede añadir otro punto de fallo. Un estudio de 2025 informó de que las consultas DNS por HTTPS representaban aproximadamente el 8 % del tráfico DNS observado, y que las respuestas incompletas aumentaban el volumen de consultas (estudio sobre el tráfico DNS cifrado). Otra investigación sobre resolutores descubrió que uno de cada tres resolutores cifrados anunciados no respondía, como se señaló antes. Por tanto, es posible que un cliente esté utilizando un resolutor cifrado que no responde como se espera, aunque el resolutor asignado por la red del establecimiento esté disponible.
Regla de resolución de problemas: confirme qué resolvedor utiliza realmente el cliente antes de pedirle al huésped que cambie la configuración del DNS.
Para los operadores, clasifique las causas probables en lugar de tratar cada error de búsqueda de la misma manera:
- Captive portal: El dispositivo no ha completado el inicio de sesión en la red WiFi o la página de términos.
- Caché obsoleta: El cliente o el resolutor conserva una respuesta desactualizada.
- Interrupción en la red proveedora: El resolutor configurado no puede completar la solicitud.
- Puerto 53 bloqueado: El tráfico DNS tradicional está bloqueado o no puede alcanzar el resolutor.
- DoH o DoT no compatibles: El comportamiento de DNS cifrado del cliente no es compatible ni está gestionado por la red.
- Bloqueo por política: El resolutor retiene intencionadamente una respuesta.
Un error de DNS también puede señalar un problema de seguridad en la red WiFi en lugar de un problema del resolvedor. Para obtener orientación sobre cómo reconocer un punto de acceso engañoso, consulte la guía de prevención de evil twin de RDE Technologies.
Cómo elegir a continuación un DNS de protección
Cada dispositivo de invitado que se conecta a su WiFi sigue teniendo que pedir indicaciones a alguien antes de conectarse. La verdadera elección del operador es quién responde a esa pregunta: el resolutor que lleve el dispositivo, el conjunto de reglas de un firewall antiguo o un servicio de DNS de protección que usted controle. Cada opción cambia la cantidad de directivas que puede aplicar y la cantidad de pruebas que conserva en ese último punto de decisión compartido.
| Enfoque | Dispositivos no gestionados | Punto de decisión | Evidencia del operador |
|---|---|---|---|
| Resolutores seleccionados por el cliente | A menudo fuera de la política DNS de la ubicación | Resolutor elegido por el dispositivo o el navegador | Visibilidad limitada en toda la red |
| Solo firewall obsoleto | La cobertura depende de las reglas del firewall y de la ruta del tráfico | Controles de firewall disponibles para esa red | Alertas y registros del firewall |
| Resolutor DNS de protección en la nube | Puede cubrir dispositivos que utilicen el resolutor asignado por la red | Búsqueda de dominio antes de que se devuelva una dirección | Informes de búsqueda y bloqueo del resolutor |
Para sectores como hostelería, educación, sanidad, sector público y redes con múltiples ubicaciones, Purple Shield es una opción de protección DNS, como se ha mencionado anteriormente. Evalúa las búsquedas antes de que se inicien las conexiones, aplica categorías de contenido como adultos y apuestas, fuerza el modo Búsqueda segura en Google, Bing y YouTube, y bloquea dominios de comando y control, phishing y malware. El proveedor también describe señales asistidas por IA diseñadas para detectar amenazas emergentes antes de que aparezcan en las listas de bloqueo estándar, además de un bloqueo de anuncios y rastreadores en la capa DNS que, según afirma, reduce el peso de las páginas y el volumen de tráfico.
Compare el ajuste operativo y de políticas
El servicio admite políticas por SSID, VLAN, establecimiento y horario, además de paneles de control, páginas de bloqueo personalizadas con marca y funcionamiento de bloqueo ante fallos (fail-closed). La descripción de su servicio indica que no requiere ningún agente de cliente ni cambios en el firewall, cita un SLA de tiempo de actividad publicado y muestra su alineación con los estándares de Friendly WiFi e Internet Watch Foundation. Considere estas afirmaciones como declaraciones del proveedor y evalúelas en función de sus propios requisitos de resiliencia e informes.
El filtrado DNS también responde solo a una parte de la cuestión de seguridad. El cifrado oculta la búsqueda a observadores en la ruta, las comprobaciones de autenticidad confirman que la respuesta procede del resolutor correcto, la política decide si responder o no, y el anonimato depende de quién opere ese resolutor. Un secure web gateway puede cubrir una parte mayor de esa pila, así que compare las diferencias entre ambas funciones antes de comprometerse.
Empiece con un SSID de invitados. Registre qué resolutor utilizan sus dispositivos hoy mismo y, a continuación, pruebe Purple Shield en esa red antes de ampliar la política a otros recintos.