¿Qué es un «sinkhole» de DNS y cómo funciona?

Toda conexión de red moderna comienza con una consulta. Cada vez que un dispositivo abre una página web, descarga una actualización o se conecta a un servidor externo, solicita a un resolutor que convierta un nombre de dominio legible para los humanos en una dirección IP. Dado que esta consulta tiene lugar antes de que ningún paquete de datos se transmita entre hosts, constituye uno de los puntos de control más eficaces en la defensa de la red.

Los actores maliciosos se aprovechan constantemente de este paso. Las variantes de malware realizan consultas a hosts remotos para recibir órdenes o sustraer datos, y los señuelos de phishing engañan a los usuarios para que accedan a portales web fraudulentos. Comprender la amplia variedad de tipos de ataques DNS pone de relieve por qué es esencial controlar el comportamiento de las consultas. El «sinkholing» de DNS proporciona a los equipos de seguridad un mecanismo activo para interceptar estas consultas de forma temprana, deteniendo la comunicación maliciosa antes de que un equipo infectado pueda establecer una conexión.

¿Qué es un «sinkhole» de DNS?

Un «sinkhole» de DNS es un mecanismo de seguridad que intercepta las consultas DNS dirigidas a dominios maliciosos conocidos y devuelve una dirección IP falsa y controlada en lugar del destino legítimo. Esta redirección impide que los dispositivos de los usuarios accedan a la infraestructura de las amenazas, neutralizando de forma eficaz las llamadas de retorno del malware, las campañas de phishing y los canales de comando de las redes de bots en la fase de resolución.

En las operaciones de red habituales, un resolutor recursivo consulta los servidores de nombres autoritativos y proporciona al cliente la dirección externa real del nombre de host solicitado. En una configuración de «sinkhole», el resolutor compara el dominio solicitado con una lista de bloqueo seleccionada. Si el dominio solicitado aparece en dicha lista, el resolutor oculta la respuesta real. En su lugar, proporciona una dirección alternativa designada por el administrador de la red, como una dirección de bucle invertido o un servidor interno especializado en el registro de eventos.

Al sustituir la dirección IP de destino, el resolutor garantiza que el cliente nunca inicie un protocolo de enlace TCP con el equipo del atacante. La conexión se interrumpe sin causar ningún daño dentro del entorno local.

Cómo funciona el «sinkholing» de DNS

Para comprender el funcionamiento de un «sinkhole» de DNS, primero hay que analizar el papel que desempeña el resolutor recursivo en el tráfico diario de una empresa. Cuando una estación de trabajo interna envía una solicitud, esta se redirige directamente a un resolutor local. Puedes consultar nuestro análisis sobre qué es un servidor DNS para ver cómo funcionan las búsquedas recursivas estándar en redes distribuidas.

El «sinkholing» de DNS introduce tres componentes operativos fundamentales en este ciclo de búsqueda:

1. Fuentes de información sobre amenazas y listas de dominios bloqueados

Un «sinkhole» depende de datos sobre amenazas precisos y actualizados. Los equipos de seguridad alimentan a los resolvers con listas de dominios maliciosos conocidos, que se recopilan a partir de fuentes de información sobre amenazas de código abierto, proveedores comerciales de inteligencia sobre amenazas, telemetría de respuesta a incidentes y grupos de intercambio del sector. Estas listas contienen URL activas de phishing, nodos de distribución de ransomware y dominios conocidos de comando y control (C2).

2. La anulación de la política del resolutor

Cuando un terminal envía una consulta de búsqueda, el resolutor evalúa el dominio solicitado según las reglas de su zona de políticas antes de aplicar las sugerencias estándar de la raíz de Internet o reenviar las consultas a los servidores superiores. Si el dominio coincide con una entrada de la lista de bloqueo, el resolutor detiene el proceso de resolución saliente. Los resolutores modernos lo consiguen mediante las zonas de políticas de respuesta (RPZ), una tecnología que permite a los administradores reescribir las respuestas DNS de forma dinámica en función de políticas personalizadas.

