El mismo dominio, dos respuestas distintas
Primera solicitud
resuelve a una IP pública
Validación
se supera: parece segura
Vence el TTL
segundos después
Segunda solicitud
resuelve a 127.0.0.1
Qué es el DNS rebinding y por qué debería importarte
La mayoría de las comprobaciones de seguridad que involucran un dominio dan por hecho que su dirección IP es lo bastante estable como para validarla una vez y confiar en ella después. El DNS rebinding explota exactamente esa suposición. Un atacante controla el DNS de un dominio y lo configura para que, al principio, resuelva a una dirección IP pública normal, superando cualquier validación que realice el sistema objetivo, y después cambia la respuesta a una dirección interna (como 127.0.0.1 o un rango interno 10.x.x.x) para una solicitud posterior, cuando la comprobación ya se ha superado.
Por qué es más que un truco teórico
Un TTL muy corto hace que el ataque sea viable: el atacante configura el registro para que caduque en unos segundos, de modo que una comprobación de validación y la solicitud real que la sigue pueden ver dos respuestas distintas, con milisegundos de diferencia, sin que el sistema víctima se dé cuenta de que el terreno ha cambiado bajo sus pies. Cualquier sistema que resuelva un dominio una sola vez y reutilice esa IP en varias operaciones (o, peor aún, que lo resuelva una vez para validarlo y deje que otro componente lo resuelva de nuevo para la solicitud real) está potencialmente expuesto.
La única defensa fiable
Validar la cadena del nombre de host no basta, y validar una IP una sola vez tampoco. La única defensa sólida es comprobar la dirección realmente resuelta frente a una lista de bloqueo de rangos privados o internos en el punto en que se establece la conexión, cada vez y no solo en la validación inicial. Eso cierra el desfase temporal del que depende el rebinding, porque ya no hay ninguna ventana entre «comprobado» y «usado» para que la respuesta cambie.
- Bloquea los rangos privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), el bucle local (127.0.0.0/8), el de enlace local (169.254.0.0/16) y los endpoints de metadatos de la nube, tanto para IPv4 como para IPv6.
- Vuelve a comprobar en cada uso, no solo una vez al validar la entrada.
- Trata una dirección IPv6 mapeada a IPv4 (como ::ffff:127.0.0.1) como equivalente a la dirección IPv4 que lleva incrustada: los intentos de rebinding a veces usan precisamente esta codificación para esquivar una comprobación ingenua pensada solo para IPv6.
| Enfoque | ¿Cierra la brecha del rebinding? |
|---|---|
| Validar una sola vez la cadena del nombre de host | No: no dice nada sobre a qué se resuelve |
| Resolver una vez y reutilizar la IP en solicitudes posteriores | No: el registro puede cambiar antes de la reutilización |
| Resolver y comprobar la lista de bloqueo en cada uso | Sí: no queda ninguna ventana para que cambie la respuesta |
Dónde ha importado en la práctica
El DNS rebinding no es una preocupación académica marginal: se ha usado repetidamente contra routers domésticos, hubs de domótica y otros dispositivos que exponen una interfaz de administración local sin autenticación, bajo el supuesto de que solo el tráfico local de confianza podría llegar a ella. Una página web maliciosa, abierta en una pestaña normal del navegador dentro de la misma red, puede usar rebinding para que el propio navegador de la víctima (en el que el router ya confía simplemente por estar en la red local) envíe solicitudes directamente a esa interfaz de administración en nombre del atacante. El navegador cree todo el tiempo que sigue hablando con el dominio público original; lo único que cambió fue la respuesta DNS que hay por debajo.
Una variante más sutil: rebinding con varias respuestas
Una versión más sofisticada se salta por completo la espera a que caduque un TTL. Una sola respuesta DNS puede contener legítimamente más de un registro A, y algunos clientes simplemente los prueban en orden, o incluso rotan entre ellos en solicitudes distintas. Un atacante puede devolver una dirección pública legítima y una interna en la misma respuesta, confiando en que el cliente acabe probando la segunda entrada: sin esperas, sin ventana temporal, aprovechando solo que el DNS nunca se diseñó para garantizar que todas las direcciones de una respuesta con varias entradas sean igual de fiables. Es un buen recordatorio de que «comprobar la primera dirección devuelta» nunca es suficiente: cada dirección de una respuesta merece el mismo escrutinio.
¿Necesitas comprobar las direcciones DNS públicas de un dominio? Usa la herramienta Domain IP Lookup.
Lecturas relacionadas
Los registros que encontrarás en casi toda zona
Qué es un registro CAA: controla qué CA emiten certificados
Aprende cómo los registros DNS CAA nombran a los emisores de certificados permitidos y cómo evitar errores comunes de configuración.
Una consulta DNS recursiva, salto a salto
Navegador
quiere example.com
Resolvedor
tu ISP / 1.1.1.1
Raíz + TLD
¿quién gestiona .com?
Autoritativo
la respuesta real
Cada salto de la cadena es otra consulta DNS, y luego se guarda en caché
DNSSEC explicado: cómo se autentican las respuestas DNS
Descubre qué hacen las firmas DNSSEC y los registros DS y DNSKEY, cómo funciona la validación y cómo un error de configuración causa respuestas SERVFAIL.
Cada rango IPv4 tiene un equivalente IPv6
Seguridad en IPv6: consideraciones que no debes ignorar
Desde el punto de vista de la seguridad, IPv6 no es solo «IPv4 con más direcciones»: algunas de sus diferencias cambian de verdad el modelo de amenazas.