La mejor filtración DNS: una guía completa para empresas

Esta guía de referencia técnica explica cómo la filtración DNS empresarial protege las redes públicas al bloquear dominios maliciosos en la capa de resolución - antes de que se establezca una conexión. Proporciona a los directores de TI, arquitectos de redes y equipos de operaciones de las instalaciones la arquitectura de despliegue, la configuración del firewall y el contexto de cumplimiento normativo que necesitan para proteger el WiFi de invitados en entornos de hostelería, comercio minorista y sector público. Purple Shield bloquea el malware, las botnets y el contenido inapropiado a nivel de DNS en más de 80.000 instalaciones activas.

📖 8 min de lectura📝 1,807 palabras🔧 2 ejemplos prácticos❓ 4 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Bienvenido al Informe Técnico de Purple. Hoy analizamos un componente crítico de la seguridad de red empresarial: el filtrado DNS.

Si es un director de TI o un arquitecto de redes que gestiona redes públicas en los sectores de hostelería, retail o grandes recintos, sabrá que ofrecer WiFi es un servicio básico. Al igual que la electricidad o la climatización, es un servicio que los visitantes esperan que funcione en cuanto entran en un edificio. Pero, desde el punto de vista de la seguridad, este servicio crea una superficie de ataque masiva y no gestionada.

Al proporcionar acceso abierto a una red, invita a dispositivos no gestionados a su infraestructura. No puede instalar protección de endpoints en el dispositivo personal de un invitado. Los perímetros de seguridad tradicionales se quedan cortos. Por eso, el filtrado DNS se ha convertido en la capa más crítica de una pila de seguridad moderna. Desplaza la defensa al primerísimo paso de una conexión digital.

Comencemos con el análisis técnico detallado. ¿Cómo funciona realmente el filtrado DNS?

El Sistema de Nombres de Dominio, o DNS, es la agenda telefónica de internet. Cuando un invitado se conecta a su WiFi y escribe una dirección web en su navegador, su dispositivo debe traducir ese dominio legible por humanos en una dirección IP legible por máquinas. En una configuración estándar, esta consulta va a un resolvedor predeterminado, a menudo proporcionado por el ISP.

En una arquitectura segura que utiliza filtrado DNS, el servidor DHCP asigna un resolvedor DNS específico y seguro al dispositivo del invitado. Cuando la consulta llega a este motor de filtrado, no se limita a resolver la dirección IP. Evalúa el dominio comparándolo con fuentes de inteligencia de amenazas en tiempo real y con las políticas corporativas específicas de su empresa.

Si el dominio es benigno, se devuelve la IP y la conexión continúa. Esto sucede en milisegundos. Sin embargo, si el dominio se marca como malicioso - como un sitio de phishing conocido o un servidor de comando y control de una botnet - o si infringe su política de contenido, el motor interviene. Devuelve una dirección IP no enrutable, una técnica conocida como sinkholing, o redirige al usuario a una página de bloqueo personalizada.

¿Por qué es este enfoque superior a otras alternativas como la inspección profunda de paquetes o el filtrado proxy? Se reduce al rendimiento y a la escala.

La inspección profunda de paquetes requiere que el hardware de red inspeccione la carga útil de cada paquete. En un entorno denso como un estadio con cincuenta mil usuarios concurrentes, la DPI introduce una latencia masiva y requiere un hardware increíblemente costoso. El filtrado DNS, por otro lado, funciona al principio del ciclo de vida de la conexión. Evalúa un paquete UDP ligero. Una vez completada la resolución DNS, la transferencia de datos real se realiza directamente entre el cliente y el servidor seguro. El motor de filtrado no necesita procesar la pesada carga útil de los datos. Esto se traduce en un impacto de latencia casi nulo, normalmente inferior a dos milisegundos.

Además, dado que el filtrado DNS funciona antes de que se establezca la conexión, es completamente agnóstico al protocolo. Bloquea la conexión tanto si la aplicación intenta utilizar HTTP, HTTPS, FTP como un puerto personalizado.

Veamos ahora un ejemplo del mundo real. Imaginemos una cadena de hoteles de lujo de quinientas habitaciones. Están experimentando un alto consumo de ancho de banda debido al streaming ilegal y han recibido quejas sobre el acceso a contenidos inapropiados en las zonas comunes. Su sistema de gestión hotelera comparte la misma infraestructura física a través de VLANs.

El enfoque correcto es desplegar una solución de filtrado DNS basada en la nube y configurar el alcance DHCP específicamente para la VLAN de la WiFi de invitados para asignar las IPs DNS de la nube. Es fundamental implementar reglas de firewall en la pasarela para bloquear el tráfico saliente de los puertos UDP y TCP cincuenta y tres desde la VLAN de invitados a cualquier IP externa que no sean los servidores DNS aprobados. A continuación, se crea una política que bloquee las categorías de contenido para adultos, piratería y malware. La decisión de diseño clave es garantizar que la VLAN del sistema de gestión hotelera siga utilizando servidores DNS internos, aislando por completo la política de filtrado a la red de invitados.