3. El destino del socavón

Una vez que el resolutor activa una anulación, devuelve una dirección predefinida. En función de los objetivos del equipo de seguridad, esta dirección puede adoptar una de estas dos configuraciones:

• Dirección nula no enrutable: El resolutor devuelve una dirección IP como 0.0.0.0 o 127.0.0.1. El dispositivo cliente intenta conectarse a sí mismo o descarta el paquete inmediatamente, interrumpiendo la sesión con una sobrecarga mínima de recursos.
• Servidor de registro controlado (Sinkhole Collector): El resolutor redirige el dispositivo hacia un servidor interno aislado que aloja un listener HTTP o un registrador de paquetes ligero. Cuando el host infectado se conecta, el servidor «sinkhole» captura los encabezados HTTP entrantes, las cadenas de agente de usuario, las direcciones IP internas y las marcas de tiempo.

Esta capacidad de registro transforma el «sinkhole» de una herramienta de bloqueo pasiva en un sensor activo de detección de amenazas. Es posible que un registro del cortafuegos solo muestre una solicitud saliente dirigida a una IP externa, pero el colector del «sinkhole» registra exactamente la estación de trabajo interna que genera la consulta maliciosa, lo que permite al equipo de respuesta ante incidentes aislar de inmediato el dispositivo afectado.

Tipos de «sinkholes» de DNS

Los «sinkholes» de DNS se implementan en distintos niveles del ecosistema de Internet y cumplen diferentes funciones operativas en función de quién los gestione.

Agujeros negros internos de la empresa

Las organizaciones implementan «sinkholes» internos en los resolutores DNS locales, en los cortafuegos de última generación (NGFW) o en las pasarelas web seguras. El objetivo principal es proteger los terminales corporativos y supervisar el estado de la red interna. Cuando un empleado hace clic en un enlace de phishing o cuando un malware latente intenta conectarse a un servidor C2, el «sinkhole» de la empresa bloquea la conexión saliente y avisa al Centro de Operaciones de Seguridad (SOC) indicando la dirección IP interna del dispositivo.

Proveedores de servicios de Internet y resolutores DNS de protección pública

Los proveedores de servicios de Internet y los operadores de DNS públicos (como Quad9 o el 1.1.1.2 de Cloudflare) implementan «sinkholes» para proteger a un amplio colectivo de consumidores y empresas. En lugar de utilizar sistemas de registro para realizar análisis forenses exhaustivos de los hosts, estos proveedores se centran en la escala. Desvían las solicitudes dirigidas a dominios peligrosos hacia rutas nulas o páginas de advertencia alojadas, lo que evita que grandes volúmenes de tráfico malicioso lleguen a sus suscriptores.

Investigación y lucha contra los «sumideros» (desmantelamiento de botnets)

Durante las operaciones contra la ciberdelincuencia a gran escala, las autoridades judiciales y los investigadores de seguridad establecen «sinkholes» a nivel de registrador o de registro. Tras obtener órdenes judiciales, los investigadores se hacen con la propiedad de los dominios maliciosos codificados en variantes de malware. Modifican los registros de los servidores de nombres autoritativos de dichos dominios, redirigiendo a millones de bots infectados de todo el mundo hacia servidores de investigación. Esto rompe el control del grupo delictivo sobre los ordenadores infectados y permite a los investigadores determinar el tamaño y la distribución geográfica de la red de bots.

Ejemplos reales de «sinkholing» de DNS

El «sinkholing» de DNS ha desempeñado un papel fundamental en la resolución de algunos de los incidentes de ciberseguridad más graves de la historia reciente.

El «kill switch» del ransomware WannaCry (2017)

En mayo de 2017, el ransomware WannaCry se propagó por todo el mundo, paralizando hospitales, empresas de telecomunicaciones y sistemas de transporte en más de 150 países. El gusano se propagó de forma autónoma utilizando el exploit EternalBlue.

