DNS protectivo explicado: Cómo funciona y por qué es importante
Published
Un invitado en el lobby de un hotel toca un enlace y la página comienza a cargarse. Antes de que el navegador pueda conectarse al sitio web, el dispositivo del invitado necesita averiguar dónde se encuentra ese sitio en internet. Esa consulta silenciosa es una oportunidad para verificar si se debe permitir el acceso a ese destino.
Un DNS de protección agrega una decisión de seguridad a este paso rutinario. Puede ayudar a las organizaciones a proteger a las personas y los dispositivos en redes compartidas, pero funciona únicamente cuando su tráfico utiliza el resolvedor administrado. Comprender esa distinción facilita la planificación para el rendimiento, las excepciones, las rutas de evasión y la privacidad.
Tabla de contenido
- Por qué cada visita a un sitio web comienza con una búsqueda DNS
- Qué hace el DNS de protección en la etapa de resolución de nombres
- Cómo funciona la aplicación de políticas en toda una red
- Impacto en el rendimiento y mejoras medibles en la carga de páginas
- Casos de uso del mundo real en recintos y empresas
- Cómo elegir el enfoque adecuado para su red
- Cómo medir el valor del DNS de protección más allá del recuento de bloqueos
- Siguientes pasos para planificar el despliegue de su DNS de protección
Por qué cada visita a un sitio web comienza con una búsqueda DNS
El nombre de un sitio web es fácil de recordar para las personas. Las computadoras necesitan una dirección de red para conectarse. El Domain Name System (DNS) realiza la traducción, de manera muy similar a un directorio telefónico que convierte el nombre de una persona en un número al que se puede llamar.
Cuando el invitado toca el enlace, el navegador solicita a un resolutor DNS la dirección asociada con el nombre del sitio web. El resolutor busca la respuesta y la envía de vuelta. El navegador puede entonces intentar conectarse al destino. El DNS no transporta la página en sí, pero ayuda al dispositivo a encontrar dónde solicitarla.
Esa secuencia crea un punto de control de seguridad útil. Si el resolvedor reconoce un dominio solicitado como una amenaza conocida, puede negarse a proporcionar una respuesta útil antes de que el navegador se conecte. Un servicio de DNS de protección aplica políticas de seguridad en esta etapa de búsqueda, en lugar de esperar a un archivo descargado o a una acción sospechosa en el punto final.
La distinción práctica: El DNS ayuda a un dispositivo a encontrar un destino. El DNS de protección agrega una decisión sobre si la búsqueda debe tener éxito.
Esto es especialmente importante en lugares donde muchas personas y dispositivos comparten la infraestructura de red. Un hotel puede tener teléfonos de huéspedes, laptops del personal, terminales de pago y equipos conectados del edificio utilizando diferentes partes de la misma red general. Una oficina, una propiedad residencial o un espacio público enfrentan un desafío similar, aunque los usuarios y dispositivos sean distintos.
El DNS de protección puede ofrecer un punto de control común para esas búsquedas, pero no es un programa de seguridad completo. No protegerá a un dispositivo que evite el resolvedor gestionado, y no reemplaza la protección de endpoints, los controles de acceso o un diseño de red cuidadoso. Las preguntas útiles son cómo toma sus decisiones el resolvedor, cómo mantiene una organización los dispositivos en la ruta prevista y qué evidencia demuestra que el servicio está ayudando sin causar interrupciones.
Qué hace el DNS de protección en la etapa de resolución de nombres
El DNS de protección es un resolutor recursivo que aplica directivas. Un resolutor recursivo gestiona las solicitudes en nombre de un dispositivo, mientras que el DNS de protección aplica reglas para decidir si un destino solicitado debe recibir una respuesta DNS normal. No es simplemente un DNS más rápido o cifrado.
Siga una búsqueda de principio a fin:
- El dispositivo solicita un nombre de dominio. Un navegador, una aplicación u otro proceso necesita una dirección antes de intentar conectarse a un destino designado.
- El resolutor verifica la solicitud. Compara el dominio con las políticas configuradas y la inteligencia de amenazas. Las implementaciones más sólidas también pueden verificar una dirección IP resuelta, lo que ayuda a evaluar la infraestructura detrás de un nombre.
- El resolutor devuelve un resultado. Si la política permite la solicitud, el resolutor proporciona una respuesta. Si no lo hace, el servicio puede bloquear la resolución, devolver una respuesta vacía o redirigir al cliente a una página de advertencia. El comportamiento exacto depende del producto y de la política.
Algunas implementaciones buscan dominios generados algorítmicamente, o DGA, que el malware puede usar para encontrar infraestructura de comando y control. Los patrones inusuales en los caracteres de un dominio, incluida la alta entropía, pueden funcionar como una señal para una posterior evaluación de directivas. Ese tipo de análisis puede complementar las fuentes de inteligencia contra amenazas, pero las organizaciones aún deben validar cómo gestiona la detección y las excepciones el servicio elegido.
El cifrado y la autenticidad no son lo mismo que una decisión de seguridad
DNSSEC ayuda a verificar la integridad y autenticidad de los datos DNS firmados. DNS over HTTPS (DoH) y DNS over TLS (DoT) protegen las consultas DNS en tránsito. Esas propiedades son importantes, pero por sí solas no determinan si un dominio existente es malicioso. El DNS de protección toma esa decisión de política en el resolvedor.
Para los equipos que revisan los controles sobre el acceso web y los servicios en la nube, esta distinción puede situarse junto con una orientación más amplia sobre la protección de entornos empresariales de Microsoft 365. El punto principal es evitar tratar el transporte cifrado o los datos autenticados como un sustituto de una decisión sobre el riesgo de destino.
Cómo funciona la aplicación de políticas en una red
Un resolutor puede tomar una decisión certera para una sola solicitud y aun así no proteger una red si los dispositivos pueden enrutar el DNS para eludirlo. Por lo tanto, la implementación en toda la infraestructura se trata de dos elementos conectados: directivas consistentes y una ruta confiable hacia el resolutor.
Un diseño centralizado envía solicitudes DNS de múltiples sitios a un servicio administrado. Esto facilita la aplicación de reglas compartidas y la revisión de la actividad en todas las ubicaciones. También convierte a la disponibilidad en un requisito de seguridad. Si el resolvedor no está localizable, el acceso web ordinario y los servicios que dependen del DNS pueden fallar incluso cuando el resto de la red esté funcionando.
El servicio de DNS de protección del gobierno de EE. UU. estuvo disponible para las agencias del Federal Civilian Executive Branch en septiembre de 2022. Para agosto de 2024, más de 104 agencias se habían incorporado, generando un promedio de 1,600 millones de consultas DNS seguras al día; el programa reportó un 99.999% de tiempo de actividad del resolutor (hoja informativa sobre DNS de protección de CISA). La lección operativa es que la calidad del filtrado y la disponibilidad del servicio deben evaluarse de forma conjunta.
Aplique la identidad sin multiplicar las políticas
El personal, los invitados, los residentes y el equipo conectado no necesitan necesariamente las mismas reglas. Una red puede asignar diferentes políticas basadas en la identidad o el segmento de red, como una red para el personal, WiFi para invitados y una red aislada para dispositivos del edificio. El objetivo es hacer que la política se adapte al usuario o dispositivo manteniendo una administración manejable.
Los controles de acceso ayudan a establecer esa separación, mientras que el monitoreo del tráfico de red puede ayudar a los equipos a investigar la actividad inusual en la red. Para ver cómo se integra el control de acceso a la red en un entorno gestionado, consulte estas soluciones de control de acceso a la red.
Cierre las rutas de omisión deliberadamente
Si un dispositivo puede enviar DNS ordinario directamente a un resolutor externo, es posible que el servicio de protección nunca vea la solicitud. DoH y DoT generan otro desafío: el cifrado puede proteger las consultas en tránsito, pero un resolutor no administrado también puede dejarlas fuera de la visibilidad y las directivas de la organización.
Donde se requiera la aplicación de políticas, los equipos deben identificar las rutas DNS directas y los destinos DNS cifrados no autorizados, y luego decidir cómo los manejarán los controles de red, endpoint y navegador. Pruebe también las excepciones. Los Captive Portals, los dispositivos móviles, IPv6 y las aplicaciones con sus propias configuraciones de resolvedor pueden comportarse de manera diferente a la de una laptop gestionada en una red corporativa. La directiva funciona únicamente en las rutas que la organización puede gobernar.
Impacto en el rendimiento y mejoras medibles en la carga de páginas
Un servicio de DNS de protección no tiene por qué ralentizar la navegación de forma perceptible. El impacto depende menos del acto de filtrado que de decisiones de diseño prácticas: dónde se ubica el resolutor, cómo almacena en caché las respuestas, cómo mantiene las conexiones y si los dispositivos lo omiten.
El DNS cifrado puede agregar tiempo de configuración cuando una conexión necesita establecer TCP, TLS o HTTP antes de enviar una consulta. Reutilizar una sesión persistente evita repetir gran parte de esa configuración. TLS 1.3, 0-RTT, la multiplexación HTTP/2 y QUIC también pueden reducir la sobrecarga de conexión, según mediciones independientes del rendimiento de DNS cifrado. Bajo condiciones de red saludables, la latencia de búsqueda sin procesar puede ser insignificante, pero esto no está garantizado para todos los clientes o rutas de red.
Pruebe la búsqueda, no solo la impresión
Un resolutor cercano y de alta disponibilidad, junto con un almacenamiento en caché conforme a los estándares, ayuda a mantener la rapidez en las consultas habituales. Sin embargo, una cifra promedio de latencia puede ocultar experiencias lentas para un subconjunto de usuarios, o cuando el resolutor debe obtener una respuesta que aún no está almacenada en caché.
Mida la latencia de consulta p50, p90 y p99 por separado para memorias caché frías y calientes. La mediana muestra una consulta típica; los percentiles más altos revelan casos más lentos que pueden afectar a los usuarios con mayor severidad. Mantenga la velocidad de consulta independiente del tiempo total de carga de la página, ya que el DNS es solo una parte del recorrido del navegador.
Incluya las condiciones que exponen imprevistos
Realice pruebas desde los tipos de redes y dispositivos que utiliza la gente, incluidos clientes móviles, IPv6 y Captive Portals. Verifique las aplicaciones y navegadores que puedan seleccionar su propio servicio DoH o DoT, ya que pueden cambiar tanto la ruta como la visibilidad de las solicitudes DNS.
DoQ, DNS over QUIC, se ha observado en mediciones distribuidas para aproximarse al rendimiento de texto plano y mejorar algunos casos de carga de páginas en comparación con DoH. Considere estos hallazgos como una razón para probar las opciones de transporte en su propio entorno, no como una promesa de un resultado en particular. El objetivo práctico es un solucionador cercano, un almacenamiento en caché eficaz, sesiones cifradas reutilizables y un diseño que no deje abiertas rutas no gestionadas.
Casos de uso del mundo real en recintos y empresas
Un despliegue nacional muestra lo que el DNS de protección puede hacer cuando muchas organizaciones comparten una capa de seguridad gestionada. En el Reino Unido, el número de organizaciones que utilizan el servicio Protective Domain Name System aumentó de 944 a 1,173 en 2022, un incremento del 24%. A lo largo de ese año, el servicio procesó aproximadamente 0.55 billones de consultas DNS y bloqueó 11,000 millones de solicitudes asociadas con destinos maliciosos, alrededor del 2% de todas las consultas (resumen de PDNS de la UK NCSC).
Esa escala ilustra el valor de tomar una decisión antes de intentar una conexión. No demuestra que cada solicitud bloqueada se habría convertido en un incidente, o que el DNS por sí solo haya detenido cada ruta hacia una amenaza. Para un operador multisitio, la comparación útil es si el servicio puede aplicar la política de manera constante, generar telemetría útil y manejar el volumen y las excepciones de ese entorno.
Considere cómo el mismo punto de control se adapta a distintos recintos:
- Hoteles y propiedades residenciales: Separe el acceso de invitados o residentes de los dispositivos del personal y del edificio. Un Captive Portal, un dispositivo antiguo o el resolvedor cifrado preferido de un residente pueden crear una excepción que se deba planificar.
- Aeropuertos y estadios: Aplique una base común en el acceso público de alta rotación mientras mantiene separadas las redes operativas y del personal. Manténgase al tanto de los dispositivos no gestionados y las necesidades de conectividad que requieran una excepción documentada.
- Sector salud y educación: Restrinja el acceso a destinos nocivos sin bloquear los servicios legítimos utilizados para la atención médica, la enseñanza o la administración. Proporcione una ruta de revisión clara cuando una política bloquee algo necesario para el trabajo.
- Retail y centros comerciales: Distinga el tráfico de visitantes del de las cajas registradoras, los dispositivos del personal y otros equipos operativos. Los equipos de retail que planifican el acceso de invitados también pueden encontrar útiles estas soluciones de retail WiFi al reflexionar sobre cómo se articulan el acceso y las políticas.
Una breve introducción al tema también puede ayudar a los equipos a alinearse sobre lo que hace y no hace la capa DNS:
En cada entorno, el filtrado de DNS es un control parcial, no una garantía de que se detenga cada amenaza. Un usuario puede llegar a la infraestructura a través de otro solucionador o una dirección IP directa, y una aplicación puede utilizar protocolos que no dependen de la ruta DNS de la organización. La implementación necesita un manejo de excepciones y monitoreo junto con la propia política.
Cómo elegir el enfoque adecuado para su red
El DNS de protección funciona en el resolutor. Los agentes de endpoint, la configuración del navegador y los controles de red operan en diferentes puntos, por lo que los equipos suelen elegir una combinación en lugar de un sustituto único. La mezcla adecuada depende de quién administra el dispositivo, qué tráfico puede ver la red y cómo deben gestionarse las excepciones.
| Control | Mejor opción | Visibilidad | Limitación común |
|---|---|---|---|
| DNS de protección | Redes compartidas, instalaciones gestionadas y aplicación de políticas de DNS | Solicitudes de DNS que pasan a través del resolutor | Los resolutores no gestionados y las rutas que no son de DNS pueden eludirlo |
| Agente de punto final | Laptops gestionadas y dispositivos móviles que necesitan protección fuera de la red | Actividad visible para el agente instalado | La cobertura depende de la instalación, el estado y la gestión del agente |
| Política de navegador | Navegadores gestionados donde se pueden regular las configuraciones de navegación y del resolutor | Configuración del navegador y actividad del navegador seleccionada | No regula todas las aplicaciones ni los navegadores no gestionados |
| Controles a nivel de red | Redes segmentadas y tráfico que pasa a través de la infraestructura gestionada | Flujos de red dentro de la cobertura del control | El tráfico cifrado o fuera de la red puede limitar la inspección |
| Controles de identidad y acceso | Personal, invitados, residentes y grupos de dispositivos con necesidades de acceso distintas | Decisiones de conexión y acceso vinculadas a la identidad o segmento | Una conexión permitida no evalúa por sí misma cada destino |
Para las laptops gestionadas, los controles de endpoints y navegadores pueden complementar la política del solucionador, especialmente cuando los empleados trabajan fuera de la oficina. El WiFi para invitados y BYOD son más difíciles de gestionar con agentes, lo que hace que los controles del lado de la red sean más prácticos, siempre que la organización pueda dirigir el DNS a su servicio elegido. Los dispositivos IoT y residenciales a menudo necesitan segmentación y una política que tenga en cuenta las opciones limitadas de gestión de dispositivos.
Para los equipos que comparan la identidad de la red, el filtrado y las comprobaciones orientadas al usuario, las comprobaciones gratuitas de DNS y correo electrónico de mailX pueden ser un recurso relevante junto con una revisión más amplia de los controles de acceso. Si los entornos de pago forman parte de la infraestructura, considere también cómo el diseño de WiFi y los requisitos de cumplimiento PCI afectan la separación y la administración de la red.
Purple Access combina opciones de red abiertas, seguras y xPSK en los puntos de acceso existentes, con incorporación mediante Captive Portal y asignación de red basada en identidades. Purple Shield agrega DNS de protección y filtrado de contenido con controles por directiva. Esas capacidades pueden coexistir junto con los controles de endpoint y navegador, pero no eliminan la necesidad de definir la aplicación del resolutor, las excepciones y el monitoreo. Elija las herramientas en función de las rutas y los dispositivos que necesita proteger, y luego verifique que sus directivas funcionen juntas.
Medición del valor del DNS de protección más allá de las cifras de bloqueos
El total de consultas bloqueadas indica que el resolutor actuó. Por sí solo, no indica si interceptó las solicitudes correctas, si interrumpió trabajo útil o si omitió tráfico que tomó otra ruta. Cuente la decisión, pero mida el control.
El taller de DNS de la European Internet Industry Association reportó 2.3 millones de reportes de abuso que abarcan 780,000 dominios únicos durante los seis meses anteriores, con reportes mensuales que aumentaron de 220,000 a 380,000 (reporte del taller). Esas cifras muestran la escala del abuso reportado. No establecen cuántos incidentes evitó un resolutor, si un bloqueo fue correcto o si el tráfico afectado llegó a un destino a través de una VPN, un resolutor alternativo, una dirección IP integrada en el código o un protocolo de aplicación cifrado.
Cree un cuadro de mando basado en resultados y excepciones
Una revisión útil combina seguridad, calidad del servicio y respuesta operativa. Monitoree si el resolvedor detectó dominios maliciosos conocidos, la rapidez con la que los equipos gestionan las apelaciones de falsos positivos y si los cambios de política llegan a las ubicaciones previstas de manera oportuna. Combine esas medidas con la disponibilidad del resolvedor y la latencia de búsqueda media y final.
Mida también los intentos de evasión. Un número bajo de solicitudes bloqueadas puede significar que el entorno tiene poca actividad maliciosa, o que los dispositivos no están utilizando el resolvedor de protección. Correlacione los eventos relevantes con la identidad de la red, como un SSID, VLAN, ubicación o grupo de usuarios, para que los investigadores puedan ver dónde se aplica una directiva y dónde puede estar ocultándose una excepción. Compare la actividad de DNS con los datos de endpoints o de incidentes en lugar de afirmar que cada búsqueda bloqueada representa un incidente evitado.
Trate los registros DNS como datos operativos sensibles
Los registros de DNS pueden revelar patrones de navegación, lo que exige precaución en entornos de salud, educación, hospitalidad y residenciales. Establezca límites de retención, restrinja el acceso por rol y mantenga la telemetría de seguridad separada de los datos de marketing de invitados. Decida quién puede investigar un evento de seguridad y qué datos necesita antes de recopilar registros a gran escala.
Próximos pasos para planificar el despliegue de su DNS protectiva
Comience con la ruta, no con el panel de control. Mapee qué dispositivos utilizan el resolvedor administrado, identifique dónde un DNS directo o un DNS cifrado no autorizado podrían eludirlo y decida cómo funcionará la aplicación para los dispositivos que la organización no administra. Incluya un proceso de excepción para los servicios legítimos que bloquee una política.
Antes del lanzamiento, acuerden cómo evaluará el equipo tanto la seguridad como la calidad del servicio:
- Confirmar el uso del resolutor: Verifique los dispositivos gestionados, las redes de invitados y los dispositivos menos predecibles, como IoT.
- Probar la ruta de la red: Donde se requiera la aplicación, revise el DNS directo y las rutas de DNS cifrado no autorizadas.
- Medir el rendimiento: Compare la latencia de búsqueda en caché fría y caliente, incluidos los percentiles más lentos.
- Definir la tarjeta de puntuación: Realice un seguimiento de la gestión de falsos positivos, la disponibilidad, la propagación de políticas, los intentos de elusión y los resultados de incidentes.
- Establecer reglas de privacidad: Establezca límites de acceso y retención de registros antes de comenzar una recolección amplia.
Para una implementación multisitio, reúna a los equipos de red y seguridad para mapear identidades, segmentos de red, rutas de resolvedores y las excepciones que requiere cada ubicación. Purple ofrece sesiones de diseño dirigidas por ingenieros de red para definir y validar los planes de implementación. El DNS de protección puede hacer que los destinos dañinos sean más difíciles de alcanzar a través de la ruta de búsqueda gestionada, pero no reemplazará la seguridad de endpoints, la segmentación de red ni la gobernanza de privacidad.
Purple Access admite redes WiFi abiertas, seguras y xPSK, con asignación de red basada en identidad e incorporación de invitados o dispositivos BYOD en los puntos de acceso existentes. Para planificar cómo estos controles de acceso pueden funcionar junto con el DNS de protección en sus instalaciones, visite Purple Access.