Hablemos ahora de los errores de implementación.

El paso fundamental es la configuración de la red. Debe configurar su pasarela o servidor DHCP para entregar las direcciones IP de su servicio de filtrado DNS a todos los clientes de la VLAN de invitados.

Pero aquí está la regla de oro fundamental: bloquee el puerto cincuenta y tres, o no servirá de nada.

Si simplemente asigna los servidores DNS a través de DHCP, los usuarios expertos o las aplicaciones maliciosas pueden eludir el filtro configurando manualmente sus propios parámetros DNS, como el ocho-ocho-ocho-ocho de Google o el uno-uno-uno-uno de Cloudflare. Para evitar esta elusión, debe implementar reglas de firewall en la pasarela que bloqueen todo el tráfico saliente en el puerto cincuenta y tres, tanto UDP como TCP, a cualquier dirección IP que no sea la de sus servidores de filtrado designados.

Otro error habitual tiene que ver con los portales cautivos. Esto lo vemos a menudo en despliegues para comercios y hostelería. Un establecimiento implementa un filtrado DNS estricto y, de repente, los invitados no pueden iniciar sesión. ¿Por qué? Porque el Captive Portal depende de dominios externos para la autenticación, por ejemplo, proveedores OAuth para el inicio de sesión social. Si su filtro DNS bloquea estos dominios antes de que el usuario se haya autenticado, se crea un callejón sin salida. El usuario no puede acceder a internet para autenticarse, y no puede autenticarse para acceder a internet.

La solución es asegurarse de que su Walled Garden esté correctamente configurado. Debe incluir explícitamente en la lista de permitidos los dominios necesarios para la experiencia del Captive Portal dentro de la política de filtrado DNS.
Un segundo escenario del mundo real: un gran centro comercial minorista desea ofrecer WiFi público gratuito con un Captive Portal para la captura de datos demográficos, al tiempo que cumple con estrictas políticas corporativas aptas para familias. La integración del filtrado DNS con el Captive Portal requiere añadir los dominios de autenticación, como Microsoft Entra ID o Google Workspace, a la lista de permitidos previa a la autenticación. La política de filtrado de contenido se aplica únicamente después de que el usuario se haya autenticado correctamente. Este enfoque convierte un posible conflicto técnico en una experiencia de visitante fluida.

Pasemos ahora a una sesión de preguntas y respuestas rápidas basadas en escenarios comunes.

Pregunta uno: ¿Podemos utilizar la inspección transparente de HTTPS en lugar del filtrado DNS para nuestra red de invitados?

No. La inspección transparente de HTTPS requiere desplegar un certificado raíz personalizado en el dispositivo final para descifrar el tráfico. No se pueden desplegar certificados en dispositivos de invitados no gestionados. Esto interrumpiría su experiencia de navegación con graves advertencias de seguridad. El filtrado DNS es el enfoque correcto para entornos de tipo trae tu propio dispositivo.

Pregunta dos: ¿Cómo gestiona el filtrado DNS el DNS sobre HTTPS, o DoH?

El DoH cifra la consulta DNS, lo que puede eludir la interceptación tradicional a nivel de red. La mejor práctica es identificar y bloquear las direcciones IP de los proveedores de DoH conocidos en el cortafuegos, lo que obliga al cliente a recurrir al DNS estándar y filtrable.

Pregunta tres: ¿Ayuda el filtrado DNS con el cumplimiento normativo?

Por supuesto. Para marcos como PCI-DSS, es obligatorio demostrar la segmentación de la red y controles de acceso sólidos. Aunque las redes de invitados siempre deben estar segmentadas de las redes de pago, evitar la ejecución de malware en la red de invitados reduce el perfil de riesgo general del establecimiento. Para fines del GDPR, demostrar que se han adoptado medidas técnicas razonables para evitar el uso indebido de su red es un indicador positivo de cumplimiento.

Para resumir la sesión de hoy: El filtrado DNS no es solo una mejor práctica de seguridad. Es una necesidad operativa para las redes públicas empresariales. Proporciona un mecanismo escalable y de baja latencia para bloquear amenazas maliciosas y aplicar políticas de uso aceptable.

Los puntos clave son los siguientes. En primer lugar, el filtrado DNS intercepta las consultas de dominio antes de que se establezca la conexión, lo que añade menos de dos milisegundos de latencia. En segundo lugar, bloquee siempre el puerto de salida cincuenta y tres en el cortafuegos para evitar la elusión mediante configuraciones de DNS personalizadas. En tercer lugar, configure cuidadosamente su Walled Garden para asegurarse de que los dominios de autenticación del Captive Portal no estén bloqueados. En cuarto lugar, utilice la segmentación VLAN para aplicar políticas de filtrado exclusivamente al tráfico de invitados, protegiendo los sistemas operativos. Y en quinto lugar, el filtrado DNS favorece el cumplimiento de PCI-DSS y GDPR al demostrar controles de acceso a la red sólidos.

