Resumen
- RRL reduce respuestas similares y repetidas de un servidor autoritativo cuando consultas UDP falsificadas podrían convertirlo en amplificador.
- La participación de Paul Vixie fue importante, pero compartida: ISC relata sesiones defensivas con él y un registro de desarrollo de BIND también nombra a Vernon Schryver.
- El sistema agrupa clases de respuesta y rangos de clientes. Ese agrupamiento regula tráfico; no autentica, atribuye ni demuestra intención.
La respuesta puede convertirse en la carga
En una reflexión DNS, una consulta llega a un servidor autoritativo con la dirección de la víctima falsificada como origen. La respuesta del servidor termina entonces en la víctima. Si ocupa mucho más que la consulta, el atacante ha puesto al servidor a enviar más datos de los que él mismo transmitió.
La presentación de ISC de 2014 ofrece un ejemplo: una consulta ANY de 36 bytes para isc.org podía obtener una respuesta de 3.576 bytes. La cifra ilustra el atractivo de la reflexión; no es una proporción universal. El tamaño depende de la pregunta, los datos de la zona, DNSSEC, el transporte y la respuesta. La cuestión operativa es más concreta: ¿cuántas respuestas reiteradas y parecidas debe seguir enviando un servidor autoritativo cuando las consultas se parecen entre sí?
ISC afirma que las sesiones de estrategia defensiva de la organización con Paul Vixie desembocaron en RRL. Un ticket de desarrollo de BIND atribuye el parche de BIND 9 a Vixie y Vernon Schryver. El registro respalda la participación central de Vixie, pero no una historia de inventor único. La defensa surgió del trabajo práctico de un equipo, de la implementación y de ajustes posteriores.
El perfil de Internet Hall of Fame sitúa ese episodio dentro de una carrera más amplia en DNS. Señala que Vixie empezó a mantener BIND 4 en Digital Equipment Corporation en 1988 y que después fue autor principal y arquitecto técnico de BIND 8. También fundó MAPS, PAIX e Internet Software Consortium y realizó su doctorado en Keio University con un trabajo relacionado con DNS y DNSSEC. Estos hitos muestran el alcance de su trabajo, sin cambiar el crédito compartido del parche de RRL, que también nombra a Schryver.
BIND 9.9.4 incorporó RRL como función opcional de compilación. La página de ISC « BIND 9.10 Significant Changes » indica que luego pasó a la configuración de compilación predeterminada. Eso documenta disponibilidad en BIND; no demuestra que todos los operadores autoritativos la activaran ni que los demás productos DNS funcionen igual.
El cubo de créditos mide semejanza, no identidad
El manual actual de BIND 9.20.29 describe cubos de tokens o créditos definidos por respuestas similares y clientes DNS. Cada respuesta consume créditos y el ritmo configurado los repone durante una ventana. El operador puede limitar categorías como respuestas no vacías, NODATA, NXDOMAIN, referencias, errores o todas las respuestas UDP. Al superar el límite, BIND puede descartar o modificar ciertas respuestas.
La palabra «cliente» encierra una decisión de política. Los valores predeterminados documentados de BIND agrupan direcciones IPv4 por /24 e IPv6 por /56: las direcciones de cada bloque se cuentan juntas. Un resolvedor, una empresa, un campus o un proveedor de acceso puede poner a muchos usuarios sin relación entre sí detrás del mismo prefijo. Si uno agota el cubo, otro usuario del bloque puede recibir una respuesta tardía, truncada o ninguna respuesta.
Eso no convierte el agrupamiento por prefijo en un error automático. Un límite por dirección puede esquivarse distribuyendo consultas entre muchas direcciones, y durante una inundación el servidor debe repartir una capacidad de salida escasa. El prefijo, la clase de respuesta y la tasa tienen un coste de disponibilidad. Son decisiones explícitas de operación, no una observación neutral de quién es «realmente» el cliente.
La opción slip de BIND deja claro el equilibrio. Con slip=2, valor predeterminado documentado, cada segunda consulta limitada que no lleve una cookie de servidor válida recibe una respuesta menor: BADCOOKIE si el cliente presentó una cookie; en caso contrario, el bit de truncamiento pide repetir por TCP. Algunos errores no se pueden truncar y se permiten a la tasa indicada. slip=1 envía respuestas truncadas para todos los límites y prioriza integridad y entrega frente a la máxima reducción de reflexión; slip=0 descarta toda respuesta limitada. El camino de reintento forma parte de la defensa.
El tipo de servicio cambia el coste
ISC recomienda RRL en servidores autoritativos. Sus guías advierten que usarlo en recursión puede producir falsos positivos y ralentizar a clientes que consultan repetidamente los mismos nombres; es preferible cerrar la recursión abierta. Una misma función puede costar de forma distinta en un servicio autoritativo público y en uno que atiende a usuarios finales.
BIND ofrece log-only para observar límites candidatos antes de aplicarlos; entre los contadores están RateDropped, QryDropped, RateSlipped y RespTruncated. Estos describen lo que hace o haría el mecanismo configurado, pero no identifican al atacante. Una dirección de origen puede estar falsificada y pertenecer a un cubo no es atribución.
La Nota 65 de Heng Lu aporta aquí solo una lente editorial: el comportamiento en ejecución muestra qué controla realmente una implementación. No es evidencia histórica sobre Vixie ni evidencia técnica sobre RRL. Para evaluar esta función importan la versión desplegada de BIND, su configuración, los contadores y las reintentos de los clientes, no la mera presencia de una directiva en un documento.
La conclusión respaldada es acotada. RRL puede reducir la contribución de un servidor autoritativo de respuestas similares a un ataque por reflexión. También puede agrupar usuarios legítimos y negociar entre entrega y supresión. No autentica consultas, no determina motivos, no mide la adopción general ni garantiza que una víctima no reciba tráfico reflejado. La contribución de Vixie se entiende mejor como su papel en convertir una defensa operativa en una función configurable cuyos límites los operadores pueden examinar.
Fuentes
- ISC, presentación DNS Response Rate Limiting (LISA 2014)
- ISC, lanzamiento de BIND 9.9.4
- ISC, BIND 9.10 Significant Changes
- Ticket de desarrollo de ISC que identifica a los autores del parche RRL para BIND 9
- Manual del administrador BIND 9.20.29
- Base de conocimiento de ISC: Response Rate Limiting
- ISC: RRL y servidores recursivos
- ISC: configuración de RRL
- ISC, Cache poisoning gets a second wind from RRL? Probably not
- Internet Hall of Fame: Paul Vixie
- Retrato de Paul Vixie publicado por Internet Hall of Fame, referencia de identidad
- Heng Lu, Nota 65: Running-Code Primacy (solo como lente editorial)
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
