DNS protectivo explicado: cómo funciona y por qué es importante
Published
Un invitado en la recepción 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 búsqueda silenciosa es una oportunidad para comprobar si se debe permitir el destino.
Protective DNS añade 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 solo funciona cuando su tráfico utiliza el resolvedor gestionado. Comprender esta distinción facilita la planificación de la eficacia, las excepciones, las rutas de omisión y la privacidad.
Índice de contenidos
- Por qué cada visita a un sitio web comienza con una búsqueda DNS
- Qué hace el DNS protectivo en la fase de resolución de nombres
- Cómo funciona la aplicación de directivas en una red
- Impacto en el rendimiento y mejoras medibles en la carga de páginas
- Casos de uso reales en recintos y empresas
- Cómo elegir el enfoque adecuado para su red
- Medición del valor del DNS protectivo más allá de los recuentos de bloqueos
- Siguientes pasos para planificar el despliegue de su DNS protectivo
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. Los ordenadores necesitan una dirección de red para conectarse. El Domain Name System (DNS) proporciona esta traducción, de forma muy similar a una guía telefónica que convierte el nombre de una persona en un número al que 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.
Esta secuencia crea un punto de control de seguridad muy útil. Si el resolvedor reconoce un dominio solicitado como una amenaza conocida, puede negarse a proporcionar una respuesta válida antes de que el navegador se conecte. Un servicio de DNS protector aplica directivas de seguridad en esta fase de búsqueda, en lugar de esperar a que se descargue un archivo o a que se produzca una acción sospechosa en el punto final.
La distinción práctica: El DNS ayuda a un dispositivo a encontrar un destino. Protective DNS añade una decisión sobre si la búsqueda debe tener éxito o no.
Esto resulta especialmente importante en lugares donde muchas personas y dispositivos comparten la infraestructura de red. Un hotel puede tener teléfonos de invitados, portátiles 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 se enfrentan a un desafío similar, aunque los usuarios y dispositivos sean distintos.
Un DNS de protección puede proporcionar 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 solucionador gestionado y no sustituye a la protección del punto final, los controles de acceso o un diseño de red cuidadoso. Las preguntas útiles son cómo toma sus decisiones el solucionador, cómo mantiene una organización los dispositivos en la ruta prevista y qué pruebas demuestran que el servicio ayuda sin causar interrupciones.
Qué hace el DNS de protección en la fase 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 comprueba la solicitud. Compara el dominio con las políticas configuradas y la inteligencia sobre amenazas. Las implementaciones más sólidas también pueden comprobar 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 utilizar para encontrar infraestructura de comando y control. Los patrones inusuales en los caracteres de un dominio, incluida una alta entropía, pueden actuar como una señal para una posterior evaluación de las directivas. Ese tipo de análisis puede complementar las fuentes de inteligencia sobre 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 equivalen a 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. Protective DNS toma esa decisión de directiva en el resolvedor.
Para los equipos que revisan los controles sobre el acceso web y los servicios en la nube, esta distinción puede alinearse con orientaciones más amplias 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 del destino.
Cómo funciona la aplicación de directivas en una red
Un resolutor puede tomar una decisión acertada para una sola solicitud y, aun así, no lograr proteger una red si los dispositivos pueden enrutar el DNS al margen de él. Por lo tanto, la implementación en toda la infraestructura se basa en dos aspectos conectados: una directiva coherente y una ruta fiable hacia el resolutor.
Un diseño centralizado envía solicitudes DNS de múltiples sedes a un servicio gestionado. Esto facilita la aplicación de reglas compartidas y la revisión de la actividad en todas las ubicaciones. También convierte la disponibilidad en un requisito de seguridad. Si el resolvedor no está accesible, el acceso web habitual 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 Poder Ejecutivo Civil Federal en septiembre de 2022. Para agosto de 2024, más de 104 agencias se habían incorporado, generando un promedio de 1600 millones de consultas DNS seguras al día; el programa notificó un tiempo de actividad del resolver del 99,999 % (hoja informativa sobre el DNS de protección de CISA). La lección operativa es que la calidad del filtrado y la disponibilidad del servicio deben evaluarse conjuntamente.
Aplique la identidad sin multiplicar las políticas
El personal, los invitados, los residentes y el equipamiento conectado no necesitan necesariamente las mismas reglas. Una red puede asignar diferentes directivas en función de la identidad o del segmento de red, como una red para empleados, WiFi para invitados y una red aislada para dispositivos del edificio. El objetivo es adaptar la política al usuario o dispositivo manteniendo una administración manejable.
Los controles de acceso ayudan a establecer esa separación, mientras que la monitorización del tráfico de red puede ayudar a los equipos a investigar la actividad inusual de la red. Para obtener una vista relacionada de 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 de forma deliberada
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 plantean otro desafío: el cifrado puede proteger las consultas en tránsito, pero un resolutor no gestionado también puede excluirlas de la directiva y la visibilidad de la organización.
Donde se requiera la aplicación de medidas, los equipos deben identificar las rutas DNS directas y los destinos de DNS cifrado no autorizados, y luego decidir cómo los manejarán los controles de red, del punto final y del navegador. Pruebe también las excepciones. Los Captive Portals, los dispositivos móviles, IPv6 y las aplicaciones con su propia configuración de solucionador pueden comportarse de forma diferente a la de un portátil gestionado en una red corporativa. La directiva solo funciona en las rutas que la organización puede gobernar.
Impacto en el rendimiento y mejoras medibles en el tiempo de carga de página
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 las respuestas en caché, cómo mantiene las conexiones y si los dispositivos lo omiten.
El DNS cifrado puede añadir 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 la conexión, según mediciones independientes sobre el rendimiento del DNS cifrado. En condiciones de red óptimas, la latencia de búsqueda directa 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 resolvedor cercano y de alta disponibilidad, junto con una memoria caché que cumpla los estándares, ayuda a mantener la rapidez en las consultas habituales. Sin embargo, una cifra media de latencia puede ocultar experiencias lentas para un subconjunto de usuarios, o bien cuando el resolvedor debe obtener una respuesta que no está almacenada en caché.
Mida la latencia de búsqueda p50, p90 y p99 por separado para memorias caché frías y calientes. La mediana muestra una búsqueda típica; los percentiles más altos revelan casos más lentos que pueden afectar más directamente a los usuarios. Mantenga la velocidad de búsqueda diferenciada 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 revelan imprevistos
Realice pruebas desde los tipos de redes y dispositivos que utiliza la gente, incluidos clientes móviles, IPv6 y Captive Portals. Compruebe las aplicaciones y los navegadores que puedan seleccionar su propio servicio DoH o DoT, ya que pueden cambiar tanto la ruta como la visibilidad de las solicitudes DNS.
En mediciones distribuidas se ha observado que DoQ, DNS over QUIC, se aproxima al rendimiento del texto plano y mejora algunos casos de carga de páginas en comparación con DoH. Considere estos hallazgos como un motivo para probar las opciones de transporte en su propio entorno, no como la promesa de un resultado específico. El objetivo práctico es contar con un resolvedor cercano, un almacenamiento en caché eficaz, sesiones cifradas reutilizables y un diseño que no deje abiertas rutas sin gestionar.
Casos de uso reales 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 1173 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 del NCSC del Reino Unido).
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, ni que el DNS por sí solo haya detenido todas las rutas hacia una amenaza. Para un operador multisitio, la comparación útil radica en si el servicio puede aplicar la directiva de manera coherente, generar telemetría útil y gestionar el volumen y las excepciones de ese entorno.
Considere cómo se adapta el mismo punto de control a diferentes recintos:
- Hoteles y propiedades residenciales: Separe el acceso de huéspedes o residentes del de los empleados y los dispositivos del edificio. Un Captive Portal, un dispositivo antiguo o el resolvedor cifrado preferido de un residente pueden generar una excepción que conviene planificar.
- Aeropuertos y estadios: Aplique una base de referencia común en el acceso público de alta rotación, manteniendo diferenciadas las redes operativas y de personal. Vigile los dispositivos no gestionados y las necesidades de conectividad que requieran una excepción documentada.
- Sector sanitario y educación: Restrinja el acceso a destinos nocivos sin bloquear los servicios legítimos utilizados para la atención médica, la docencia o la administración. Ofrezca un proceso de revisión claro cuando una directiva bloquee algo necesario para el trabajo.
- Comercio minorista 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 planifiquen el acceso de invitados también pueden encontrar útiles estas soluciones de WiFi para retail al considerar cómo se integran el acceso y las directivas.
Una breve introducción al tema también puede ayudar a los equipos a alinearse sobre lo que la capa DNS hace y no hace:
En cada entorno, el filtrado DNS es un control parcial, no una garantía de que se detengan todas las amenazas. Un usuario puede acceder a la infraestructura a través de otro resolvedor o mediante una dirección IP directa, y una aplicación puede utilizar protocolos que no dependan de la ruta DNS de la organización. El despliegue requiere una gestión de excepciones y monitorización junto con la propia directiva.
Elección del 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 puntos diferentes, por lo que los equipos suelen elegir una combinación en lugar de un sustituto único. La mezcla adecuada depende de quién gestione el dispositivo, qué tráfico pueda ver la red y cómo se deban gestionar las excepciones.
| Control | Mejor opción para | Visibilidad | Limitación habitual |
|---|---|---|---|
| Protective DNS | Redes compartidas, entornos gestionados y aplicación de políticas DNS | Solicitudes DNS que pasan a través del resolutor | Los resolutores no gestionados y las rutas no DNS pueden eludirlo |
| Agente de punto final | Portátiles y dispositivos móviles gestionados que necesitan protección fuera de la red | Actividad visible para el agente instalado | La cobertura depende de la instalación, la salud y la gestión del agente |
| Política del navegador | Navegadores gestionados donde se pueden regular el resolutor y los ajustes de navegación | Configuración del navegador y actividad seleccionada del navegador | 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 diferentes necesidades de acceso | Decisiones de conexión y acceso vinculadas a la identidad o segmento | Una conexión permitida no juzga por sí misma cada destino |
Para portátiles gestionados, los controles de cliente y navegador pueden complementar la directiva del resolvedor, especialmente cuando los empleados trabajan fuera de la oficina. El WiFi para invitados y BYOD son más difíciles de gestionar mediante agentes, lo que hace que los controles en la red sean más prácticos, siempre que la organización pueda dirigir el DNS hacia el servicio elegido. Los dispositivos IoT y residenciales a menudo requieren segmentación y una directiva 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 de PCI-DSS afectan a la separación y 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 la identidad. Purple Shield añade DNS de protección y filtrado de contenidos con controles por directiva. Esas funcionalidades pueden coexistir con los controles de puntos de acceso y navegadores, pero no eliminan la necesidad de definir la aplicación del resolver, las excepciones y la supervisión. Elija las herramientas en función de las rutas y los dispositivos que necesite proteger y, a continuación, verifique que sus directivas funcionen conjuntamente.
Medición del valor del DNS de protección más allá de las métricas de bloqueo
Un total de consultas bloqueadas le indica que el resolvedor actuó. Por sí solo, no le dice si interceptó las solicitudes correctas, si interrumpió un trabajo útil o si pasó por alto tráfico que tomó otra ruta. Contabilice la decisión, pero mida el control.
El taller sobre DNS de la European Internet Industry Association notificó 2,3 millones de informes de abuso que cubrían 780 000 dominios únicos durante los seis meses anteriores, con informes mensuales que aumentaron de 220 000 a 380 000 (informe del taller). Esas cifras muestran la magnitud del abuso notificado. No establecen cuántos incidentes evitó un resolver, si un bloqueo fue correcto o si el tráfico afectado llegó a un destino a través de una VPN, un resolver 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 eficaz combina la seguridad, la calidad del servicio y la respuesta operativa. Permite comprobar si el resolvedor ha detectado dominios maliciosos conocidos, la rapidez con la que los equipos gestionan las apelaciones por falsos positivos y si los cambios de directiva llegan puntualmente a las ubicaciones previstas. Combine estas medidas con la disponibilidad del resolvedor y la latencia media y extrema de las búsquedas.
Mida también los intentos de elusión. Un número bajo de solicitudes bloqueadas puede significar que el entorno tiene poca actividad maliciosa, o bien que los dispositivos no están utilizando el solucionador 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 ocultarse una excepción. Compare la actividad DNS con los datos de los puntos finales 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 DNS pueden revelar patrones de navegación, lo que exige especial cuidado en entornos sanitarios, educativos, hoteleros y residenciales. Establezca límites de retención, restrinja el acceso por funciones 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 su despliegue de DNS protector
Comience por la ruta, no por el panel de control. Mapee qué dispositivos utilizan el resolvedor gestionado, identifique dónde el DNS directo o el DNS cifrado no autorizado podrían omitirlo y decida cómo se aplicará el control en los dispositivos que la organización no gestiona. Incluya un proceso de excepción para los servicios legítimos que bloquee una política.
Antes del despliegue, acuerden cómo evaluará el equipo tanto la seguridad como la calidad del servicio:
- Confirmar el uso del resolutor: Compruebe los dispositivos gestionados, las redes de invitados y los dispositivos menos predecibles, como los de IoT.
- Probar la ruta de red: Donde se requiera su aplicación, revise las rutas DNS directas y las rutas DNS cifradas no autorizadas.
- Medir el rendimiento: Compare la latencia de búsqueda en caché fría y caliente, incluyendo los percentiles más lentos.
- Definir el cuadro de mando: 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 a los registros y de retención antes de comenzar una recopilación amplia.
Para un despliegue en múltiples sedes, reúna a los equipos de redes y seguridad para mapear identidades, segmentos de red, rutas de solucionadores y las excepciones que requiere cada ubicación. Purple ofrece sesiones de diseño dirigidas por ingenieros de redes para dar forma y validar los planes de despliegue. 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 sustituirá a la seguridad del punto final, la segmentación de red o la gobernanza de la privacidad.
Purple Access admite redes WiFi abiertas, seguras y xPSK, con asignación de red basada en la identidad e incorporación de invitados o BYOD en los puntos de acceso existentes. Para planificar cómo pueden funcionar estos controles de acceso junto con el DNS de protección en sus instalaciones, visite Purple Access.