Sus próximos pasos: audite la configuración actual de DNS de su red de invitados, verifique que el puerto de salida cincuenta y tres esté restringido y revise el Walled Garden de su Captive Portal en comparación con su política de filtrado DNS activa.

Gracias por escuchar este Purple Technical Briefing. Para obtener guías de despliegue y patrones de arquitectura más detallados, visite purple.ai.

Conclusiones clave

✓El filtrado de DNS intercepta las solicitudes de resolución de dominio antes de que se establezca cualquier conexión, añadiendo menos de 2 ms de latencia, lo que lo convierte en el único método práctico de control de contenido para redes de invitados de alta densidad.
✓La asignación por DHCP por sí sola no garantiza el cumplimiento. Bloquee el puerto 53 de salida (UDP y TCP) en el firewall para evitar que los usuarios y el malware eviten el filtro utilizando configuraciones de DNS personalizadas.
✓Configure el Walled Garden antes de aplicar cualquier política de bloqueo. Los dominios de los proveedores de identidad (Microsoft Entra ID, Google Workspace, Okta) deben estar en la lista de permitidos para que funcione la autenticación del Captive Portal.
✓Limite el alcance de las políticas de filtrado de DNS únicamente a la VLAN de invitados. Las VLAN operativas que ejecutan sistemas POS y PMS deben utilizar servidores de resolución DNS internos para evitar interrupciones y fallos de cumplimiento con PCI-DSS.
✓Bloquee los rangos de IP de proveedores de DoH conocidos en el firewall para evitar la evasión de DNS cifrado en navegadores y dispositivos modernos.
✓El filtrado de DNS respalda el Requisito 1.3 de PCI-DSS (segmentación de red) y el Artículo 32 de GDPR (medidas técnicas de seguridad), proporcionando evidencia documentada para las auditorías de cumplimiento.
✓Purple Shield identifica y bloquea amenazas de día cero hasta 10 días más rápido que los proveedores de listas negras reactivas, utilizando análisis de dominios impulsado por IA en lugar de esperar a que se reporten los sitios maliciosos.

Resumen ejecutivo

Para los responsables de TI que gestionan redes públicas a gran escala, garantizar la seguridad del entorno de navegación es un mandato operativo, no un elemento opcional. El WiFi para invitados en sectores como hostelería, retail y espacios públicos es un entorno intrínsecamente inseguro. Sin unos controles sólidos, se convierte en un vector para la distribución de malware, la actividad de botnets y el acceso a contenidos inapropiados que dañan la reputación de la marca y exponen a la empresa a riesgos de cumplimiento.

El filtrado DNS es el mecanismo más eficiente para aplicar políticas de contenido y bloquear amenazas en el extremo de la red. A diferencia de la inspección profunda de paquetes (DPI), que consume muchos recursos, el filtrado DNS intercepta la solicitud de resolución de dominio antes de que se intercambie cualquier carga útil. Evalúa un paquete UDP ligero frente a la inteligencia de amenazas en tiempo real y devuelve una dirección IP válida o un sumidero de tráfico (sinkhole), añadiendo menos de dos milisegundos de latencia. Esto lo convierte en el único método práctico de control de contenido para entornos de alta densidad que dan servicio a miles de dispositivos no gestionados simultáneos.

Esta guía aborda la arquitectura técnica necesaria para desplegar el filtrado DNS en sedes empresariales distribuidas, incluyendo la segmentación de VLAN, la aplicación del puerto 53, la integración con el Captive Portal y la prevención de la elusión de DNS sobre HTTPS (DoH). También cubre el cumplimiento con PCI-DSS y GDPR, y explica cómo Purple Shield se integra en las infraestructuras de hardware existentes de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks y Fortinet sin necesidad de reemplazar el hardware.

Análisis técnico detallado: cómo funciona el filtrado DNS

El Sistema de Nombres de Dominio (DNS) traduce dominios legibles por humanos en direcciones IP legibles por máquinas. Cada conexión a internet comienza con una solicitud de resolución DNS. En una red estándar, los dispositivos consultan a un resolutor predeterminado asignado por el ISP. En una arquitectura segura, el servidor DHCP asigna un resolutor DNS con aplicación de políticas a los dispositivos en la VLAN de invitados.

Cuando un dispositivo consulta a este resolutor seguro, el motor de filtrado evalúa el dominio frente a múltiples fuentes de datos de forma simultánea: fuentes de inteligencia de amenazas en tiempo real, listas de bloqueo de categorías (contenido para adultos, apuestas, piratería) y registros de dominios de comando y control de botnets. La decisión se toma en milisegundos.

Si el dominio es seguro, el motor devuelve la dirección IP correcta y la conexión continúa normalmente. Si el dominio está marcado como malicioso o infringe su política de uso aceptable, el motor devuelve una dirección IP no enrutable (sinkholing) o redirige al usuario a una página de bloqueo personalizada. El punto clave: esta intervención ocurre antes de que se intercambie cualquier carga de datos entre el dispositivo y el servidor de destino.

Ventajas de rendimiento y escalabilidad

