Explicación del sinkhole de DNS: Cómo detiene las llamadas maliciosas
Un sinkhole de DNS redirige las búsquedas de malware a una trampa, deteniendo las llamadas maliciosas y revelando los dispositivos infectados. Conozca cómo funciona y dónde implementarlo.
Published 2 de noviembre de 2026
Un invitado conecta una computadora portátil al WiFiWiFi de su cafetería, abre un navegador y continúa con su día. En segundo plano, el malware de esa computadora 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 destinos de internet de ese dispositivo.
Un DNS sinkhole le ofrece una manera de interrumpir esa devolución de llamada y registrar evidencia que vale la pena investigar. La pregunta útil no es solo lo que bloquea. Es si usted puede identificar el dispositivo afectado, demostrar que su directiva se aplica y restaurar el acceso legítimo cuando una regla comete un error.
Tabla de contenido
- 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 las detecciones de sinkhole en indicios de dispositivos infectados
- Modelos de implementación 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
La computadora portátil infectada necesita encontrar su controlador antes de poder solicitar instrucciones. Si el software malicioso utiliza un nombre de dominio, la computadora portátil primero le pide a un resolutor DNS que traduzca ese nombre en una dirección IP.
Piense en el DNS como un directorio telefónico. El dominio es el nombre que usted busca y la dirección IP es el número al que necesita llamar. Un resolutor de protección verifica si debe proporcionar ese número.
Un sinkhole de DNS reemplaza la respuesta para un dominio de mala reputación conocido por un destino controlado, o bloquea la respuesta, para que el dispositivo no pueda usar esa búsqueda para comunicarse con el atacante.
Estrictamente hablando, el sinkholing significa redirigir el tráfico a un punto de conexión controlado. Los administradores también utilizan el término de manera más amplia para referirse a 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 de nombres de la conexión posterior.
El bloqueo de DNS no es lo mismo que el bloqueo de IP
Un DNS sinkhole actúa sobre el nombre solicitado antes de que el dispositivo use la respuesta para ponerse en contacto 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 que 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 completa puede afectar a servicios no relacionados, mientras que una política de DNS puede dirigirse a un nombre de host en particular. Ningún enfoque reemplaza al otro.
En WiFi compartidas, el resolutor es útil porque el operador no necesita acceso administrativo a la computadora 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 de DNS es una solicitud de información, no una conexión al sitio web solicitado. La respuesta del resolutor determina lo que el dispositivo puede intentar a continuación.
La ruta básica separa el dispositivo, la verificación de directivas y el destino controlado.
- El dispositivo solicita su dominio de retrollamada. Envía una consulta a su resolutor configurado.
- El resolutor identifica qué directiva se aplica a la red de origen, como una SSID de invitados o una VLAN del personal.
- El nombre se verifica con inteligencia sobre amenazas y reglas locales, incluidas categorías de comando y control, phishing y software malicioso.
- En caso de coincidencia con un bloqueo, el resolutor proporciona una dirección controlada, devuelve una respuesta de nombre no existente, o rechaza o suprime la respuesta.
- El dispositivo intenta conectarse al señuelo o no logra obtener un destino útil. Los nombres permitidos se resuelven normalmente.
Antes de que un dispositivo abra un sitio o aplicación, consulta al DNS dónde encontrarlo, y Shield responde utilizando la directiva para esa red. Si un dominio está bloqueado, la conexión a ese destino nunca se inicia y el dispositivo muestra la página de bloqueo con la marca del cliente. Esa experiencia del usuario no debe confundirse con el software malicioso que reintenta un retorno de llamada fallido.
Elija la respuesta según la evidencia que necesite
Opciones de respuesta de un sinkhole y lo que revela cada una
| Respuesta | Lo que experimenta el dispositivo | Lo que averiguan los defensores | Principal compromiso |
|---|---|---|---|
| Nombre no existente (NXDOMAIN) | La búsqueda falla y la conexión nunca se inicia | Que se intentó una búsqueda y fue bloqueada | Detiene la retrollamada pero no proporciona 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, temporización de retrollamada, patrón de reintento y protocolo observable | Requiere un extremo supervisado y un almacenamiento de registros cuidadoso |
| Respuesta rechazada o suprimida | El resolutor rechaza la consulta o la deja sin respuesta | Poco más allá del intento en sí, a menos que el registro del resolutor esté habilitado | Rápido de aplicar, pero algunos clientes reintentan agresivamente |
NXDOMAIN no borra la información de origen ni la marca de tiempo. Un resolutor puede registrar ambas cosas. Lo que no puede recopilar de esa búsqueda fallida es la conexión que el software malicioso habría realizado posteriormente.
Una evaluación de captura de paquetes sinkhole revisada por pares reportó una mejora de cinco veces en la captura de paquetes maliciosos con un diseño de recopilación avanzado en comparación con una implementación convencional. Esa es evidencia sobre la arquitectura de recopilación, no una promesa de que cada sinkhole ofrecerá la misma mejora.
Este video ofrece otra forma de seguir el mecanismo.
La respuesta que elija determina qué comportamiento posterior puede observar. Mantenga los recolectores aislados y no asuma que la redirección generará una página de advertencia limpia para cada aplicación cifrada.
El brote de Conficker que estandarizó el uso de los sinkholes
Conficker demostró cómo los defensores podían convertir la búsqueda de instrucciones del software malicioso en una fuente de inteligencia. En lugar de inspeccionar cada computadora infectada, los investigadores interceptaron los destinos con los que el gusano estaba programado para comunicarse.
El archivo de Conficker de CAIDA describe el brote detectado por primera vez en noviembre de 2008, cuyas primeras variantes generaban aproximadamente 250 nombres de dominio seudoaleatorios por día. El gusano se ponía en contacto con los nombres generados a través de HTTP para obtener instrucciones o malware adicional.
Los investigadores y operadores de red registraron dominios seleccionados antes de que los delincuentes pudieran usarlos, y luego apuntaron esos nombres a servidores controlados. Por consiguiente, las computadoras infectadas llamaron a la infraestructura operada 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 comando criminal. Por lo tanto, una interceptación exitosa hizo más que denegar una actualización. Registró una computadora que aún intentaba obtener una.
- Para la contención, los encargados de responder evitaron que los nombres seleccionados llevaran a una infraestructura controlada por los atacantes.
- Para la investigación, los registros de llamadas de retorno identificaron los sistemas que requerían atención.
- Para el seguimiento de la corrección, las llamadas de retorno continuas indicaron que la limpieza aún estaba incompleta.
Las variantes posteriores de Conficker ampliaron el grupo de nombres generados y agregaron actualizaciones entre pares (peer-to-peer). Los equipos de respuesta tuvieron que coordinar el registro y el bloqueo en lugar de depender de una lista pequeña y estática.
La implementación histórica también difería de la directiva de filtrado local de una organización. Los investigadores cambiaron los destinos de los dominios que controlaban, afectando a las computadoras infectadas que resolvían esos nombres a través de DNS ordinario. Por lo general, el operador de un establecimiento aplica la directiva en su propio resolutor recursivo en su lugar.
La cobertura fue la limitación en ambos casos. Los defensores podían interceptar las llamadas de retorno a nombres bajo su control, pero eso no significaba que todas las rutas de actualización posibles hubieran desaparecido. Conficker estableció el uso de sinkholes como una técnica de contención y una herramienta de medición, no como un sustituto de la reparación de computadoras infectadas.
Convertir coincidencias de sinkhole en pistas sobre dispositivos infectados
Un cliente que consulta repetidamente un dominio bloqueado de comando y control (C2) requiere atención. El patrón puede proporcionar una pista útil incluso cuando no se cuenta con un agente en el punto de conexión, inspección de carga útil o registros detallados del firewall.
La dependencia es importante: el artículo sobre defensa contra botnets de la Universidad de Arizona explica que una redirección de DNS eficaz requiere identificar la infraestructura C2 de la botnet y contar con la cooperación del operador de DNS que utiliza la botnet. Una coincidencia muestra que una solicitud específica coincidió con su directiva, no que haya descubierto todas las rutas de comunicación.
Conserve el contexto suficiente para ubicar 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 directivas involucrados.
- Identificador de cliente: Conserve una referencia de dispositivo utilizable, no solo la dirección pública de la sede.
- Dominio consultado: Conserve el nombre de host exacto que activó la regla.
- Categoría de la directiva: Distinga una clasificación de amenaza de una restricción de contenido.
- Acción de respuesta: Registre si el resolutor redirigió, rechazó o devolvió NXDOMAIN.
Una IP pública de origen puede representar a muchos invitados detrás de la misma puerta de enlace. Para identificar un dispositivo individual, correlacione las observaciones del punto de conexión con los registros del resolutor y de la red. No etiquete todo el establecimiento 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 soporte, no como un veredicto automático contra el propietario del dispositivo.
Valide la señal y mantenga la cobertura
Compare las coincidencias repetidas con el comportamiento normal en esa red y verifique la clasificación con fuentes de inteligencia sobre amenazas actualizadas. Los dominios generados, el alojamiento que cambia rápidamente, las direcciones codificadas y los canales de respaldo pueden dejar brechas. La falta de coincidencias 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 durante los diez meses anteriores habían regresado posteriormente al mercado comercial de dominios.
Revise la procedencia de las reglas, la propiedad y la clasificación de forma programada. Si usted mismo opera dominios registrados de sinkhole, proteja su configuración 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 implementación para redes compartidas y de invitados
Un sinkhole protege la ruta de DNS que usted controla. Es posible que el navegador o la aplicación de un invitado elija un resolutor cifrado externo en su lugar, lo que dejaría su directiva local sin nada que evaluar.
Un análisis técnico de DNS cifrado explica por qué el DNS-over-HTTPS externo puede eludir el monitoreo de DNS convencional. Por lo tanto, la decisión de implementación se basa en la aplicación del resolutor y el comportamiento del cliente, y no solo en la calidad de una lista de bloqueo.
Modelos de implementación de sinkhole para redes compartidas
| Modelo | Dónde se ubica el control | Mejor uso | Principal limitación |
|---|---|---|---|
| Resolutor de red en la red para invitados WiFi | Resolutor asignado a cada cliente por la red | Hoteles, pubs y WiFi para invitados en espacios públicos WiFi | Los clientes con un resolutor propio codificado o cifrado pueden omitirlo |
| Inspección de DNS en firewall | Dentro de un firewall o puerta de enlace existente | Oficinas con una infraestructura de firewall establecida | La inspección convencional de DNS pasa por alto el DoH externo transportado como HTTPS |
| Política de dispositivos o navegadores administrados | El navegador o el sistema operativo establece el resolutor y deshabilita el DoH alternativo | Dispositivos corporativos o escolares administrados | No abarca dispositivos personales no administrados |
| DNS de protección en la nube | Resolutor alojado por el proveedor al que apunta el DNS de la red | Recintos e instalaciones multisitio | Depende de la disponibilidad del proveedor y del acceso a la telemetría |
El cifrado y la aplicación de directivas son opciones independientes
El DNS cifrado mejora la confidencialidad entre el cliente y el resolutor. Esto no debilita necesariamente el filtrado: un resolutor de protección aprobado puede aceptar consultas cifradas y seguir aplicando la política. El problema de visibilidad surge cuando el cliente elige un resolutor externo que no aplica sus reglas.
Para los dispositivos administrados, las directivas del navegador y del sistema operativo pueden especificar el servicio aprobado. En las redes de invitados, 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 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 únicamente a resolutores aprobados, abarcando ambos protocolos de transporte y ambas familias de IP. La redirección transparente puede interceptar 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 políticas del personal, de los invitados y de los dispositivos especializados. Una regla restrictiva para invitados no debería interrumpir el equipo clínico ni las aplicaciones del personal.
- Pruebe la resolución ordinaria: Confirme que las aplicaciones autorizadas sigan funcionando.
- Pruebe las rutas de omisión: Verifique los resolutores seleccionados por el navegador y otros túneles permitidos.
- Pruebe la atribución: Confirme que coincida una directiva controlada con 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. Demuestre la cobertura mediante pruebas, en lugar de asumir que distribuir la dirección de un resolutor obliga a cada aplicación a utilizarlo.
Falsos positivos y cómo recuperarse rápidamente
Una lista de bloqueo más larga no es automáticamente más segura. Una regla amplia 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 contra la amenaza prevista.
Un estudio de implementación de agujeros negros (sinkholing) de 2025 reportó falsos positivos que requirieron una gestión manual de listas de permitidos y personal capacitado. La responsabilidad operativa debe formar parte del plan de implementación y no estar únicamente en 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 evidencias.
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 de un proveedor | Dominio en la nube compartido bloqueado por categoría | Verifique la categoría registrada y, luego, agregue a la lista de permitidos el host exacto, no todo el dominio |
| Un dispositivo de invitado activa aciertos de agujero negro (sinkhole) cada minuto | Dispositivo infectado o aplicación agresiva reintentando la conexión | Identifique y contenga al cliente y, a continuación, organice la inspección del dispositivo |
| Pico de consultas bloqueadas tras un cambio de directiva | Entrada de lista de bloqueo amplia o regla con comodín | Revierta el último cambio y revise su alcance de SSID o VLAN |
| Las aplicaciones funcionan pero un SSID no muestra bloqueos | Es posible que los clientes utilicen DNS cifrado fuera del resolutor | Ejecute una prueba de directiva controlada e inspeccione la configuración del resolutor y las rutas de DNS saliente |
Un informe vacío por sí solo no confirma una omisión. Es posible que la red no haya generado solicitudes coincidentes.
Mida las conexiones dañinas prevenidas, la tasa de falsos positivos, el tiempo de resolución de apelaciones y las excepciones por ubicación. El volumen de consultas bloqueadas por sí solo puede aumentar porque una aplicación reintenta la conexión repetidamente.
Antes de habilitar una regla, confirme:
- Clasificación: La categoría de amenaza del dominio está respaldada.
- Uso compartido: Las aplicaciones empresariales no dependen del mismo host o dominio primario.
- Reversión: Se registran la directiva anterior y el procedimiento de restauración.
- Alcance: El SSID o VLAN previsto es explícito.
- Propiedad: Una persona designada gestiona las solicitudes de excepción y revisa su vencimiento.
Decida si un sinkhole se adapta a su red
Para una oficina pequeña con puntos de conexión administrados, comience con el registro de DNS y la directiva de puntos de conexión. Es posible que usted ya cuente con los controles de dispositivos necesarios para investigar solicitudes sospechosas directamente, así que evite agregar un recolector que no pueda mantener.
Para redes de invitados, públicas o de estudiantes, priorice el cumplimiento de límites y la atribución de clientes. Los dispositivos no administrados 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 antes de tiempo.
Adapte el modelo operativo al entorno de la infraestructura
Una organización con múltiples ubicaciones se beneficia de una directiva de resolutor administrada centralmente, excepciones específicas de la red e informes consolidados. Compare los servicios en función de la evidencia que muestran y los controles que usted pueda probar, no solo de sus recuentos de categorías.
Elija un sinkhole cuando pueda ser propietario de todo el proceso: directiva, cobertura, investigación, excepciones y recuperación.
Comience con una implementación limitada:
- Trace la ruta del resolutor. Identifique qué resolutor utiliza cada red y dónde los DNS alternativos o túneles podrían eludir la directiva.
- Ejecute un período de observación documentado de solo registro. Registre las solicitudes coincidentes con su cliente, categoría y red, y luego revise las dependencias de aplicaciones legítimas.
- Habilite primero los bloqueos de alta confianza. Comience con destinos de C2 y software malicioso confirmados, conserve un plan de reversión por escrito y asigne un responsable de excepciones.
Mantenga la remediación de los puntos de conexión independiente de la contención de la red. Una devolución de llamada bloqueada es una intervención exitosa, pero el dispositivo aún requiere investigación. Su implementación estará lista cuando el personal pueda demostrar tanto un bloqueo controlado como una restauración segura del acceso legítimo.
Purple Shield ofrece DNS de protección con directivas e informes específicos para cada red, de modo que usted pueda evaluar el bloqueo de dominios maliciosos junto con la evidencia 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 en vivo sin necesidad de nuevo hardware ni agentes de dispositivo.