Al analizar el archivo binario del malware, el investigador de seguridad Marcus Hutchins descubrió un dominio no registrado codificado de forma fija en el código fuente. El autor del malware había incluido una comprobación: antes de cifrar la unidad del equipo, el código enviaba una consulta DNS a este dominio. Si la consulta fallaba, el ransomware procedía al cifrado de los archivos. Si el dominio respondía, el malware abortaba la ejecución. Hutchins registró el dominio por unos diez dólares y lo redirigió a un servidor «sinkhole». Cuando los equipos de todo el mundo resolvieron el dominio con éxito, la lógica integrada detuvo la rutina de ejecución, frenando así, sin pretenderlo, el brote global de raíz.

Operación Avalancha (2016)

La red Avalanche funcionó durante más de siete años como una plataforma ilícita de alojamiento «a prueba de balas» y distribución de malware, que albergaba más de dos docenas de troyanos bancarios y variantes de ransomware como GozNym y TeslaCrypt. La infraestructura utilizaba técnicas de «fast-flux» dobles, rotando direcciones IP y servidores de nombres cada pocos minutos para eludir la detección.

A finales de 2016, una coalición multinacional de fuerzas del orden de cuarenta países, junto con Europol y el Departamento de Justicia de Estados Unidos, desmanteló la operación. Según la documentación publicada por Europol, las autoridades incautaron, bloquearon o desviaron a servidores «sinkhole» más de 800 000 dominios. Al sustituir los servidores de nombres de los delincuentes por servidores «sinkhole» controlados, los investigadores desconectaron cientos de miles de equipos infectados de sus operadores, lo que supuso una de las mayores operaciones colaborativas de desarticulación de redes de bots jamás llevadas a cabo.

Ventajas del «sinkholing» de DNS

La implementación de un «sinkhole» de DNS ofrece ventajas estratégicas únicas para la defensa de la red:

• Prevención de amenazas en fase inicial: La resolución de DNS tiene lugar antes del protocolo de enlace TCP o de la negociación TLS. Interceptar una amenaza en esta fase garantiza que las cargas maliciosas nunca lleguen al búfer de la red.
• Localización rápida de infecciones: Un colector «sinkhole» registra la dirección IP de origen de cada cliente interno que realiza consultas incluidas en la lista negra. Esto permite a los equipos de seguridad detectar dispositivos comprometidos, ordenadores portátiles no autorizados o dispositivos IoT no autorizados que carecen de los agentes de seguridad tradicionales para terminales.
• Sin huella en los terminales: Dado que el «sinkholing» se ejecuta directamente dentro de la arquitectura del resolutor DNS, los administradores no necesitan instalar ni mantener agentes del lado del cliente en ordenadores, teléfonos o sistemas operativos de servidor individuales.
• Capa de defensa rentable: Las organizaciones pueden crear sistemas de «sinkhole» eficaces utilizando paquetes DNS de código abierto, como BIND o Unbound, combinados con fuentes de información sobre amenazas gratuitas y gestionadas por la comunidad.

Combinar la protección de consultas a nivel de red con unas prácticas recomendadas de seguridad del DNS se crea una sólida defensa en profundidad, lo que garantiza que tanto las estaciones de trabajo internas como los nodos periféricos externos mantengan un alto nivel de seguridad.

Limitaciones de los «sinkholes» de DNS

Aunque el «sinkholing» de DNS ofrece una sólida capa de filtrado, no es una solución de seguridad que lo abarque todo. Los equipos de redes deben tener en cuenta varias limitaciones estructurales:

• Llamadas de retorno directas a direcciones IP: Los autores de amenazas suelen programar el malware para que se conecte directamente a direcciones IP numéricas externas. Si el malware elude el resolutor del sistema y envía una solicitud de conexión directamente a 203.0.113.10, el «sinkhole» nunca detecta el tráfico.
• Elusión del DNS cifrado (DoH y DoT): Los navegadores modernos y las cargas maliciosas pueden realizar consultas a resolutores públicos externos mediante DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT). Estas solicitudes se transmiten a través de canales cifrados, eludiendo los resolutores internos de la empresa y sorteando las políticas locales de redireccionamiento a sumideros, a menos que las reglas de puertos de salida bloqueen estrictamente o descifren dicho tráfico.
• Algoritmos de generación de dominios (DGA): Las variantes avanzadas de malware utilizan algoritmos para generar cientos de nombres de dominio pseudoaleatorios cada día. Las listas de bloqueo de seguridad suelen ir por detrás de los dominios DGA recién generados, lo que permite que el malware establezca una conexión externa antes de que los analistas identifiquen y desvíen el nuevo dominio.
• Resolución y almacenamiento en caché del cliente: Si un dispositivo cliente ha resuelto una dirección antes de que un administrador haya añadido ese dominio a la zona de «sinkhole», el sistema operativo mantiene la IP original en su caché local hasta que caduque el tiempo de vida (TTL) del registro.
• Falsos positivos: Confiar en fuentes de amenazas agresivas o sin filtrar puede provocar que servicios legítimos, redes de distribución de contenidos o direcciones de alojamiento compartido sean desviados a un «sinkhole», lo que causa trastornos a los equipos internos.

Cómo configurar un «sinkhole» de DNS

Es posible configurar un «sinkhole» de DNS funcional en distintos entornos, desde laboratorios domésticos hasta servicios de directorio de nivel empresarial. El proceso se centra en modificar las políticas del resolutor para interceptar las solicitudes maliciosas.

1. Zonas de política de respuesta (RPZ) en BIND o Unbound

Los entornos Unix empresariales que utilizan el demonio Berkeley Internet Name Domain (BIND) o Unbound suelen emplear las zonas de política de respuesta (RPZ). Las reglas RPZ, a menudo denominadas «cortafuegos DNS», configuran el servidor recursivo local para que devuelva una respuesta modificada cuando un cliente solicita una zona bloqueada.

Un administrador crea un archivo de zona específico que contiene datos sobre amenazas:

$TTL 1 h
@ IN SOA localhost. root.localhost. ( 2026102401 1 h 15 m 30 d 2 h )
NS localhost.

; Redirigir los dominios maliciosos a un servidor de registro interno
malicious-site.example.com CNAME sinkhole.internal.network.
phishing-domain.example.net A 192.168.10.50
*.bad-actor-infrastructure.org A 192.168.10.50

Cualquier consulta que coincida con estos registros se resuelve directamente en 192.168.10.50, en lugar de consultar los servidores raíz.

2. Políticas de DNS de Windows Server

En entornos de Active Directory, el servicio DNS de Windows Server incluye funciones de políticas nativas que permiten a los administradores bloquear o redirigir consultas sin necesidad de software externo. Al configurar las políticas de resolución de consultas mediante PowerShell, los administradores pueden comparar los criterios de los nombres de dominio completos (FQDN) entrantes con una lista de bloqueo de dominios maliciosos y devolver una dirección IP nula estática:

Add-DnsServerQueryResolutionPolicy -Name «SinkholePolicy» -Action DENY -FQDN «EQ,*.maliciousdomain.com»

3. Dispositivos de protección específicos (p. ej., Pi-hole)

Para oficinas domésticas y redes de pequeñas empresas, los filtros DNS a nivel de hardware, como Pi-hole, ofrecen servicios de «sinkhole» listos para usar. Instalado en un pequeño servidor o en una máquina virtual, Pi-hole funciona como el resolutor principal de la red local. Consulta las listas de bloqueo elaboradas por la comunidad de seguridad y devuelve 0.0.0.0 cada vez que un dispositivo solicita un dominio vinculado a redes publicitarias, telemetría de seguimiento o dominios de malware.

Gestión de las cachés locales de los clientes