El filtrado DNS es arquitectónicamente superior al DPI para entornos públicos de alta densidad. El DPI requiere que el hardware de red inspeccione la carga útil de cada paquete. En un recinto con 50.000 usuarios concurrentes (un estadio, un centro de conferencias o un gran complejo comercial), el DPI introduce una latencia significativa y requiere un hardware costoso y diseñado específicamente en cada punto de inspección.

El filtrado DNS funciona al principio del ciclo de vida de la conexión. Evalúa un único paquete UDP ligero. Una vez completada la resolución, los datos se transfieren directamente entre el cliente y el servidor de destino. El motor de filtrado nunca procesa la carga útil de los datos. El impacto en la latencia es sistemáticamente inferior a dos milisegundos, independientemente del número de usuarios concurrentes.

Dado que el filtrado DNS funciona antes de que se establezca la conexión, es independiente del protocolo. Bloquea las conexiones tanto si la aplicación utiliza HTTP, HTTPS, FTP como un puerto personalizado. Esto supone una ventaja significativa frente al filtrado basado en URL, que solo inspecciona el tráfico HTTP/HTTPS.

La ventaja de detección de amenazas de 10 días

La seguridad DNS heredada se basa en listas negras reactivas: se identifica un dominio como malicioso, se notifica a una autoridad central, se añade a una base de datos y, finalmente, se distribuye a su filtro; un proceso que puede tardar días. Las campañas de malware modernas se aprovechan de este desfase. Los atacantes registran dominios nuevos, ejecutan una campaña en un plazo de 24 horas y abandonan el dominio antes de que llegue a cualquier lista de bloqueo estándar.

Purple Shield utiliza la detección de amenazas impulsada por IA para analizar patrones de registro de dominios, reputación de IP y firmas criptográficas en tiempo real. Este enfoque identifica y bloquea las amenazas emergentes de día cero hasta 10 días más rápido que los proveedores reactivos tradicionales (datos internos de Purple, 2026). En un entorno donde un solo enlace malicioso en un dispositivo invitado puede provocar un ransomware, ese plazo de detección es de gran importancia operativa.

Guía de implementación: arquitectura y despliegue

Desplegar correctamente el filtrado DNS requiere una configuración de red precisa en tres capas: DHCP, firewall y Captive Portal.

Paso 1: Segmentación de VLAN

Segmente su red para que el tráfico de invitados quede aislado de los sistemas operativos. Coloque los dispositivos de los invitados en una VLAN dedicada (por ejemplo, VLAN 20) y mantenga los terminales de punto de venta (TPV), los sistemas de gestión hotelera y los dispositivos del personal en VLAN independientes con resolutores DNS internos. Esto garantiza que su política de filtrado DNS se aplique exclusivamente al tráfico de invitados no confiable y no interrumpa los sistemas operativos.

Esta segmentación también cumple con el requisito 1.3 de PCI-DSS, que exige que los entornos de datos de titulares de tarjetas estén aislados de las redes no confiables. El WiFi de invitados nunca debe compartir una VLAN con la infraestructura de pago.

Paso 2: Configuración del alcance de DHCP

Configure el rango DHCP para la VLAN de invitados para asignar las direcciones IP de su servicio de filtrado DNS en la nube como servidores DNS primario y secundario. Esto garantiza que cada dispositivo que se conecte a la red de invitados reciba el resolvedor correcto de forma automática.

Paso 3: Aplicación del puerto 53 en el firewall

La asignación de DHCP por sí sola no es suficiente. Un usuario puede eludir la configuración de DNS proporcionada por DHCP configurando manualmente su dispositivo para utilizar un resolvedor público como Google (8.8.8.8) o Cloudflare (1.1.1.1). El software malicioso suele incluir configuraciones de DNS fijas en su código para eludir por completo los controles de red.

Debe implementar una regla de firewall que descarte todo el tráfico saliente en el puerto 53 (tanto UDP como TCP) desde la VLAN de invitados a cualquier dirección IP que no sean sus servidores de filtrado designados. Esto convierte el filtro DNS de un control consultivo en uno obligatorio.

Paso 4: Mitigación de DNS sobre HTTPS (DoH)

Los navegadores y aplicaciones modernos utilizan cada vez más DoH, que cifra las consultas DNS dentro del tráfico HTTPS estándar en el puerto 443. Esto elude por completo la interceptación del puerto 53. Para mantener la cobertura, configure su firewall para bloquear los rangos de direcciones IP conocidos de los principales proveedores de DoH. Esto obliga a los dispositivos cliente a volver al DNS estándar no cifrado, que su motor de filtrado puede inspeccionar. La norma NIST SP 800-81r3 (publicada en marzo de 2026) aborda específicamente el DoH como una consideración de seguridad de DNS corporativa.

Paso 5: Configuración del Walled Garden del Captive Portal

Si utiliza un Captive Portal para la autenticación de invitados, debe configurar un Walled Garden antes de aplicar cualquier política de bloqueo. El Walled Garden es una lista de dominios a los que los dispositivos pueden acceder antes de haberse autenticado. Debe incluir todos los dominios necesarios para que el Captive Portal funcione: el propio dominio de su portal, cualquier proveedor de identidad (Microsoft Entra ID, Okta, Google Workspace) y cualquier punto de conexión OAuth de inicio de sesión social.

