ExplainerDNS filtering limits
Filtro DNS fail open vs fail closed: qué sucede cuando el filtro se cae
Usted podrá decidir cómo deben comportarse sus redes WiFi para invitados y WiFi para empleados cuando el filtro DNS deje de responder, y verificar si su red realmente falla en modo fail closed. Sabrá dónde se oculta el mecanismo de respaldo en DHCP, reenviadores y dispositivos, y cómo probar la redundancia antes de...
El filtrado DNS con fallo abierto (fail open) o fallo cerrado (fail closed) es la decisión sobre qué hace una red cuando su resolutor de filtrado deja de responder. El fallo abierto recurre a un resolutor sin filtrado, por lo que la navegación continúa sin protección. El fallo cerrado no envía consultas a ningún otro lugar, de acuerdo con el control SC-24 de NIST SP 800-53 (fallo en un estado conocido), por lo que nada se resuelve sin filtrado.
¿Qué es el filtrado DNS con fallo abierto frente a fallo cerrado?
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 de DNS de protección verifica ese nombre frente a la inteligencia de amenazas y su política de contenido. Luego devuelve la dirección real, una dirección de página de bloqueo o una denegación.
Esta ubicación es la razón por la que funciona el filtrado DNS. La comprobación se realiza antes de que un solo paquete llegue al destino. Puede detener un enlace de phishing o una devolución de llamada de malware que un firewall vería únicamente como tráfico permitido en el puerto 443. El Centro Nacional de Ciberseguridad del Reino Unido opera un servicio de DNS de protección para el sector público bajo este mismo principio.
Esa ubicación también es el 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.
- Fallo abierto. 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 vuelva el filtro.
- Fallo cerrado. No existe una ruta sin filtrado. Las nuevas búsquedas esperan a que responda un resolutor de filtrado y nada se resuelve sin una decisión de política.
La elección es una compensación entre disponibilidad y certeza. El fallo abierto favorece al visitante que desea que se cargue una página de inmediato. El fallo cerrado favorece a su equipo de seguridad, al responsable de protección y al auditor, quienes necesitan demostrar que la red estuvo filtrada cada minuto del año.
NIST SP 800-53 Rev. 5 define la misma idea en dos controles. SC-24 es "fallo en un estado conocido" y SC-7(18) es "fallo seguro" (NIST SP 800-53 Rev. 5).
¿Cómo funciona el comportamiento de fallo del filtro en el resolutor?
Su configuración decide el comportamiento de fallo del filtro, no el filtro en sí. Se establece en tres lugares: el DHCP, cualquier reenviador de DNS local y el dispositivo.
Los campos DNS del DHCP
DHCP es el protocolo que entrega a cada dispositivo su dirección IP y configuración de red cuando se conecta. La mayoría de las redes de invitados y empleados lo utilizan para proporcionar a cada dispositivo dos o más direcciones de servidores DNS. Si todas apuntan a resolutores de filtrado, el diseño es de fallo cerrado. Si la segunda apunta a un ISP o resolutor público, el diseño es de fallo abierto, 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 a los resolvedores ascendentes. Aquí, el respaldo reside en la lista ascendente del reenviador. Un reenviador que enumera un resolvedor público debajo del filtro falla en modo abierto, incluso si el DHCP parece correcto.
El comportamiento propio del dispositivo
La selección del resolvedor varía según el sistema operativo. Algunos dispositivos tratan al segundo servidor como un respaldo estricto. Otros lo consultan cada vez que el primero responde lento, o envían consultas a ambos. En un diseño de fallo abierto, las respuestas sin filtrar pueden filtrarse incluso si el filtro funciona perfectamente.
Cómo se ve el fallo cerrado
En un diseño de fallo cerrado, cada dirección DNS que un dispositivo o reenviador puede usar apunta a un resolvedor de filtrado con la misma política. Si uno deja de responder, el dispositivo reintenta con el siguiente. La búsqueda falla únicamente cuando todos los resolvedores de filtrado quedan inaccesibles. El dispositivo recibe entonces un tiempo de espera agotado o SERVFAIL, la respuesta estándar de "falla del servidor" DNS, en lugar de una respuesta sin filtrar.
Diagrama de flujo que muestra un dispositivo reintentando un segundo resolvedor de filtrado después de que el primero falla, la política permitiendo o bloqueando el dominio, y una ruta punteada donde todos los resolvedores fallan y no se abre ninguna conexión.
Connections
- Dispositivo to Resolvedor de filtrado 1 (1. Consulta)
- Dispositivo to Resolvedor de filtrado 2 (2. Reintentar en el siguiente filtro)
- Resolvedor de filtrado 2 to Verificación de política (3. Aplicar política de red)
- Verificación de política to Respuesta limpia (4a. Dominio permitido)
- Verificación de política to Respuesta de bloqueo (4b. Amenaza o categoría bloqueada)
- Dispositivo to Sin respuesta (Si todos los filtros fallan)
Hecho correctamente, el fail closed no es frágil. La resiliencia proviene de resolvedores de filtrado redundantes, no de una salida de emergencia sin filtrar.
Fail open, fail closed, fail secure: ¿qué términos se confunden?
Cuatro términos cercanos aparecen en documentos de proveedores, hallazgos de auditoría y tickets de cambio. Describen cosas diferentes, y mezclarlos conduce a un diseño incorrecto.
| Término | Lo que describe | Durante una interrupción del filtro | Riesgo que conlleva |
|---|---|---|---|
| Fail open | Las consultas recurren a un resolutor no filtrado cuando el filtro no está accesible | La navegación continúa sin filtrado | Las amenazas y categorías bloqueadas se resuelven sin directiva y a menudo sin registro |
| Fail closed | Solo están configurados resolutores filtrados, sin respaldo no filtrado | Las nuevas búsquedas fallan hasta que responda un resolutor filtrado | La disponibilidad depende de la redundancia del filtro |
| Fail secure (NIST SC-7(18)) | Término del marco de control: un dispositivo de límite no debe entrar en un estado inseguro al fallar | Mismo resultado práctico que fail closed | Los auditores pueden pedirle evidencia de ello |
| Serve-stale (RFC 8767) | Un resolutor responde desde el caché caducado cuando los servidores ascendentes son inaccesibles | Los dominios visitados recientemente continúan resolviéndose | Las respuestas reflejan la última decisión, no una verificación de política 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 demasiado estricta |
| Bypass | Un dispositivo ignora el resolutor de red mediante DNS codificado de forma rígida, DoH o DoT | No se ve afectado, porque carece de filtrado todo el tiempo | Requiere controles de egreso, no una configuración de fallo |
Fail closed no es denegación por defecto
La denegación por defecto (default deny) es una elección de política sobre dominios no categorizados. Se ejecuta mientras el filtro está funcionando correctamente. Fail closed trata sobre lo que sucede 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
El RFC 8767 permite que un resolutor responda desde el caché caducado cuando no puede comunicarse con los servidores ascendentes. Esto mantiene funcionando los nombres populares durante interrupciones breves. Vuelve a aplicar la última decisión, por lo que un dominio que se haya vuelto malicioso desde entonces no se detecta.
La omisión 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 toca su filtro. Las configuraciones de fail closed no tienen efecto sobre esto. La omisión se gestiona mediante reglas de egreso.
¿Dónde se encuentra una interrupción del filtrado de DNS en la práctica?
Una interrupción del filtrado de DNS solo importa cuando el enlace a internet está activo pero el filtro resulta inaccesible. Si se cae todo el enlace ascendente, ambos modos se ven iguales. En la práctica, la diferencia surge a través de eventos operativos habituales:
- 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 aguas arriba;
- un cambio de enrutamiento en una WAN de sucursal que envía el DNS por la ruta equivocada;
- un contratista que edita un alcance DHCP y añade un resolvedor público "por resiliencia";
- un incidente en el propio proveedor de filtrado.
Cada uno de estos parece inofensivo en una red que falla en modo cerrado. Cada uno elimina la protección silenciosamente en una red que falla en modo abierto.
Redes WiFi de cortesía en hospitalidad
Los hoteles y grupos de pubs aplican políticas de contenido para mantener la red WiFi de invitados apta para familias y segura contra malware. Una red de invitados que falla en modo abierto elimina esa política sin avisar a nadie. Para los grandes operadores de hospitalidad, una falla en la política en el WiFi público conlleva un riesgo de marca además del riesgo de seguridad.
Sector salud
Shield bloquea alrededor de 241,000 amenazas a la semana en St George's Healthcare NHS Trust. Según nuestras cuentas, eso da un promedio de unas 1,400 por hora. Una ventana de fallo en modo abierto de una hora permitiría que esas búsquedas se resolvieran sin control en todos 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 administrados. En una terminal, una brecha de fallo en modo abierto significa una red pública no filtrada en horas pico de volumen.
Redes corporativas y de personal
Las redes del personal elevan las exigencias de disponibilidad. Las aplicaciones empresariales deben seguir funcionando, por lo que el fallo en modo cerrado necesita una redundancia real que lo respalde. 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 un nivel superior sin filtrar.
¿Cuáles son los límites y casos especiales del DNS con fallo en modo cerrado?
El fallo en modo cerrado es la opción predeterminada correcta para la mayoría de las redes WiFi de personal e invitados. Aun así tiene límites, y debe conocerlos antes de diseñar en función de él.
El fallo en modo cerrado con un solo resolvedor es un plan de interrupción
Si la red enumera una sola dirección de filtrado, el fallo en modo cerrado significa que cada interrupción de esa dirección deshabilita el DNS. La redundancia entre múltiples resolvedores de filtrado es lo que hace que el fallo en modo cerrado sea viable. 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 de DNS incluye un TTL (tiempo de vida), el número de segundos que un dispositivo o resolvedor puede guardarla en caché. Durante una interrupción breve, los nombres guardados en caché siguen funcionando y los nuevos fallan. Los visitantes perciben esto como "algunos sitios funcionan y otros no", lo que puede confundir a su mesa de ayuda.
Los Portales Cautivos necesitan DNS antes del inicio de 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 jardín amurallado 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.
Una falla se ve diferente a un bloqueo
Un dominio bloqueado debe devolver una página de bloqueo o una negativa clara. Una búsqueda fallida devuelve un tiempo de espera agotado (timeout) o SERVFAIL. RFC 8914 Extended DNS Errors agrega códigos que los diferencian, como Bloqueado (15) y Filtrado (17) frente a Sin Autoridad Alcanzable (22). Informe a su equipo de soporte sobre ambos, para que puedan distinguir un bloqueo por directiva de una interrupción del servicio.
DNS no puede ver más allá del nombre
El modo fail closed garantiza una decisión de directiva en cada búsqueda, no una cobertura total. Las conexiones a direcciones IP puras omiten DNS por completo. Las conexiones que ya estaban abiertas antes de la interrupción continúan. 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 conocer cómo encajan estos límites en una arquitectura más amplia, consulte ¿es suficiente el filtrado DNS? y el resumen de límites del filtrado DNS.
¿Cómo se relaciona el DNS fail closed con Purple Shield?
Purple Shield es DNS de protección y filtrado de contenido para cualquier red. Shield funciona en modo fail closed, por lo que una interrupción nunca deja una red sin filtrar. Cada búsqueda recibe una decisión de directiva o ninguna respuesta, pero nunca una sin verificar.
Puede ejecutar Shield de forma independiente en cualquier red WiFi o junto con Purple Access. Usted define una directiva por red y por VLAN (virtual LAN, una red lógicamente separada en hardware compartido). Las redes de invitados, personal y administración en un mismo sitio pueden tener reglas diferentes. Shield no requiere hardware nuevo y se ubica 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 ubicación se aplica a los tres. La pregunta que se debe hacer a cada proveedor es dónde reside la alternativa en caso de falla. Pregunte cómo se comportan sus agentes errantes cuando los resolutores no están disponibles y cuántas direcciones de filtrado se pueden configurar. Luego, verifique que la configuración de su propio DHCP y reenviador no vuelva a introducir una ruta no filtrada.
Shield funciona 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 de implementación. La guía de seguridad WiFi empresarial muestra dónde se ubica el filtrado DNS junto a la identidad y la segmentación.
Este concepto se pone a prueba durante la ventana de cambios, no en el folleto. La regla del firewall, la edición de DHCP o la secundaria pública "resiliente" determinan si su red permanece filtrada. Audite esas tres configuraciones este trimestre. A continuación, lea DNS sobre TLS y filtrado: qué cambia con el puerto 853, ya que un resolutor con fallo seguro sólo protege a los dispositivos que realmente lo utilizan.
Preguntas frecuentes
¿El DNS con fallo seguro significa que una interrupción dejará mi WiFi fuera de línea?
No, no cuando el filtro se ejecuta en resolutores redundantes. El fallo seguro sólo detiene las nuevas búsquedas cuando todos los resolutores de filtrado no están disponibles al mismo tiempo. Los dispositivos reintentan primero con la siguiente dirección de filtrado. Las respuestas almacenadas en caché permiten que los sitios visitados recientemente se sigan resolviendo durante interrupciones breves. Diseñe la redundancia antes de la puesta en marcha y, a continuación, pruébela bloqueando un resolutor a la vez desde un VLAN de prueba.
¿Shield funcionará con los puntos de acceso y firewalls que ya poseo?
Sí. Shield filtra en la resolución DNS, por lo que no necesita 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. Usted orienta el DNS de cada red o VLAN hacia Shield, elimina cualquier respaldo no filtrado y aplica una directiva por red. La página del producto cubre los pasos.
¿Cómo se calcula el precio de Shield?
Purple cotiza Shield para su propiedad en lugar de publicar un precio de lista 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 lo tanto, la cotización refleja sus redes y establecimientos, no hardware nuevo. Solicite una cotización indicando su número de establecimientos, su recuento de redes y VLAN, y si ya utiliza Purple.
¿Cómo migro desde DNSFilter o Cisco Umbrella sin interrumpir 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 registros, y luego mueva las redes en producción dentro de una ventana de cambios. Elimine por completo las direcciones del resolutor anterior en lugar de dejarlas como DNS secundario. Verifique también los agentes de roaming en los dispositivos del personal, ya que sus configuraciones de respaldo se encuentran fuera de su alcance DHCP.
¿Existe alguna normativa que exija el filtrado DNS con fallo seguro?
Ninguna normativa menciona expresamente el DNS con fallo seguro, 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 cubre el fallo en un estado conocido. SC-7(18) cubre la protección perimetral con fallo seguro. El filtrado con fallo seguro le proporciona evidencia de que la directiva se aplicó en todo momento, lo que resulta útil cuando lo solicitan los auditores o los responsables de protección.
¿Cómo pruebo el comportamiento actual de fallo de mi filtro?
Bloquee el DNS saliente hacia sus resolutores de filtrado desde un solo VLAN de prueba y observe cómo responde un dispositivo. Si los sitios web continúan cargándose y el filtro no registra nada, la red tiene un fallo abierto. Verifique los campos DNS de DHCP, las listas de reenvío ascendente y cualquier configuración del dispositivo codificada de forma rígida. Repita bloqueando un resolutor de filtrado a la vez para confirmar que la redundancia funcione correctamente.
¿El filtrado DNS es suficiente por sí solo o necesito un gateway web seguro?
El filtrado DNS cubre la protección contra amenazas y las políticas de contenido para la mayoría de las redes de invitados y recintos, pero no 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 esos controles, agregue un gateway web seguro en los dispositivos administrados. Consulte Filtrado DNS vs gateway web seguro para conocer dónde se ubica la diferencia.
Key terms
- DNS de protección
- Un resolutor recursivo que verifica cada dominio consultado contra la inteligencia de amenazas y las directivas de contenido antes de responder, devolviendo la dirección real, la dirección de una 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 opera un servicio de DNS de protección para el sector público basado en este principio. Es el control cuyo modo de falla rige esta decisión.
- Falla abierta
- Un diseño en el que las consultas DNS recurren a un resolutor que no aplica ninguna directiva cuando el resolutor con filtrado no está accesible. La resolución continúa, pero el bloqueo de amenazas, las reglas de contenido y el registro de eventos se detienen. Por lo general, se encuentra como un resolutor público o del ISP en el campo DHCP secundario o en una lista ascendente de reenviadores. A menudo se introduce por accidente durante un cambio.
- Falla cerrada
- Un diseño en el que cada dirección DNS que un dispositivo o reenviador puede utilizar apunta a un resolutor con filtrado que aplica la misma directiva. Una búsqueda falla con un tiempo de espera agotado o un error SERVFAIL únicamente cuando todos los resolutores con filtrado se encuentran inaccesibles. Este es el valor predeterminado correcto para la mayoría de las redes WiFi para invitados y WiFi para empleados, siempre que cuenten con resolutores de filtrado redundantes.
- Falla segura (NIST SC-7(18))
- Mejora de protección de perímetro SC-7(18) del NIST SP 800-53 Rev. 5, que requiere que un dispositivo perimetral evite entrar en un estado no seguro cuando falla. Es posible que los auditores le pidan demostrarlo. El filtrado DNS fail closed ofrece en la práctica el mismo resultado.
- Falla en estado conocido (NIST SC-24)
- Control SC-24 del NIST SP 800-53 Rev. 5, el cual requiere que los sistemas mecanicen sus fallas en un estado conocido y definido, en lugar de uno impredecible. Ninguna norma menciona explícitamente el DNS en modo fail closed, pero este control es el lenguaje del marco de referencia que se cita al justificarlo ante auditores o responsables de protección.
- Servicio de datos obsoletos (Serve-stale)
- Comportamiento del RFC 8767 que permite a un resolutor responder desde la caché caducada cuando no puede alcanzar los servidores ascendentes, manteniendo operativos los nombres resueltos recientemente. Mitiga las interrupciones breves, pero vuelve a aplicar la última decisión, por lo que un dominio que se haya vuelto malicioso desde entonces no será detectado.
- SERVFAIL
- El código de respuesta de falla del servidor en el formato de mensajes DNS definido en RFC 1035, que se devuelve cuando un resolutor no puede completar una búsqueda. En una red con bloqueo por falla, es lo que recibe un dispositivo cuando todos los resolutores de filtrado están fuera de servicio. Su mesa de ayuda debe diferenciarlo de un bloqueo de política.
- Errores extendidos de DNS
- Códigos RFC 8914 que añaden detalles a las respuestas de DNS, incluidos Bloqueado (15), Filtrado (17) y Autoridad no alcanzable (22). Permiten que el personal de soporte y las herramientas distingan un bloqueo de política de una interrupción del servicio al diagnosticar reportes de sitios que no cargan.
- TTL (tiempo de vida)
- El campo en cada registro de recurso DNS, definido en RFC 1035, que especifica la cantidad de segundos que un dispositivo o resolutor puede almacenar en caché la respuesta. Durante una interrupción breve, los nombres almacenados en caché siguen funcionando y los nuevos fallan. Los visitantes lo reportan como si algunos sitios funcionaran y otros no.
- Reenviador de DNS
- Un servicio DNS en un firewall, puerta de enlace o servidor interno que recibe consultas de dispositivos y las reenvía a una lista configurada de resolutores ascendentes. La alternativa secundaria reside en su lista ascendente. Un resolutor público en esa lista permite el paso por falla aunque el DHCP esté limpio, incluida la capa detrás del DNS interno en las 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 resolutor seleccionado y pueden desviar el tráfico sin pasar por el resolutor de la red. Estos representan evasiones, no fallas. Las configuraciones de bloqueo por falla no tienen efecto sobre ellos, por lo que debe controlarlos mediante reglas de salida.
- Portal cautivo
- La página de inicio que ve un invitado antes de conectarse a Internet. El dispositivo debe resolver el portal y los dominios del jardín amurallado antes de autenticarse. Un resolutor previo al inicio de sesión sin filtrar convierte al portal en una brecha de seguridad. Una red de portal cautivo con bloqueo por falla y sin redundancia impide que los invitados inicien sesión.
- Denegación predeterminada
- Una política 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 falla. A menudo se confunde con el bloqueo por falla. Usted puede ejecutar un bloqueo por falla con una política permisiva o un paso por falla con una estricta.
Worked examples
¿Un contratista añade un resolutor público al alcance DHCP de una red de invitados como DNS secundario para brindar resiliencia. El resolutor con filtrado se mantiene como primario. ¿La red sigue estando protegida?
No. Un resolutor público en el campo secundario convierte el diseño en fail open. Algunos sistemas operativos consultan ese segundo servidor siempre que el primero responde con lentitud, por lo que pueden filtrarse búsquedas sin filtrar a diario, no solo durante las interrupciones. Para confirmarlo, bloquee el tráfico DNS saliente hacia los resolutores de filtrado desde un solo VLAN de prueba. Si los sitios aún cargan y el filtro no registra nada, la red falla en modo fail open. Reemplace la dirección pública con un segundo resolutor de filtrado que contenga la misma directiva. Luego, revise las listas de reenviadores ascendentes y las configuraciones de dispositivos programadas de forma rígida para detectar la misma falla. Por último, bloquee un resolutor de filtrado a la vez para demostrar que la redundancia funciona.
Usted está migrando las redes de invitados y empleados desde DNSFilter o Cisco Umbrella a Purple Shield. ¿Cómo evita una interrupción en el filtrado durante la transición?
Realice la transición de una red o VLAN a la vez. Comience apuntando el DNS DHCP de un VLAN de prueba hacia Shield, luego confirme que los bloqueos y registros aparezcan como se espera. Traslade las redes activas en una ventana de mantenimiento una vez que la prueba sea exitosa. Elimine por completo las direcciones del resolutor anterior en lugar de dejarlas como DNS secundario. Un DNS secundario remanente vuelve a introducir una ruta no filtrada o inconsistente. Revise también los agentes itinerantes en los dispositivos de los empleados, ya que sus configuraciones de respaldo se encuentran fuera del alcance de su DHCP. Este enfoque mantiene cada búsqueda bajo una decisión de directiva a lo largo de toda la migración. Asimismo, deja intacto el comportamiento fail closed de Shield una vez que el proveedor anterior ha sido eliminado.
Frequently asked questions
¿El DNS con bloqueo por falla significa que una caída del servicio dejará mi WiFi fuera de línea?
No, no cuando el filtro funciona en resolutores redundantes. El bloqueo por falla solo interrumpe las nuevas búsquedas cuando todos los resolutores de filtrado están inaccesibles al mismo tiempo. Los dispositivos intentan primero la conexión 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 luego pruébela bloqueando un resolutor a la vez desde un VLAN de prueba.
¿Shield funcionará con los puntos de acceso y firewalls que ya poseo?
Sí. Shield filtra a nivel de resolución DNS, por lo que no requiere hardware adicional y funciona de manera independiente en cualquier red WiFi. Purple funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Solo debe apuntar el DNS de cada red o VLAN hacia Shield, eliminar cualquier alternativa sin filtrar y aplicar una política por red. La página del producto explica los pasos a seguir.
¿Cómo se calcula el precio de Shield?
Purple cotiza Shield para sus instalaciones en lugar de publicar una lista de precios 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 lo tanto, la cotización refleja sus redes y sucursales, no hardware nuevo. Solicite una cotización indicando la cantidad de sucursales, su red y la cantidad de VLAN, así como si ya utiliza Purple.
¿Cómo puedo migrar desde DNSFilter o Cisco Umbrella sin interrumpir el filtrado?
Migre una red o VLAN a la vez. Apunte el DNS DHCP de un VLAN de prueba a Shield, confirme los bloqueos y registros, y luego mueva las redes activas en una ventana de mantenimiento. Elimine por completo las direcciones del solucionador antiguo en lugar de dejarlas como DNS secundario. Revise también los agentes de roaming en los dispositivos del personal, ya que sus configuraciones de reserva están fuera de su alcance DHCP.
¿Existe alguna regulación que exija el filtrado DNS de falla con bloqueo?
Ninguna normativa menciona expresamente el DNS de falla con bloqueo (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 cubre la falla en un estado conocido. SC-7(18) cubre la protección perimetral que falla de forma segura. El filtrado de falla con bloqueo le proporciona evidencia de que la política se aplicó en todo momento, lo que resulta útil cuando lo soliciten los auditores o los encargados de salvaguarda.
¿Cómo pruebo el comportamiento de falla de mi filtro actual?
Bloquee el DNS saliente hacia sus solucionadores de filtrado desde un solo VLAN de prueba y observe cómo reacciona un dispositivo. Si los sitios web continúan cargándose y el filtro no registra nada, la red falla sin bloqueo (fail-open). Verifique los campos DNS DHCP, las listas de reenviadores hacia arriba y cualquier configuración codificada en los dispositivos. Repita el proceso bloqueando un solucionador de filtrado a la vez para confirmar que la redundancia funcione.
¿Es suficiente el filtrado DNS por sí solo o necesito una pasarela web segura?
El filtrado DNS cubre la protección contra amenazas y la política de contenido para la mayoría de las redes de invitados y sucursales, pero no 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 esos controles, agregue una pasarela web segura (SWG) en los dispositivos administrados. Consulte [Filtrado DNS frente a pasarela web segura](guide:dns-filtering-vs-secure-web-gateway) para conocer los límites de cada solución.