Cada vez que se apliquen nuevas políticas de «sinkhole», es posible que los dispositivos activos de la red sigan accediendo a las direcciones antiguas hasta que caduque la caché interna de su sistema operativo. A la hora de solucionar problemas o comprobar si una regla de «sinkhole» funciona según lo previsto, los administradores deben saber cómo vaciar el DNS en los terminales afectados para borrar las tablas de caché existentes y forzar una consulta inmediata al resolutor.

«Sinkhole» de DNS frente a filtrado de DNS frente a «blackhole» de DNS

En los debates sobre seguridad, los términos «sinkhole», «blackhole» y «filtrado» suelen utilizarse indistintamente. Aunque comparten el objetivo de mitigar las amenazas en la capa de resolución de nombres, funcionan de maneras distintas.

Un «blackhole» de DNS simplemente se niega a responder o indica al dispositivo que el registro no existe. Un «sinkhole» responde deliberadamente con una dirección que redirige al cliente a un entorno aislado, donde el personal de seguridad puede supervisar lo que el cliente intenta hacer a continuación.

Preguntas frecuentes

¿Un «sinkhole» de DNS es lo mismo que un «Pi-hole»?

Un Pi-hole es una implementación específica de un «sinkhole» de DNS diseñada para redes locales. Mientras que los «sinkholes» empresariales se centran principalmente en registrar las comunicaciones de las redes de bots y detectar infecciones de malware, un Pi-hole utiliza sobre todo técnicas de «sinkholing» para bloquear anuncios, el seguimiento web y las conexiones telemétricas no deseadas antes de que lleguen a las pantallas de los usuarios finales.

¿Qué dirección IP utiliza un «sinkhole»?

Un «sinkhole» suele utilizar una dirección no enrutable o una dirección colectora especializada. Entre las direcciones no enrutables más comunes se encuentran la 127.0.0.1 (la dirección de bucle invertido del host) o la 0.0.0.0 (una meta-dirección no enrutable). Cuando el objetivo es recabar pruebas forenses, el «sinkhole» devuelve la dirección IP interna privada de un servidor de monitorización dedicado que registra los detalles de las conexiones entrantes.

¿Puede el malware eludir un «sinkhole» de DNS?

Sí. El malware puede eludir un «sinkhole» de DNS incorporando direcciones IP sin formato en su código, lo que elimina por completo la necesidad de consultar nombres de dominio. También puede eludir los resolutores locales utilizando protocolos cifrados, como DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT), que apunten a servidores públicos externos, o modificando los archivos de configuración del sistema local.

¿Es legal el «sinkholing» de DNS?

Sí, dentro de la red interna de una organización, el «sinkholing» de DNS es una práctica habitual de seguridad. Los propietarios de las redes conservan plena autoridad sobre la forma en que sus servidores de resolución gestionan el tráfico interno. Cuando se aplica en Internet pública para tomar el control de dominios externos, el «sinkholing» requiere órdenes judiciales, la cooperación de los registros de dominios u operaciones coordinadas de las fuerzas del orden a nivel internacional.

Reflexiones finales

Los «sinkholes» de DNS constituyen una línea de defensa esencial para el tráfico saliente, ya que impiden que los equipos internos se comuniquen con infraestructuras maliciosas y permiten detectar infecciones ocultas. Sin embargo, proteger el tráfico que sale de tus estaciones de trabajo es solo la mitad de la batalla. También debes proteger el nombre de dominio de tu empresa para evitar que sea utilizado en ciberataques salientes contra socios y clientes externos.

Sin una supervisión continua, las desviaciones sutiles en la configuración, la creación no autorizada de registros o los punteros sueltos pueden dejar a tu organización expuesta al secuestro de dominios y a la suplantación de identidad en el correo electrónico. Con la supervisión automatizada supervisión automatizada de la seguridad y el cumplimiento normativo del DNS, podrá realizar un seguimiento en tiempo real de los cambios en sus zonas autoritativas, detectar modificaciones anómalas al instante y proteger la reputación de su dominio frente a manipulaciones no autorizadas.