Si estos dominios están bloqueados antes de la autenticación, los usuarios no podrán completar el flujo de inicio de sesión. El resultado es una experiencia de incorporación defectuosa y usuarios frustrados. Configure primero el Walled Garden y luego aplique su política de filtrado de contenido únicamente a las sesiones autenticadas.

Para obtener más información sobre la arquitectura de SSID y cómo deben estructurarse las redes de WiFi de invitados, WiFi de empleados e IoT, consulte Tres SSIDs para dominarlos a todos: invitados, Passpoint y WiFi de IoT .

Buenas prácticas: diseño de políticas y gestión continua

Bloqueo basado en categorías

Organice su política de filtrado DNS en torno a categorías de contenido en lugar de listas de bloqueo de dominios individuales. Las categorías suelen incluir: malware y phishing, comando y control de botnets, contenido para adultos, juegos de azar, streaming ilegal y uso compartido de archivos P2P. Las políticas basadas en categorías son más fáciles de mantener y capturan automáticamente nuevos dominios a medida que se actualiza la inteligencia de amenazas.

Frecuencia de actualización de la inteligencia de amenazas

Seleccione un proveedor de filtrado de DNS que actualice la inteligencia de amenazas en tiempo real o casi real. Las listas de bloqueo estáticas actualizadas a diario son insuficientes contra las campañas modernas de malware de flujo rápido (fast-flux). Purple Shield actualiza su inteligencia de amenazas continuamente, lo que refleja la misma detección impulsada por IA que proporciona la ventaja de 10 días sobre los proveedores reactivos.

Despliegue agnóstico del hardware

Purple Shield funciona como una superposición en la nube, lo que significa que se integra con su infraestructura de puntos de acceso existente sin necesidad de reemplazar el hardware. Es compatible con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La política de filtrado se aplica en la capa de DNS, por lo que el hardware del punto de acceso solo necesita reenviar las consultas de DNS al resolvedor correcto.

Analíticas e informes

El filtrado de DNS genera registros de consultas detallados que proporcionan visibilidad sobre el comportamiento de la red. Utilice estos registros para identificar tendencias: un aumento en los intentos de phishing bloqueados desde un punto de acceso específico puede indicar un ataque dirigido. La revisión periódica de los informes de categorías bloqueadas también respalda las auditorías de conformidad, demostrando a los evaluadores de PCI-DSS y auditores de GDPR que dispone de controles activos implementados.

La plataforma WiFi Analytics de Purple se integra con Shield para proporcionar una visibilidad unificada de los eventos de seguridad y el rendimiento de la red.

Resolución de problemas y mitigación de riesgos

Elusión del filtro mediante DNS personalizado

Síntoma: Los usuarios informan que acceden a contenido que debería estar bloqueado. Los registros del firewall muestran consultas de DNS a 8.8.8.8 o 1.1.1.1 desde la VLAN de invitados.

Causa: El puerto 53 no está bloqueado en el firewall. Los usuarios están anulando la configuración de DNS asignada por DHCP.

Solución: Implemente una regla de firewall que descarte todo el tráfico saliente de los puertos UDP/TCP 53 desde la VLAN de invitados hacia cualquier IP que no sea su motor de filtrado.

Fallo de autenticación en el Captive Portal

Síntoma: Los invitados no pueden completar el flujo de inicio de sesión. La página del Captive Portal no se carga o los botones de inicio de sesión social no responden.

Causa: El filtro de DNS está bloqueando los dominios del proveedor de identidad antes de la autenticación. Microsoft Entra ID, Google Workspace o el propio dominio de su portal están en una lista de categorías bloqueadas.

Solución: Audite su configuración de Walled Garden. Añada todos los dominios de autenticación requeridos a la lista de permitidos antes de la autenticación. Pruebe todo el flujo de inicio de sesión en un entorno de pruebas antes de desplegar cambios en las políticas.

Elusión de DoH

Síntoma: Los registros del filtro de DNS muestran un volumen bajo de consultas a pesar de la alta utilización de la red. Algunos dispositivos parecen eludir el filtrado por completo.

Causa: Los navegadores o las aplicaciones utilizan DoH, enrutando consultas de DNS cifradas a través del puerto 443 hacia resolvedores externos.

Solución: Bloquee los rangos de IP conocidos de los principales proveedores de DoH en el firewall. Verifique la cobertura supervisando las conexiones HTTPS a las direcciones IP de los resolvedores de DoH conocidos.

Interrupción de la VLAN operativa

Síntoma: Los terminales de punto de venta (POS) o los sistemas de gestión hotelera pierden la conectividad tras el despliegue del filtro de DNS.

Causa: La política de filtrado de DNS se ha aplicado a la VLAN incorrecta o el DHCP está asignando el resolvedor de DNS en la nube a dispositivos operativos.

