ExplainerDNS filtering limits
Fallo abierto vs. fallo cerrado en el filtrado DNS: qué ocurre cuando el filtro deja de funcionar
Podrá decidir cómo deben comportarse las redes WiFi para invitados y WiFi para empleados cuando el filtro DNS deje de responder, además de comprobar si su red realmente falla en modo cerrado. Sabrá dónde se oculta la alternativa de reserva en el DHCP, los reenviadores y los dispositivos, y cómo probar la redundancia...
La disyuntiva entre fail open y fail closed en el filtrado DNS radica en la decisión sobre cómo actúa una red cuando su resolutor de filtrado deja de responder. El modo fail open recurre a un resolutor sin filtrado, por lo que la navegación continúa sin protección. El modo fail closed no envía las consultas a ningún otro sitio, en consonancia con el control SC-24 (fail in known state) de NIST SP 800-53, de forma que nada se resuelve sin filtrar.
¿En qué consiste el filtrado DNS fail open frente a fail closed?
El filtrado DNS se ubica en el primer paso de cada conexión. Un teléfono solicita a un resolutor que convierta un nombre de dominio en una dirección IP antes de abrir cualquier sesión (RFC 1035). Un resolutor DNS de protección comprueba ese nombre en función de la inteligencia sobre amenazas y de su política de contenidos. A continuación, devuelve la dirección real, la dirección de una página de bloqueo o una denegación.
Esta ubicación es la razón por la que el filtrado DNS funciona. La comprobación se realiza antes de que un solo paquete llegue al destino. Puede detener un enlace de phishing o una llamada de malware que un firewall solo vería como tráfico permitido en el puerto 443. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) gestiona un servicio de DNS de protección para el sector público basado en este mismo principio.
Esta ubicación también representa su punto débil. Si cada búsqueda depende del resolutor de filtrado, necesita un plan para cuando no se pueda acceder a él. Solo existen dos planes.
- Fail open. La red o el dispositivo envía la consulta a otro resolutor que no aplica ninguna política. La navegación continúa, pero la protección, el registro y las reglas de contenido se detienen hasta que el filtro vuelve a estar disponible.
- Fail closed. No existe ninguna ruta sin filtrar. Las nuevas búsquedas quedan a la espera de que responda un resolutor de filtrado y nada se resuelve sin una decisión de la política.
La elección es una compensación entre disponibilidad y garantía. El modo fail open favorece al visitante que desea que la página se cargue de inmediato. El modo fail closed favorece a su equipo de seguridad, al responsable de protección y al auditor, quienes necesitan demostrar que la red ha estado filtrada cada minuto del año.
El estándar NIST SP 800-53 Rev. 5 expone esta misma idea en dos controles. SC-24 es "fail in known state" y SC-7(18) es "fail secure" (NIST SP 800-53 Rev. 5).
¿Cómo funciona el comportamiento ante fallos del filtro en el resolutor?
El comportamiento ante fallos del filtro lo determina su configuración, no el filtro en sí. Se establece en tres lugares: el servidor DHCP, cualquier reenviador DNS local y el propio dispositivo.
Los campos DNS de DHCP
DHCP es el protocolo que asigna a cada dispositivo su dirección IP y la configuración de red al conectarse. La mayoría de las redes de invitados y de personal lo utilizan para proporcionar a cada dispositivo dos o más direcciones de servidores DNS. Si todas ellas apuntan a resolutores de filtrado, el diseño es fail closed. Si la segunda apunta a un resolutor público o del ISP, el diseño es fail open, independientemente de lo que prometa el proveedor de filtrado.
Flow diagram showing a guest device query timing out at the filtering resolver, falling back to an unfiltered secondary resolver and connecting to a domain with no policy check.
Connections
- Guest device to Filtering resolver (1. Query on port 53)
- Filtering resolver to Guest device (2. Timeout, no reply)
- Guest device to Unfiltered fallback resolver (3. Retry to secondary)
- Unfiltered fallback resolver to Answer with no policy check (4. Resolves any domain)
- Answer with no policy check to Connection opens (5. Device connects)
El reenviador local
Muchos firewalls y gateways ejecutan un reenviador DNS. Los dispositivos consultan al gateway y este reenvía la solicitud a los resolutores ascendentes. En este caso, la opción alternativa se encuentra en la lista ascendente del reenviador. Un reenviador que incluye un resolutor público por debajo del filtro falla en abierto, incluso si la configuración de DHCP parece correcta.
El comportamiento del propio dispositivo
La selección del resolutor varía según el sistema operativo. Algunos dispositivos tratan al segundo servidor como una alternativa estricta en espera. Otros lo consultan cada vez que el primero responde despacio o envían consultas a ambos. Con un diseño de fallo en abierto, las respuestas sin filtrar pueden filtrarse mientras el filtro funciona perfectamente.
Cómo es un diseño de fallo en cerrado
En un diseño de fallo en cerrado, cada dirección DNS que un dispositivo o reenviador puede utilizar apunta a un resolutor de filtrado con la misma directiva. Si uno deja de responder, el dispositivo vuelve a intentarlo con el siguiente. La búsqueda falla únicamente cuando todos los resolutores de filtrado son inaccesibles. El dispositivo recibe entonces un tiempo de espera agotado o la respuesta SERVFAIL, el error estándar de fallo del servidor DNS, en lugar de una respuesta sin filtrar.
Diagrama de flujo que muestra un dispositivo reintentando en un segundo resolver de filtrado tras el fallo del primero, la política permitiendo o bloqueando el dominio, y una ruta discontinua donde todos los resolvers fallan y no se abre ninguna conexión.
Connections
- Dispositivo to Resolver de filtrado 1 (1. Consulta)
- Dispositivo to Resolver de filtrado 2 (2. Reintento al siguiente filtro)
- Resolver de filtrado 2 to Comprobación de política (3. Aplicar política de red)
- Comprobación de política to Respuesta limpia (4a. Dominio permitido)
- Comprobación de política to Respuesta de bloqueo (4b. Amenaza o categoría bloqueada)
- Dispositivo to Sin respuesta (Si todos los filtros fallan)
Si se aplica correctamente, el fallo bloqueado no es frágil. La resiliencia proviene de los resolvers de filtrado redundantes, no de una vía de escape sin filtrar.
Fail open, fail closed, fail secure: ¿qué términos suelen confundirse?
En los documentos de los proveedores, los hallazgos de auditoría y los tickets de cambio aparecen cuatro términos muy cercanos. Describen cosas distintas y mezclarlos conduce a un diseño erróneo.
| Término | Qué describe | Durante una interrupción del filtro | Riesgo que conlleva |
|---|---|---|---|
| Fail open | Las consultas recurren a un resolutor no filtrado cuando no se puede acceder al filtro | La navegación continúa sin filtrar | Las amenazas y las categorías bloqueadas se resuelven sin directivas y a menudo sin registro |
| Fail closed | Solo se configuran resolutores de filtrado, sin alternativa no filtrada | Las nuevas búsquedas fallan hasta que un resolutor de filtrado responde | La disponibilidad depende de la redundancia del filtro |
| Fail secure (NIST SC-7(18)) | Término del marco de control: un dispositivo perimetral no debe entrar en un estado no seguro ante un fallo | Mismo resultado práctico que fail closed | Los auditores pueden solicitar pruebas de ello |
| Serve-stale (RFC 8767) | Un resolutor responde desde una caché caducada cuando los servidores entrantes no están accesibles | Los dominios visitados recientemente se siguen resolviendo | Las respuestas reflejan la última decisión, no una comprobación de directivas reciente |
| Default deny | Directiva para dominios que el filtro aún no ha categorizado | No es un modo de fallo; se aplica mientras el filtro funciona correctamente | Bloqueo excesivo si se configura de forma muy estricta |
| Bypass | Un dispositivo ignora el resolutor de red mediante DNS codificado de forma rígida, DoH o DoT | No se ve afectado, porque no se filtra en ningún momento | Requiere controles de salida, no una configuración de fallos |
Fail closed no es default deny
Default deny es una elección de directivas sobre dominios no categorizados. Funciona mientras el filtro está activo. Fail closed se refiere a lo que ocurre cuando el filtro no está presente. Puede ejecutar fail closed con una directiva permisiva, o fail open con una estricta.
Serve-stale se sitúa entre ambos
RFC 8767 permite que un resolutor responda desde una caché caducada cuando no puede conectar con los servidores entrantes. Esto mantiene en funcionamiento los nombres más populares durante interrupciones breves. Vuelve a reproducir la última decisión, por lo que un dominio que se haya vuelto malicioso desde entonces no será detectado.
La omisión o bypass no es un fallo
Un dispositivo que utiliza DNS sobre HTTPS (DoH, RFC 8484) o DNS sobre TLS (DoT, RFC 7858) hacia un resolutor público nunca interactúa con su filtro. Los ajustes de fail closed no tienen ningún efecto sobre ello. La omisión debe gestionarse mediante reglas de salida.
¿Dónde se produce una interrupción del filtrado de DNS en la práctica?
Una interrupción del filtrado de DNS solo es relevante cuando el enlace a Internet está activo pero no se puede acceder al filtro. Si cae todo el enlace ascendente, ambos modos se comportan de la misma manera. En la práctica, la diferencia surge a través de eventos operativos cotidianos:
- un cambio en el firewall que bloquea el puerto 53 saliente hacia las direcciones del filtro;
- un reenviador local que se bloquea o deja de reenviar hacia el servidor entrante;
- un cambio de enrutamiento en la WAN de una sucursal que envía las solicitudes DNS por la ruta incorrecta;
- un contratista que edita un ámbito DHCP y añade un resolvedor público "para tener resiliencia";
- un incidente en el propio proveedor de filtrado.
Cada uno de estos casos parece inofensivo en una red que falla en modo cerrado. Sin embargo, cada uno elimina la protección silenciosamente en una red que falla en modo abierto.
Redes de WiFi para invitados en hostelería
Los hoteles y grupos de restauración aplican políticas de contenido para que la WiFi para invitados sea apta para familias y esté a salvo de malware. Una red de invitados que falla en modo abierto abandona esa política sin avisar a nadie. Para los grandes operadores de hostelería, un fallo de política en la WiFi pública conlleva tanto un riesgo de marca como un riesgo de seguridad.
Sector sanitario
Shield bloquea unas 241 000 amenazas a la semana en St George's Healthcare NHS Trust. Según nuestros cálculos, esto equivale a una media de unas 1400 a la hora. Una ventana de fallo en modo abierto de una hora permitiría que esas búsquedas se resolvieran sin control en los dispositivos de pacientes, visitantes y personal.
Centros de transporte
Los aeropuertos albergan miles de dispositivos de pasajeros en redes públicas, muchos de ellos no gestionados. En una terminal, una brecha por fallo en modo abierto significa una red pública sin filtrar en momentos de máximo volumen.
Redes corporativas y de personal
Las redes del personal aumentan las exigencias de disponibilidad. Las aplicaciones corporativas deben seguir funcionando, por lo que el fallo en modo cerrado necesita una redundancia real detrás. Los nombres internos suelen resolverse en servidores DNS internos, que luego reenvían las consultas externas al filtro. Asegúrese de que ese nivel de reenvío tampoco tenga ningún nivel superior sin filtrar.
¿Cuáles son los límites y casos particulares del DNS que falla en modo cerrado?
El fallo en modo cerrado es la opción predeterminada adecuada para la mayoría de las redes WiFi corporativas y de invitados. Aun así, tiene límites que conviene conocer antes de diseñar su arquitectura.
El fallo en modo cerrado con un solo resolvedor es un plan de interrupción
Si la red incluye una única dirección de filtrado, el fallo en modo cerrado significa que cualquier caída de esa dirección interrumpirá el DNS. La redundancia a través de múltiples resolvedores de filtrado es lo que hace que el fallo en modo cerrado sea viables. Pregunte a su proveedor cuántas direcciones de resolvedor puede configurar y pruebe cada una de ellas.
La caché mantiene vivos algunos nombres
Cada respuesta DNS incluye un TTL (tiempo de vida), el número de segundos que un dispositivo o resolvedor puede mantenerla en caché. Durante una interrupción corta, los nombres almacenados en caché siguen funcionando y los nuevos fallan. Los visitantes lo perciben como "algunos sitios funcionan y otros no", lo que puede desorientar a su servicio de asistencia.
Los Portales Cautivos necesitan DNS antes de iniciar sesión
Un Captive Portal es la página de bienvenida que ve un invitado antes de conectarse. El dispositivo debe resolver el portal y cualquier dominio del walled garden antes de autenticarse. Si la red previa al inicio de sesión utiliza un resolvedor sin filtrar, el portal se convierte en la brecha. Si falla en modo cerrado sin redundancia, los invitados no podrán iniciar sesión en absoluto.
Un fallo tiene un aspecto diferente al de un bloqueo
Un dominio bloqueado debe devolver una página de bloqueo o una denegación clara. Una búsqueda fallida devuelve un tiempo de espera agotado o SERVFAIL. RFC 8914 Extended DNS Errors añade códigos que los diferencian, como Bloqueado (15) y Filtrado (17) en comparación con Autoridad No Alcanzable (22). Informe a su equipo de soporte sobre ambos, para que puedan distinguir un bloqueo por directiva de una caída del servicio.
El DNS no puede ver más allá del nombre
Fallo cerrado garantiza una decisión de directiva en cada búsqueda, no una cobertura total. Las conexiones a direcciones IP puras se saltan el DNS por completo. Las conexiones que ya estaban abiertas antes de la caída continúan. El DNS también ve solo el dominio, nunca la ruta, lo cual se explica en por qué el filtrado DNS no puede ver URLs completas.
Para saber cómo encajan estos límites en un entorno más amplio, consulte ¿es suficiente el filtrado DNS? y la vista general de límites del filtrado DNS.
¿Cómo se relaciona el DNS de fallo cerrado con Purple Shield?
Purple Shield es DNS de protección y filtrado de contenidos para cualquier red. Shield aplica fallo cerrado, por lo que una caída del servicio nunca deja una red sin filtrar. Cada búsqueda recibe una decisión de directiva o ninguna respuesta, nunca una sin verificar.
Puede ejecutar Shield de forma independiente en cualquier red WiFi o junto con Purple Access. Puede configurar una directiva por red y por VLAN (LAN virtual, una red lógicamente independiente sobre hardware compartido). Las redes de invitados, personal y administración en un mismo centro pueden aplicar reglas diferentes. Shield no requiere hardware nuevo y se integra como una superposición en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet.
- ~241.000amenazas bloqueadas a la semanaSt George's Healthcare NHS Trust
- 80.000+ubicaciones activasDatos de Purple
- 90paísesDatos de Purple
DNSFilter y Cisco Umbrella también filtran en la resolución DNS, por lo que el argumento de la ubicación se aplica a los tres. La pregunta que se debe hacer a cada proveedor es dónde reside la alternativa. Pregunte cómo se comportan sus agentes itinerantes cuando los resolutores no están localizables y cuántas direcciones de filtrado puede configurar. A continuación, compruebe que sus propios ajustes de DHCP y reenvío no reintroduzcan una ruta sin filtrar.
Shield opera en toda la presencia de Purple de más de 80.000 ubicaciones en 90 países. Lea cómo funciona Shield para obtener detalles sobre el despliegue. La guía de seguridad WiFi para empresas muestra dónde se sitúa el filtrado DNS junto con la identidad y la segmentación.
Este concepto repercute durante la ventana de cambios, no en el folleto. La regla del firewall, la edición del DHCP o la DNS secundaria pública «resiliente» son las que determinan si su red permanece filtrada. Audite estas tres configuraciones este trimestre. A continuación, lea DNS sobre TLS y filtrado: qué cambia con el puerto 853, ya que un resolvedor de denegación por defecto (fail closed) solo protege los dispositivos que realmente lo utilizan.
Preguntas frecuentes
¿Un sistema DNS de denegación por defecto implica que una interrupción deje mi red WiFi sin conexión?
No, no cuando el filtro se ejecuta en resolvedores redundantes. La denegación por defecto solo detiene las nuevas búsquedas cuando no se puede acceder a ningún resolvedor de filtrado al mismo tiempo. Los dispositivos vuelven a intentarlo primero con la siguiente dirección de filtrado. Las respuestas almacenadas en caché permiten que los sitios visitados recientemente sigan resolviéndose durante interrupciones breves. Diseñe la redundancia antes de la puesta en marcha y, a continuación, pruébela bloqueando un resolvedor cada vez desde un VLAN de prueba.
¿Funcionará Shield con los puntos de acceso y firewalls que ya poseo?
Sí. Shield filtra en la resolución DNS, por lo que no requiere nuevo hardware y se ejecuta de forma independiente en cualquier red WiFi. Purple funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Solo tiene que apuntar el DNS de cada red o VLAN a Shield, eliminar cualquier alternativa sin filtrar y aplicar una directiva por red. La página del producto describe los pasos a seguir.
¿Cómo se calcula el precio de Shield?
Purple presupuesta Shield para su infraestructura en lugar de publicar una tarifa estándar en esta guía. Shield es un complemento de seguridad que puede ejecutar de forma independiente en cualquier red WiFi o junto con Purple Access. Por tanto, el presupuesto refleja sus redes y recintos, no el hardware nuevo. Solicite un presupuesto indicando el número de recintos, la cantidad de redes y VLAN, y si ya utiliza Purple.
¿Cómo puedo migrar desde DNSFilter o Cisco Umbrella sin que se produzca una brecha en el filtrado?
Realice la transición de una red o VLAN a la vez. Apunte el DNS DHCP de un VLAN de prueba a Shield, confirme los bloqueos y los registros y, a continuación, mueva las redes activas durante una ventana de cambios. Elimine por completo las direcciones del resolvedor antiguo en lugar de dejarlas como DNS secundario. Compruebe también los agentes de roaming en los dispositivos del personal, ya que sus configuraciones de reserva quedan fuera de su ámbito DHCP.
¿Existe alguna normativa que exija el filtrado DNS de denegación por defecto?
Ninguna normativa menciona explícitamente el DNS de denegación por defecto, pero los marcos de control esperan que los controles de seguridad fallen en un estado conocido y seguro. El control SC-24 de la norma NIST SP 800-53 Rev. 5 contempla el fallo en un estado conocido. El control SC-7(18) contempla la protección perimetral con fallo seguro. El filtrado con denegación por defecto le aporta pruebas de que la directiva se ha aplicado en todo momento, lo que resulta de gran utilidad cuando los auditores o los responsables de protección lo requieran.
¿Cómo puedo probar el comportamiento actual de mi filtro en caso de fallo?
Bloquee el DNS saliente hacia sus resolvedores de filtrado desde un único VLAN de prueba y observe cómo responde el dispositivo. Si los sitios web continúan cargándose y el filtro no registra nada, la red permite el acceso por defecto (fail open). Revise los campos DNS del DHCP, las listas de reenviadores ascendentes y cualquier configuración codificada en el dispositivo. Repita el proceso bloqueando un resolvedor de filtrado cada vez para confirmar que la redundancia funciona correctamente.
¿Es suficiente el filtrado DNS por sí solo o necesito un secure web gateway?
El filtrado DNS cubre la protección contra amenazas y las directivas de contenido para la mayoría de las redes de invitados y recintos, pero no inspecciona las URL completas ni ofrece prevención contra la pérdida de datos. Detecta nombres de dominio, pero no rutas ni contenido de archivos. Si necesita esos controles, añada un secure web gateway en los dispositivos gestionados. Consulte filtrado DNS frente a secure web gateway para conocer las diferencias.
Key terms
- DNS protectivo
- Un resolutor recursivo que comprueba cada dominio consultado contra la inteligencia de amenazas y la directiva de contenido antes de responder, devolviendo la dirección real, una dirección de página de bloqueo o una denegación. Actúa sobre la búsqueda de nombres definida en el RFC 1035, antes de que se abra cualquier sesión. El NCSC del Reino Unido gestiona un servicio de Protective DNS para el sector público basado en este principio. Es el control cuyo modo de fallo rige esta decisión.
- Fallo abierto
- Un diseño en el que las consultas DNS recurren a un resolutor que no aplica ninguna directiva cuando el resolutor de filtrado es inaccesible. La resolución continúa, pero el bloqueo de amenazas, las reglas de contenido y el registro de eventos se detienen. Suele encontrarse como un resolutor público o del ISP en el campo secundario de DHCP o en una lista ascendente de reenviadores. A menudo se introduce por accidente durante un cambio.
- Fallo cerrado
- Un diseño en el que cada dirección DNS que un dispositivo o reenviador puede utilizar apunta a un resolutor de filtrado con la misma directiva. Una búsqueda falla con un tiempo de espera agotado o SERVFAIL solo cuando todos los resolutores de filtrado son inaccesibles. Es el valor predeterminado adecuado para la mayoría de las redes WiFi para invitados y WiFi para empleados, siempre que haya resolutores de filtrado redundantes respaldándolo.
- Fallo seguro (NIST SC-7(18))
- Mejora de la protección del perímetro SC-7(18) del estándar NIST SP 800-53 Rev. 5, que requiere que un dispositivo perimetral evite entrar en un estado no seguro en caso de fallo. Es posible que los auditores le pidan evidencias al respecto. El filtrado DNS con fallo cerrado ofrece el mismo resultado práctico.
- Fallo en estado conocido (NIST SC-24)
- Control SC-24 del estándar NIST SP 800-53 Rev. 5, que exige que los sistemas fallen en un estado conocido y definido en lugar de en uno impredecible. Ninguna normativa menciona explícitamente el DNS con fallo cerrado, pero este control es el lenguaje del marco de trabajo que se cita al justificarlo ante auditores o responsables de protección de datos.
- Uso de datos caducados (Serve-stale)
- Comportamiento del RFC 8767 que permite a un resolutor responder desde una caché caducada cuando no puede alcanzar los servidores ascendentes, manteniendo operativos los nombres resueltos recientemente. Suaviza las interrupciones breves, pero reproduce la última decisión, por lo que no detecta un dominio que se haya vuelto malicioso desde entonces.
- SERVFAIL
- El código de respuesta de fallo del servidor en el formato de mensaje DNS definido en la norma RFC 1035, que se devuelve cuando un resolver no puede completar una búsqueda. En una red a prueba de fallos con bloqueo, es lo que recibe un dispositivo cuando todos los resolvers de filtrado están caídos. Su equipo de soporte debe aprender a distinguirlo de un bloqueo.
- Errores DNS extendidos
- Códigos RFC 8914 que añaden detalles a las respuestas DNS, incluidos Bloqueado (15), Filtrado (17) y Autoridad no alcanzable (22). Permiten al personal y a las herramientas de soporte diferenciar un bloqueo por directiva de una interrupción del servicio al diagnosticar avisos de sitios web que no cargan.
- TTL (tiempo de vida)
- El campo en cada registro de recursos DNS, definido en la norma RFC 1035, que indica el número de segundos que un dispositivo o resolver puede guardar la respuesta en caché. Durante una interrupción breve, los nombres guardados en caché siguen funcionando y los nuevos fallan. Los visitantes lo comunican indicando que algunos sitios cargan y otros no.
- Reenviador DNS
- Un servicio DNS en un firewall, puerta de enlace o servidor interno que recibe las consultas de los dispositivos y las reenvía a una lista configurada de resolvers ascendentes. La alternativa se encuentra en su lista ascendente. Un resolver público allí ubicado fallará con permiso aunque el DHCP esté correcto, incluida la capa posterior al DNS interno en redes del personal.
- DoH y DoT
- DNS sobre HTTPS, especificado en RFC 8484, y DNS sobre TLS, especificado en RFC 7858. Ambos cifran el DNS hacia un resolver seleccionado y pueden eludir el resolver de la red. Se trata de una omisión, no de un fallo. La configuración a prueba de fallos con bloqueo no influye en ellos, por lo que debe controlarlos mediante reglas de salida.
- Portal cautivo
- La página de bienvenida que ve un invitado antes de conectarse a Internet. El dispositivo debe resolver los dominios del portal y del jardín vallado antes de autenticarse. Un resolver previo al inicio de sesión sin filtrar convierte al portal en el punto vulnerable. Una red de portal a prueba de fallos con bloqueo y sin redundancia impide que los invitados inicien sesión.
- Denegación por defecto
- Una directiva de filtrado para dominios que el filtro aún no ha categorizado. Se aplica mientras el filtro funciona correctamente y no es un modo de fallo. Suele confundirse con la opción a prueba de fallos con bloqueo. Puede ejecutar esta última con una directiva permisiva o a prueba de fallos con permiso con una estricta.
Worked examples
Un contratista añade un resolutor público al ámbito DHCP de una red de invitados como DNS secundario para aportar resiliencia. El resolutor de filtrado se mantiene como primario. ¿Sigue estando protegida la red?
No. Incluir un resolutor público en el campo secundario hace que el diseño falle en modo abierto. Algunos sistemas operativos consultan ese segundo servidor siempre que el primero va lento, por lo que las búsquedas sin filtrar pueden filtrarse a diario y no solo durante las interrupciones. Para confirmarlo, bloquee el DNS saliente hacia los resolutores de filtrado desde un VLAN de prueba. Si los sitios se siguen cargando y el filtro no registra nada, la red falla en modo abierto. Sustituya la dirección pública por un segundo resolutor de filtrado que aplique la misma directiva. A continuación, revise las listas de reenviadores ascendentes y la configuración hardcoded de los dispositivos en busca del mismo error. Por último, bloquee los resolutores de filtrado de uno en uno para demostrar que la redundancia funciona.
Va a migrar las redes de invitados y de empleados de DNSFilter o Cisco Umbrella a Purple Shield. ¿Cómo evita que quede una brecha en el filtrado durante la transición?
Realice la transición de una red o VLAN cada vez. Comience apuntando el DNS DHCP de un VLAN de prueba a Shield y, a continuación, confirme que los bloqueos y registros aparecen según lo previsto. Traslade las redes activas en una ventana de cambio una vez superada la prueba. Elimine por completo las direcciones de los resolutores antiguos en lugar de dejarlas como DNS secundario. Si se mantiene un secundario antiguo, se vuelve a introducir una ruta sin filtrar o incoherente. Compruebe también los agentes itinerantes en los dispositivos del personal, ya que su configuración de reserva se encuentra fuera de su ámbito DHCP. Este enfoque permite que cada búsqueda permanezca bajo el control de una directiva a lo largo de toda la migración. Asimismo, mantiene intacto el comportamiento de fallo cerrado de Shield una vez retirado el proveedor antiguo.
Frequently asked questions
¿El DNS a prueba de fallos con bloqueo implica que una caída dejará mi WiFi sin conexión?
No, no cuando el filtro se ejecuta en resolvers redundantes. El modo a prueba de fallos con bloqueo solo detiene las nuevas búsquedas cuando todos los resolvers de filtrado están inaccesibles a la vez. Los dispositivos reintentan primero con la siguiente dirección de filtrado. Las respuestas guardadas en caché mantienen la resolución de los sitios visitados recientemente durante interrupciones breves. Diseñe la redundancia antes de la puesta en marcha y, a continuación, pruébela bloqueando un resolver a la vez desde un VLAN de prueba.
¿Funcionará Shield con los puntos de acceso y firewalls que ya tengo?
Sí. Shield filtra en la resolución DNS, por lo que no requiere hardware nuevo y se ejecuta de forma independiente en cualquier red WiFi. Purple funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Solo tiene que apuntar el DNS de cada red o VLAN a Shield, eliminar cualquier alternativa sin filtrar y aplicar una directiva por red. La página del producto explica todos los pasos.
¿Cómo se calcula el precio de Shield?
Purple presupuesta Shield para su espacio en lugar de publicar una lista de precios en esta guía. Shield es un complemento de seguridad que puede ejecutar de manera independiente en cualquier red WiFi o junto con Purple Access. Por lo tanto, el presupuesto refleja sus redes y recintos, no hardware nuevo. Solicite un presupuesto indicando su número de recintos, su red y número de VLAN, y si ya utiliza Purple.
¿Cómo puedo migrar desde DNSFilter o Cisco Umbrella sin interrupciones en el filtrado?
Realice la migración de las redes o de los VLAN de uno en uno. Apunte el DNS DHCP de un VLAN de prueba a Shield, confirme los bloqueos y registros y, a continuación, mueva las redes en producción dentro de una ventana de cambios. Elimine por completo las direcciones del antiguo resolutor en lugar de dejarlas como DNS secundario. Compruebe también los agentes móviles en los dispositivos del personal, ya que sus configuraciones alternativas quedan fuera de su alcance DHCP.
¿Existe alguna normativa que exija un filtrado DNS con fallo de cierre?
Ninguna normativa exige explícitamente el filtrado DNS con fallo de cierre (fail closed), pero los marcos de control esperan que los controles de seguridad fallen en un estado conocido y seguro. El control SC-24 de NIST SP 800-53 Rev. 5 contempla el fallo en un estado conocido. El SC-7(18) cubre la protección perimetral que falla de forma segura. El filtrado con fallo de cierre le proporciona pruebas de que la directiva se ha aplicado en todo momento, lo que resulta de gran ayuda cuando lo soliciten los auditores o los responsables de protección.
¿Cómo pruebo el comportamiento ante fallos de mi filtro actual?
Bloquee el DNS saliente hacia sus resolutores de filtrado desde un único VLAN de prueba y observe cómo reacciona el dispositivo. Si los sitios web continúan cargándose y el filtro no registra nada, la red falla en modo abierto (fail open). Verifique los campos DNS del DHCP, las listas de reenviadores ascendentes y cualquier configuración fija en el dispositivo. Repita la prueba bloqueando un resolutor de filtrado a la vez para confirmar que la redundancia funciona correctamente.
¿Es suficiente el filtrado DNS por sí solo o necesito una pasarela web segura?
El filtrado DNS cubre la protección contra amenazas y las directivas de contenido para la mayoría de las redes de invitados y recintos, pero no incluye la inspección completa de URL ni la prevención de pérdida de datos. Detecta nombres de dominio, no rutas ni contenidos de archivos. Si necesita este tipo de controles, añada una pasarela web segura (SWG) en los dispositivos gestionados. Consulte [Filtrado DNS frente a pasarela web segura](guide:dns-filtering-vs-secure-web-gateway) para ver dónde se sitúa el límite.