DNS sinkhole explicado: Cómo detiene las llamadas maliciosas
Un DNS sinkhole redirige las búsquedas de malware a un señuelo, deteniendo las llamadas y revelando los dispositivos infectados. Descubra cómo funciona y dónde desplegarlo.
Published 2 de noviembre de 2026
Un invitado conecta un portátil al WiFi de su cafeteríaWiFi, abre un navegador y continúa con su día. En segundo plano, el malware de ese portátil intenta ponerse en contacto con su controlador. No puede instalar software de seguridad en el dispositivo de cada visitante, pero sí puede controlar cómo responde su red a las solicitudes de ese dispositivo para acceder a destinos de internet.
Un sinkhole de DNS le ofrece una forma de interrumpir esa devolución de llamada y registrar pruebas que valga la pena investigar. La pregunta útil no es solo qué bloquea, sino si puede identificar el dispositivo afectado, demostrar que se aplica su directiva y restablecer el acceso legítimo cuando una regla comete un error.
Índice de contenidos
- Qué es un sinkhole de DNS en términos sencillos
- Cómo responde un sinkhole a una búsqueda maliciosa
- El brote de Conficker que convirtió los sinkholes en un estándar
- Convertir los accesos al sinkhole en pistas sobre dispositivos infectados
- Modelos de despliegue para redes compartidas y de invitados
- Falsos positivos y cómo recuperarse rápidamente
- Decida si un sinkhole se adapta a su red
Qué es un sinkhole DNS en términos sencillos
El portátil infectado necesita encontrar su controlador antes de poder solicitar instrucciones. Si el malware utiliza un nombre de dominio, el portátil pide primero a un resolvedor DNS que traduzca ese nombre en una dirección IP.
Piense en el DNS como una guía telefónica. El dominio es el nombre que busca y la dirección IP es el número al que necesita llamar. Un resolvedor de protección comprueba si debe proporcionar ese número.
Un sinkhole de DNS reemplaza la respuesta para un dominio malicioso conocido por un destino controlado, o bloquea la respuesta, para que el dispositivo no pueda usar esa búsqueda para llegar al atacante.
En sentido estricto, sinkholing significa redirigir el tráfico a un punto final controlado. Los administradores también utilizan el término de forma más amplia para las directivas de DNS que suprimen las búsquedas maliciosas sin proporcionar un destino.
La analogía del directorio ayuda a separar la búsqueda del nombre de la conexión posterior.
El bloqueo de DNS no es lo mismo que el bloqueo de IP
Un sinkhole de DNS actúa sobre el nombre solicitado antes de que el dispositivo utilice la respuesta para contactar con ese destino. Una regla de firewall ordinaria evalúa los paquetes, a menudo utilizando su dirección IP de destino, y puede rechazar el intento de conexión inicial. Un firewall no tiene por qué esperar a que se establezca una conexión.
Esa distinción es importante cuando los servicios legítimos y maliciosos comparten la infraestructura de alojamiento. Bloquear una dirección IP entera puede afectar a servicios no relacionados, mientras que una directiva DNS puede dirigirse a un nombre de host concreto. Ninguno de los dos enfoques sustituye al otro.
En redes WiFi compartidas WiFi, el resolutor resulta útil porque el operador no necesita acceso administrativo al portátil. Sin embargo, detener una devolución de llamada no elimina la infección. Le da al operador una oportunidad de contención y, con el registro adecuado, una pista para la investigación.
Cómo responde un sinkhole a una búsqueda maliciosa
Una búsqueda DNS es una solicitud de información, no una conexión al sitio web solicitado. La respuesta del resolvedor determina lo que el dispositivo puede intentar a continuación.
La ruta básica separa el dispositivo, la comprobación de la directiva y el destino controlado.
- El dispositivo solicita su dominio de devolución de llamada. Envía una consulta a su resolvedor configurado.
- El resolvedor identifica qué directiva se aplica a la red de origen, como una red de invitados SSID o de personal VLAN.
- El nombre se contrasta con la inteligencia sobre amenazas y las reglas locales, incluidas las categorías de comando y control, suplantación de identidad (phishing) y malware.
- En caso de coincidencia de bloqueo, el resolvedor proporciona una dirección controlada, devuelve una respuesta de nombre no existente, o bien rechaza o suprime la respuesta.
- El dispositivo intenta conectarse al señuelo o no consigue obtener un destino válido. Los nombres permitidos se resuelven con normalidad.
Antes de que un dispositivo abra un sitio web o una aplicación, consulta al DNS dónde encontrarlo, y Shield responde aplicando la directiva de esa red. Si un dominio está bloqueado, la conexión a ese destino nunca se inicia y el dispositivo muestra en su lugar la página de bloqueo personalizada del cliente. Esta experiencia del usuario no debe confundirse con el intento fallido de respuesta de un malware.
Elija la respuesta según las pruebas que necesite
Opciones de respuesta de sinkhole y lo que revela cada una
| Respuesta | Lo que experimenta el dispositivo | Lo que averiguan los defensores | Principal inconveniente |
|---|---|---|---|
| Nombre no existente (NXDOMAIN) | La búsqueda falla y la conexión nunca se inicia | Que se ha intentado y bloqueado una búsqueda | Detiene la devolución de llamada, pero no proporciona información sobre el comportamiento de conexión posterior |
| Dirección de agujero negro (sinkhole) | La búsqueda devuelve la dirección de un servidor controlado | IP de origen, intervalos de la devolución de llamada, patrón de reintento y protocolo observable | Requiere un punto de extremo monitorizado y un almacenamiento de registros cuidadoso |
| Respuesta denegada o suprimida | El resolvedor rechaza la consulta o la deja sin respuesta | Apenas nada más allá del propio intento, a menos que el registro del resolvedor esté activado | Rápido de aplicar, pero algunos clientes reintentan la conexión de forma agresiva |
NXDOMAIN no borra la información del origen ni de la marca de tiempo. Un resolutor puede registrar ambas cosas. Lo que no puede recopilar a partir de esa búsqueda fallida es la conexión que el malware habría realizado a continuación.
Una evaluación revisada por pares sobre captura de paquetes en sinkholes reflejó una mejora de cinco veces en la captura de paquetes maliciosos mediante un diseño de recopilación avanzado en comparación con una implementación convencional. Se trata de una prueba sobre la arquitectura de recopilación, no de la promesa de que todos los sinkholes vayan a ofrecer la misma mejora.
Este vídeo ofrece otra forma de seguir el mecanismo.
La respuesta que elija determina el comportamiento posterior que podrá observar. Mantenga aislados los recolectores y no asuma que el redireccionamiento generará una página de advertencia limpia para cada aplicación cifrada.
El brote de Conficker que estandarizó el uso de sinkholes
Conficker demostró cómo los defensores podían convertir la búsqueda de instrucciones del malware en una fuente de inteligencia. En lugar de inspeccionar cada equipo infectado, los investigadores interceptaron los destinos con los que el gusano estaba programado para contactar.
El archivo Conficker de CAIDA describe el brote detectado por primera vez en noviembre de 2008, cuyas primeras variantes generaban aproximadamente 250 nombres de dominio seudoaleatorios al día. El gusano se ponía en contacto con los nombres generados a través de HTTP para obtener instrucciones o malware adicional.
Investigadores y operadores de red registraron dominios seleccionados antes de que los delincuentes pudieran usarlos, y luego apuntaron esos nombres a servidores controlados. En consecuencia, los equipos infectados llamaron a la infraestructura gestionada por los defensores.
La búsqueda se convirtió en un punto de medición
Esas devoluciones de llamada ayudaron a los equipos de respuesta a identificar sistemas infectados, estimar la propagación del gusano y rastrear el progreso de la limpieza sin comunicarse directamente con la red de mando delictiva. Por lo tanto, una intercepción con éxito hizo algo más que denegar una actualización: registró un equipo que todavía intentaba obtener una.
- Para la contención, los equipos de respuesta impidieron que determinados nombres dirigieran a la infraestructura controlada por los atacantes.
- Para la investigación, los registros de devoluciones de llamada identificaron los sistemas que requerían atención.
- Para el seguimiento de la corrección, la continuidad de las devoluciones de llamada indicaba que la limpieza aún no se había completado.
Las variantes posteriores de Conficker ampliaron el conjunto de nombres generados y añadieron la actualización entre pares (peer-to-peer). Los equipos de respuesta tuvieron que coordinar el registro y el bloqueo en lugar de confiar en una lista pequeña y estática.
El despliegue histórico también difería de la directiva de filtrado local de una organización. Los investigadores cambiaban los destinos de los dominios que controlaban, lo que afectaba a los equipos infectados que resolvían esos nombres a través de DNS ordinario. Por el contrario, un operador de recinto generalmente aplica la directiva en su propio resolutor recursivo.
La cobertura fue la limitación en ambos casos. Los defensores podían interceptar las devoluciones de llamada a los nombres bajo su control, pero eso no significaba que todas las posibles rutas de actualización hubieran desaparecido. Conficker estableció el sinkholing tanto como técnica de contención como herramienta de medición, no como un sustituto de la reparación de ordenadores infectados.
Cómo convertir las coincidencias de sinkhole en pistas sobre dispositivos infectados
Un cliente que consulta repetidamente un dominio bloqueado de comando y control (C2) merece atención. El patrón puede proporcionar una pista útil incluso cuando no se dispone de un agente en el punto final, inspección de carga útil o registros detallados del firewall.
La dependencia es importante: el estudio de la Universidad de Arizona sobre la defensa contra botnets explica que una redirección DNS eficaz requiere identificar la infraestructura C2 de la botnet y contar con la cooperación del operador de DNS que utiliza dicha botnet. Una coincidencia muestra que una solicitud concreta se topó con su directiva, no que haya descubierto todas las rutas de comunicación.
Conserve suficiente contexto para localizar el cliente
Registre estos campos juntos en lugar de dispersarlos en paneles desconectados:
- Marca de tiempo: Correlacione el evento con las concesiones de red y los registros de autenticación.
- SSID o VLAN: Identifique la red y el límite de directiva implicados.
- Identificador de cliente: Conserve una referencia de dispositivo útil, no solo la dirección pública del establecimiento.
- Dominio consultado: Conserve el nombre de host exacto que activó la regla.
- Categoría de directiva: Distinga una clasificación de amenaza de una restricción de contenido.
- Acción de respuesta: Registre si el resolutor redirigió, denegó o devolvió NXDOMAIN.
Una IP pública de origen puede representar a muchos invitados detrás de la misma pasarela. Para identificar un dispositivo individual, correlacione las observaciones del punto final con los registros de la red y del resolutor. No etiquete todo el recinto como infectado solo porque un recolector vea su dirección compartida.
Regla de investigación: Trate una coincidencia de sinkhole como una pista con contexto de respaldo, no como un veredicto automático contra el propietario del dispositivo.
Valide la señal y mantenga la cobertura
Compare los impactos repetidos con el comportamiento normal en esa red y verifique la clasificación con fuentes de inteligencia de amenazas actualizadas. Los dominios generados, los alojamientos con cambios rápidos, las direcciones codificadas de forma rígida y los canales de reserva pueden dejar brechas. La falta de impactos no es prueba de que un dispositivo esté limpio.
El estado del dominio también requiere una revisión continua. Un estudio académico de 2019 sobre el desmantelamiento de dominios maliciosos reveló que más del 14 % de los dominios eliminados en los diez meses anteriores habían vuelto posteriormente al mercado comercial de dominios.
Revise la procedencia, la propiedad y la clasificación de las reglas de forma programada. Si opera usted mismo dominios sinkhole registrados, proteja su configuración de DNS y sus renovaciones. Restrinja el acceso a los registros a nivel de cliente y establezca periodos de retención coherentes con la legislación local y sus necesidades de investigación.
Modelos de despliegue para redes compartidas y de invitados
Un sinkhole protege la ruta DNS que usted controla. El navegador o la aplicación de un invitado pueden seleccionar en su lugar un resolutor cifrado externo, dejando su directiva local sin nada que evaluar.
Un análisis técnico del DNS cifrado explica por qué el DNS-over-HTTPS externo puede eludir la supervisión convencional de DNS. Por lo tanto, la decisión de despliegue gira en torno a la aplicación del solucionador y el comportamiento del cliente, y no se trata meramente de la calidad de una lista de bloqueo.
Modelos de despliegue de sinkhole para redes compartidas
| Modelo | Dónde se ubica el control | Caso de uso óptimo | Principal limitación |
|---|---|---|---|
| Resolutor de red en la red de invitados WiFi | Resolutor asignado a cada cliente por la red | Hoteles, pubs, WiFi para invitados pública WiFi | Los clientes con su propio resolutor codificado o cifrado pueden eludirlo |
| Inspección de DNS en firewall | Dentro de un firewall o pasarela existente | Oficinas con una infraestructura de firewall consolidada | La inspección de DNS convencional pasa por alto el DoH externo transmitido como HTTPS |
| Directiva de navegador o dispositivo gestionado | El navegador o el SO establece el resolutor y deshabilita el DoH alternativo | Dispositivos corporativos o escolares gestionados | No alcanza a los dispositivos personales no gestionados |
| DNS de protección en la nube | Resolutor alojado por el proveedor al que apunta el DNS de la red | Recintos e instalaciones multisede | Depende de la disponibilidad del proveedor y del acceso a la telemetría |
El cifrado y la aplicación de políticas son decisiones independientes
El DNS cifrado mejora la confidencialidad entre el cliente y el solucionador. Esto no debilita necesariamente el filtrado: un solucionador de protección aprobado puede aceptar consultas cifradas y seguir aplicando la directiva. El problema de visibilidad surge cuando el cliente elige un solucionador externo que no aplica sus reglas.
Para los dispositivos gestionados, las directivas del navegador y del sistema operativo pueden especificar el servicio aprobado. En las redes de invitados, se necesita una postura documentada sobre el DNS cifrado alternativo, la privacidad del usuario y las excepciones permitidas. Bloquear todo el tráfico web cifrado para detener el DoH no es una estrategia general viable.
Coloque el control en un límite que pueda probar
Distribuya el resolutor aprobado a través de la configuración de red. Restrinja el DNS convencional saliente directo a los resolutores aprobados, cubriendo tanto los protocolos de transporte como ambas familias de IP. La redirección transparente puede capturar el DNS convencional enviado a otra parte, pero no resuelve de forma transparente el DNS cifrado arbitrario.
Utilice la segmentación de red para separar las directivas del personal, de los invitados y de los dispositivos especializados. Una regla restrictiva para invitados no debería interrumplir el equipo clínico o las aplicaciones del personal.
- Probar la resolución ordinaria: confirme que las aplicaciones permitidas siguen funcionando.
- Probar las rutas de omisión: compruebe los resolutores seleccionados por el navegador y otros túneles permitidos.
- Probar la atribución: confirme que aparezca una coincidencia de directiva controlada en la red y el cliente correctos.
Un cambio de DNS a nivel de red puede aplicar filtrado en todos los dispositivos participantes sin necesidad de instalar software en cada uno de ellos. Demuestre la cobertura con pruebas, en lugar de asumir que la distribución de una dirección de resolutor obliga a todas las aplicaciones a usarla.
Falsos positivos y cómo recuperarse rápidamente
Una lista de bloqueos más larga no es automáticamente más segura. Una regla general contra la infraestructura en la nube compartida puede interrumpir los portales de proveedores, los flujos de trabajo de pago o las aplicaciones de aprendizaje sin mejorar la protección frente a la amenaza prevista.
Un estudio de implementación de sinkholing de 2025 reportó falsos positivos que requirieron la gestión manual de listas de permitidos y personal capacitado. La responsabilidad operativa corresponde al plan de despliegue, no solo a la cola de incidentes.
El proceso de recuperación debe tener en cuenta los servicios compartidos y las excepciones de alcance limitado.
Restablezca el acceso sin eliminar la protección
Inicie las nuevas directivas en modo de solo registro durante un periodo de observación acordado. Capture el cliente, la categoría y la regla coincidente para que las decisiones posteriores cuenten con un historial de pruebas.
Síntomas de sinkhole, causas probables y primeras acciones
| Síntoma | Causa probable | Primera acción |
|---|---|---|
| El dispositivo del personal no puede acceder al sitio web de un proveedor | Dominio en la nube compartido bloqueado por categoría | Compruebe la categoría registrada y, a continuación, añada a la lista de permitidos el host exacto, no el dominio completo |
| Un dispositivo de invitado activa coincidencias de agujero negro (sinkhole) cada minuto | Dispositivo infectado o aplicación agresiva reintentando la conexión | Identifique y aísle al cliente; a continuación, organice la inspección del dispositivo |
| Aumento repentino de consultas bloqueadas tras un cambio de directiva | Entrada genérica en la lista de bloqueos o regla con comodines | Revierta el último cambio y revise su alcance en el SSID o VLAN |
| Las aplicaciones funcionan, pero un SSID no muestra bloqueos | Es posible que los clientes utilicen DNS cifrado fuera del resolvedor | Ejecute una prueba de directiva controlada e inspeccione la configuración del resolvedor y las rutas DNS salientes |
Un informe vacío por sí solo no confirma una elusión. Es posible que la red no haya generado solicitudes coincidentes.
Mida las conexiones dañinas evitadas, la tasa de falsos positivos, el tiempo de resolución de recursos y las excepciones por espacio. El volumen de consultas bloqueadas por sí solo puede aumentar porque una aplicación reintenta la conexión repetidamente.
Antes de activar una regla, confirme:
- Clasificación: La categoría de amenaza del dominio es compatible.
- Uso compartido: Las aplicaciones empresariales no dependen del mismo host o dominio primario.
- Reversión: La directiva anterior y el procedimiento de restauración están registrados.
- Alcance: El SSID o VLAN previsto es explícito.
- Titularidad: Una persona designada gestiona las solicitudes de excepción y revisa su caducidad.
Decida si un sinkhole se adapta a su red
Para una oficina pequeña con puntos finales gestionados, comience con el registro de DNS y la directiva de punto final. Es posible que ya disponga de los controles de dispositivos necesarios para investigar solicitudes sospechosas directamente, así que evite añadir un recolector que no pueda mantener.
Para redes de invitados, públicas o de estudiantes, priorice la aplicación de límites y la atribución de clientes. Los dispositivos no gestionados hacen que los controles a nivel de resolutor sean útiles, pero un operador aún necesita una forma segura de investigar o contener un dispositivo sin acusar a su propietario prematuramente.
Adapte el modelo operativo a su infraestructura
Una organización con múltiples sedes se beneficia de una directiva de resolvedor gestionada de forma centralizada, excepciones específicas para cada red e informes consolidados. Compare los servicios en función de las pruebas que exponen y los controles que pueda probar, no solo por su número de categorías.
Elija un sinkhole cuando pueda asumir la propiedad de todo el proceso: directivas, cobertura, investigación, excepciones y recuperación.
Comience con un despliegue limitado:
- Trace la ruta del resolvedor. Identifique qué resolvedor utiliza cada red y dónde podrían eludir la directiva mediante túneles o DNS alternativos.
- Lleve a cabo un periodo documentado de observación exclusivo para registros. Registre las solicitudes coincidentes con su cliente, categoría y red; a continuación, revise las dependencias de las aplicaciones legítimas.
- Active primero los bloqueos de alta confianza. Comience por los destinos confirmados de C2 y malware, mantenga un plan de reversión por escrito y asigne un responsable de excepciones.
Mantenga la remediación del punto final independiente de la contención de la red. Una retrollamada bloqueada es una intervención exitosa, pero el dispositivo aún requiere investigación. Su despliegue estará listo cuando el personal pueda demostrar tanto un bloqueo controlado como un restablecimiento seguro del acceso legítimo.
Purple Shield ofrece un servicio DNS de protección con directivas e informes específicos para cada red, lo que le permite evaluar el bloqueo de dominios maliciosos junto con la información necesaria para gestionarlo. Visite Purple Shield para solicitar una prueba gratuita de 30 días, apunte el DNS de su red a Shield y pruebe el filtrado en su red activa sin necesidad de nuevo hardware ni agentes de dispositivo.