Solución: Verifique la etiqueta de VLAN en todos los puertos del switch y puntos de acceso. Confirme que las VLAN de los dispositivos operativos estén configuradas para usar únicamente resolvedores de DNS internos.

ROI e impacto empresarial

El filtrado de DNS ofrece un retorno cuantificable en tres dimensiones.

Recuperación de ancho de banda: El bloqueo del streaming ilegal, el uso de redes peer-to-peer y el tráfico automatizado de botnets recupera una cantidad considerable de ancho de banda. En el sector hotelero, esto puede reducir el uso de la VLAN de invitados entre un 20 % y un 40 %, lo que mejora el rendimiento para los usuarios legítimos sin necesidad de actualizar las líneas contratadas.

Reducción de costes de cumplimiento: Demostrar la aplicación de controles activos a nivel de DNS reduce el alcance y el coste de las auditorías de PCI-DSS. También proporciona pruebas documentadas para el Artículo 32 del GDPR (medidas técnicas para garantizar la seguridad de los datos) y respalda los requisitos de certificación de Cyber Essentials en materia de protección contra malware.

Protección de marca y de responsabilidad civil: Aplicar políticas de navegación aptas para familias en entornos de retail y hostelería evita la visualización pública de contenidos inapropiados. En espacios frecuentados por niños (centros comerciales, hoteles familiares, estadios), esto es tanto un requisito de marca como una consideración legal en muchas jurisdicciones.

Para obtener orientación de implantación específica para cada sector, consulte nuestras páginas especializadas para Hostelería , Retail , Sanidad y Transporte .

Definiciones clave

Filtración DNS

Una técnica de seguridad que intercepta las solicitudes de resolución de dominios y las evalúa frente a fuentes de inteligencia de amenazas y políticas de contenido antes de permitir o bloquear una conexión.

El método principal de control de contenido para dispositivos de invitados no gestionados en redes públicas. No requiere agente de punto final.

Sinkholing

Devolver una dirección IP no enrutable (como 0.0.0.0) en respuesta a una consulta DNS para un dominio malicioso, evitando que el dispositivo establezca una conexión.

Utilizado para bloquear silenciosamente el tráfico de comando y control de botnets sin alertar al malware de que ha sido detectado.

Walled Garden

Un entorno de red restringido previo a la autenticación que permite el acceso a un conjunto específico de dominios aprobados antes de que un usuario complete el flujo de inicio de sesión de captive portal.

Debe incluir todos los dominios del proveedor de identidad (Microsoft Entra ID, Google Workspace, Okta) y los recursos de captive portal para evitar fallos de autenticación.

DNS over HTTPS (DoH)

Un protocolo que cifra las consultas DNS dentro del tráfico HTTPS estándar en el puerto 443, ocultando el dominio de destino de la inspección a nivel de red.

Cada vez más utilizado por defecto en los navegadores modernos. Requiere el bloqueo a nivel de cortafuegos de los rangos de IP de los proveedores de DoH para mantener la cobertura de filtrado de DNS.

Segmentación de VLAN

Dividir una única red física en múltiples redes lógicas aisladas utilizando el etiquetado 802.1Q.

Crítico para aislar el tráfico de invitados de los sistemas operativos. El requisito 1.3 de PCI-DSS exige que los entornos de datos de titulares de tarjetas estén separados de las redes no confiables, incluido el WiFi de invitados.

Captive portal

Una página web con la que los dispositivos deben interactuar antes de obtener acceso completo a la red, utilizada para la autenticación, la aceptación de los términos de servicio y la captura de datos de primera mano.

Requiere una configuración cuidadosa de Walled Garden para funcionar correctamente junto con el filtrado de DNS.

Deep Packet Inspection (DPI)

Un método de filtrado de red que examina la carga útil completa de los paquetes en un punto de inspección, lo que permite un filtrado que tiene en cuenta el contenido pero introduce una sobrecarga de procesamiento significativa.

Poco práctico para redes de invitados de alta densidad debido a la latencia y al coste del hardware. El filtrado de DNS es la alternativa preferida para entornos de dispositivos no gestionados.

Fuente de inteligencia de amenazas

Una base de datos actualizada continuamente de direcciones IP, dominios y patrones de URL maliciosos conocidos, utilizada para potenciar las decisiones de filtrado de DNS en tiempo real.

La calidad y la frecuencia de actualización de la fuente de inteligencia de amenazas determinan con qué rapidez responde un filtro DNS a las nuevas amenazas de día cero.

Dominio de día cero

Un dominio recién registrado utilizado en una campaña de malware o phishing antes de que aparezca en cualquier lista de bloqueo estándar.

Las campañas de ataque modernas utilizan dominios desechables que están activos durante menos de 24 horas. La detección de amenazas impulsada por IA identifica estos dominios analizando los patrones de registro en lugar de esperar a recibir informes.

Ejemplos prácticos

Una cadena hotelera de 400 habitaciones está desplegando WiFi de invitados en 12 propiedades. Utilizan Microsoft Entra ID para la autenticación del Captive Portal y su sistema de gestión de propiedades (PMS) se ejecuta en la misma infraestructura de switch físico. Tras activar la filtración DNS, los huéspedes de tres propiedades informan de que no pueden completar el proceso de inicio de sesión. ¿Cuál es la causa principal y cómo debe resolverlo el equipo?

La causa principal es una configuración incompleta del Walled Garden. El filtro DNS está bloqueando los dominios de autenticación de Microsoft Entra ID antes de que los huéspedes se autentiquen, creando una situación sin salida en la que los huéspedes no pueden cargar la página de inicio de sesión. Pasos para la resolución: 1. En el panel de control de filtración DNS, cree una política de preautenticación que incluya explícitamente en la lista de permitidos todos los dominios de Microsoft Entra ID, incluidos login.microsoftonline.com, login.live.com y cualquier dominio específico del inquilino. 2. Verifique que el propio dominio del Captive Portal y cualquier recurso de CDN que cargue también estén en la lista de permitidos. 3. Confirme que la VLAN del PMS (VLAN 10) está configurada para utilizar resolutores DNS internos, no el motor de filtración en la nube. 4. Aplique la política restrictiva de bloqueo de contenidos únicamente a las sesiones de postautenticación en la VLAN de invitados (VLAN 20). 5. Pruebe todo el flujo de inicio de sesión en cada propiedad afectada antes de cerrar la incidencia.

Comentario del examinador: Este es el fallo de despliegue de filtración DNS más común en el sector de la hostelería. La solución es sencilla, pero requiere comprender que la filtración DNS se aplica a todas las consultas DNS de un dispositivo, incluidas las realizadas antes de la autenticación. El Walled Garden debe configurarse antes de que se active cualquier política de bloqueo. El problema de aislamiento del PMS es un hallazgo secundario pero crítico: mezclar políticas de DNS operativas y de invitados en el mismo resolutor crea un riesgo de cumplimiento bajo el Requisito 1.3 de PCI-DSS.

Una gran cadena de tiendas minoristas opera 200 tiendas, cada una con una red WiFi de invitados. Su equipo de seguridad de TI despliega un filtro DNS en la nube y actualiza el ámbito DHCP en todas las VLAN de invitados. Dos semanas después, una prueba de penetración revela que el 18% de los dispositivos de los invitados están resolviendo con éxito dominios maliciosos conocidos. Los registros del filtro DNS no muestran consultas bloqueadas de estos dispositivos. ¿Cuál es el fallo de arquitectura y cuál es la solución?

El fallo es que el puerto 53 no está bloqueado en el firewall. El 18% de los dispositivos están eludiendo los servidores DNS asignados por DHCP al utilizar resolutores preconfigurados (8.8.8.8, 1.1.1.1) o al utilizar DNS sobre HTTPS. Dado que sus consultas DNS nunca llegan al motor de filtración, no aparecen consultas bloqueadas en los registros. Solución: 1. Implemente una regla de firewall en la puerta de enlace de la VLAN de invitados que descarte todo el tráfico saliente UDP y TCP en el puerto 53 hacia cualquier IP que no sea la de los motores de filtración aprobados. 2. Identifique y bloquee los rangos de IP de los principales proveedores de DoH (Cloudflare, Google, NextDNS) en el firewall para evitar la elusión cifrada. 3. Vuelva a ejecutar la prueba de penetración para confirmar la cobertura. 4. Supervise los registros de descarte del firewall para el tráfico del puerto 53 para verificar que la regla está activa.

Comentario del examinador: DHCP es una sugerencia, no un mecanismo de aplicación. La regla del firewall es la capa de aplicación real. Esta distinción es crítica y se pasa por alto con frecuencia en los despliegues iniciales. La elusión de DoH es un vector secundario que requiere una mitigación independiente. Juntos, estos dos controles - el bloqueo del puerto 53 y el bloqueo de IP de proveedores de DoH - cierran las vías principales de evasión.

Preguntas de práctica

Q1. Una cadena de tiendas minoristas despliega un filtro DNS en la nube en 150 tiendas. Actualizan el alcance de DHCP en todas las VLAN de invitados para asignar las IP del motor de filtrado. Una semana después, los gerentes de las tiendas informan que los clientes aún pueden acceder a categorías de contenido bloqueadas. El panel del filtro DNS muestra un volumen de consultas muy bajo desde estas tiendas. ¿Cuál es la causa más probable y cuál es la solución?

Sugerencia: Considere cómo un dispositivo puede resolver DNS sin utilizar el servidor asignado por DHCP.

Ver respuesta modelo

La causa más probable es que el puerto de salida 53 no esté bloqueado en el cortafuegos. Los dispositivos están omitiendo los servidores DNS asignados por DHCP mediante resolutores públicos codificados estáticamente. El bajo volumen de consultas en el panel confirma que las consultas no están llegando al motor de filtrado. La solución consiste en implementar una regla de cortafuegos que descarte todo el tráfico UDP y TCP saliente en el puerto 53 de la VLAN de invitados hacia cualquier IP que no sea la de los motores de filtrado aprobados. Adicionalmente, se deben bloquear los rangos de IP de los proveedores de DoH conocidos para evitar la elusión de DNS cifrado.

Q2. Un centro de conferencias está implementando el filtrado de DNS por primera vez. Utilizan Google Workspace para la autenticación de los asistentes en su Captive Portal. Durante las pruebas, los asistentes no pueden completar el flujo de inicio de sesión: la página de inicio de sesión de Google no se carga. ¿Qué paso de configuración se omitió y cómo debería corregirse?

Sugerencia: La autenticación ocurre antes de que el dispositivo tenga acceso completo a internet. ¿Qué dominios deben ser accesibles antes de que se complete la autenticación?

Ver respuesta modelo

El Walled Garden no se configuró antes de aplicar la política de filtrado de DNS. El filtro DNS está bloqueando los dominios de autenticación de Google Workspace (accounts.google.com, oauth2.googleapis.com) antes de que los asistentes puedan autenticarse. La solución es añadir todos los dominios de autenticación y OAuth de Google Workspace requeridos a la lista de permitidos previa a la autenticación en la política de filtrado de DNS. El propio dominio del Captive Portal y cualquier recurso de CDN también deben incluirse en la lista de permitidos. Aplique la política de contenido restrictiva solo a las sesiones posteriores a la autenticación.

Q3. El equipo de TI de un estadio está evaluando el filtrado de DNS frente a la inspección profunda de paquetes (DPI) para su recinto con capacidad para 60.000 personas. Al equipo de redes le preocupa la latencia durante los eventos de máxima afluencia. ¿Qué enfoque es más adecuado y por qué?

Sugerencia: Considere la sobrecarga de procesamiento de cada método a una escala de 60.000 usuarios concurrentes.

Ver respuesta modelo

El filtrado de DNS es la opción adecuada. Funciona en la capa de resolución, evaluando un único paquete UDP ligero antes de que se establezca cualquier conexión, lo que añade menos de dos milisegundos de latencia independientemente del número de usuarios concurrentes. DPI requiere inspeccionar la carga útil completa de cada paquete, lo que con 60.000 usuarios concurrentes introduciría una latencia significativa y requeriría un hardware extremadamente costoso en cada punto de inspección. El filtrado de DNS también es independiente del protocolo, bloqueando conexiones a través de cualquier puerto, mientras que DPI suele limitarse al tráfico HTTP y HTTPS.

Q4. Un director de TI de un grupo hotelero quiere confirmar que su implementación de filtrado de DNS cumple con los requisitos de PCI-DSS. Sus terminales de pago están en la VLAN 10 y el WiFi de invitados está en la VLAN 20. El filtro de DNS se aplica únicamente a la VLAN 20. ¿Qué evidencia adicional deben documentar para su asesor de PCI-DSS?

Sugerencia: El requisito 1.3 de PCI-DSS cubre los controles de acceso a la red entre redes confiables y no confiables.

Ver respuesta modelo

El director de TI debe documentar: 1. Reglas de firewall que confirmen que no se puede acceder a la VLAN 10 (entorno de datos de titulares de tarjetas) desde la VLAN 20 (red de invitados), cumpliendo con el Requisito 1.3 de PCI-DSS. 2. Configuración de DHCP que demuestre que los dispositivos de la VLAN 10 utilizan servidores de resolución DNS internos, no el motor de filtrado en la nube. 3. Reglas de firewall que bloqueen el puerto 53 de salida desde la VLAN 20 hacia IPs no aprobadas, demostrando la aplicación obligatoria del filtrado de DNS. 4. Documentación de la política del filtro DNS que muestre las categorías activas de bloqueo de malware y botnets en la VLAN 20. 5. Registros del filtro DNS que muestren eventos de consultas bloqueadas, demostrando que el control está activo y monitoreado.

Continúe leyendo esta serie

Cómo segregar de forma segura las redes WiFi de empleados y de invitados

Esta guía técnica autorizada proporciona a los responsables de TI estrategias prácticas para segregar de forma segura las redes WiFi de empleados, invitados e IoT utilizando VLANs y 802.1X. Detalla cómo proteger la infraestructura empresarial, mantener el cumplimiento de PCI-DSS y aprovechar los Captive Portals para capturar datos de origen.

Comprensión de Cisco SUDI: Identidad con Anclaje por Hardware en el Control de Acceso Seguro a la Red

Esta guía explica cómo Cisco SUDI proporciona una identidad con anclaje por hardware y criptográficamente segura para la infraestructura de red empresarial. Aprenda a sustituir las direcciones MAC suplantables por certificados 802.1AR inmutables para proteger el control de acceso a la red de su recinto.

Cómo configurar SCEP para el registro automatizado de certificados WiFi corporativos

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi corporativos, abarcando toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a directores de TI, arquitectos de red y CTO de hoteles, cadenas de retail, estadios, centros de conferencias y organizaciones del sector público que necesitan ir más allá de las claves precompartidas e implementar una autenticación 802.1X EAP-TLS escalable y basada en la identidad. La plataforma de superposición en la nube de Purple, que es independiente del hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto a la red de personal autenticada por certificado.