La mayoría de las organizaciones invierten años en afinar su estrategia de balanceo de carga HTTP, en construir una protección WAAP profunda para tráfico web, y sin embargo tratan su infraestructura DNS como un único servidor recursivo con una IP estática. Ese único servidor se convierte tanto en un cuello de botella de rendimiento como en un objetivo de ataque de alto valor.
En el plano del rendimiento, una capa DNS lenta empuja la latencia a cada transacción cara al usuario. Sin un balanceo de carga adecuado, un resolver saturado retrasa cada búsqueda subsiguiente — y los clústeres DNS basados en anycast tradicionales son difíciles de gestionar en centros de datos privados donde se requiere control on-prem.
En el plano de la seguridad, los atacantes saben que el DNS rara vez se inspecciona. Las herramientas de tunelización DNS extraen gigabytes de datos a través de registros TXT de aspecto inocuo; el malware con DGA contacta miles de dominios generados aleatoriamente buscando command-and-control; las campañas de amplificación DNS abusan de resolvers abiertos como vectores de reflexión; y los clientes stub en redes de invitados consultan al resolver upstream que quieran, saltándose el resto de controles de seguridad que la organización haya puesto en marcha.
TR7 DNS Firewall y Balanceador de Carga trata el DNS como un protocolo de aplicación de primera clase que merece el mismo balanceo de carga, gestión de salud, caché y aplicación de política de seguridad que ya reciben los servicios HTTP.
TR7 trata el DNS como un protocolo de aplicación de primera clase: las consultas obtienen balanceo de carga completo y entrega consciente de la salud desde el lado ADC, y pasan por un motor de política desde el lado WAAP — sin salir del mismo gateway.
Múltiples algoritmos — round-robin, least-outstanding, hash consistente, weighted random y weighted hash — distribuyen las consultas DNS entre pools de resolvers o autoritativos. Cada algoritmo se asocia a su carga de trabajo: round-robin para pools simétricos, least-outstanding para tiempos de respuesta variables del backend, hash consistente para escenarios de afinidad de caché.
Health checks configurables sondean continuamente los backends DNS — comprobaciones de consulta UDP, comprobaciones de consulta TCP, comprobaciones de resolución de nombre personalizadas. Los servidores en mal estado salen de rotación en segundos; la recuperación los reincorpora automáticamente. El mismo modelo de salud que el resto de TR7 usa para pools HTTP se aplica a los pools DNS.
Coincidencia por regla en nombre de consulta, tipo de consulta, IP de origen, opciones EDNS, expresiones regulares y combinaciones de estas. Las acciones incluyen bloquear, descartar, refusar, truncar, suplantar una respuesta controlada, enrutar a un pool distinto o etiquetar la consulta para inspección downstream. La política se evalúa antes de que la consulta llegue a ningún backend.
Los límites de tasa pueden aplicarse por IP de origen, por nombre de consulta, por tipo de consulta o por dimensión combinada. Los bloqueos dinámicos se activan automáticamente cuando los patrones de tráfico cruzan los umbrales definidos por el operador — un único origen que inunda el gateway con consultas NXDOMAIN se ralentiza o bloquea temporalmente sin intervención del operador.
TR7 DNS Firewall y Balanceador de Carga lleva al protocolo DNS toda la filosofía de gestión de tráfico de TR7 — balanceo de carga, health checks, caché, política y observabilidad.
Round-robin para pools uniformes, least-outstanding para backends con tiempo de respuesta variable, hash consistente y weighted hash para escenarios de afinidad de caché donde la misma consulta debe llegar al mismo backend, y weighted random para desplazamientos graduales de tráfico. Cada vService elige su propio algoritmo; los algoritmos pueden cambiarse en vivo sin reinicio.
Los dominios corporativos internos pueden resolverse a través de un pool, los dominios públicos a través de otro, las zonas de partner a través de un tercero. Las reglas de routing por pool dirigen las consultas según patrones de QName, rangos de IP de origen o etiquetas de política coincidentes. El mismo gateway sirve múltiples arquitecturas DNS de forma limpia.
Sondas de consulta DNS TCP y UDP, sondas personalizadas de resolución de nombre y comprobaciones de respuesta basadas en tiempo verifican continuamente la salud del backend. Los parámetros de umbral definen cuántas comprobaciones fallidas disparan la retirada y cuántas exitosas reinstauran un backend. Los backends lentos pueden retirarse incluso aunque respondan — evitando latencia visible para el usuario.
Los registros solicitados con frecuencia se cachean en el gateway con invalidación consciente del TTL. La caché respeta DNSSEC donde corresponda y puede saltarse selectivamente para zonas sensibles. El ratio de aciertos de caché se expone en métricas en tiempo real para que los operadores vean exactamente cuánta carga absorbe el gateway.
Las reglas de firewall coinciden con cualquier combinación de nombre de consulta (exacto, sufijo, regex), tipo de consulta (A, AAAA, TXT, MX, ANY, etc.), IP de origen, EDNS Client Subnet, opciones EDNS y flags de petición. Las condiciones pueden combinarse con lógica AND/OR. Las reglas se evalúan en el orden definido por el operador con semántica explícita allow/deny.
Bloquear devuelve un error controlado; descartar tira silenciosamente; refusar devuelve REFUSED; truncar fuerza el fallback a TCP (útil contra amplificación); suplantar devuelve una respuesta controlada (bloqueo por NXDOMAIN, redirección a sinkhole, devolución de una alternativa segura); enrutar envía la consulta a un pool distinto. Las acciones de etiquetado marcan las consultas para inspección downstream sin alterar la respuesta.
La detección basada en patrones y estadística identifica consultas contra dominios generados algorítmicamente (C2 de malware DGA) y cargas TXT/CNAME inusuales características de la exfiltración de datos basada en DNS. Las consultas detectadas pueden bloquearse, redirigirse a sinkhole o registrarse solo para revisión del analista.
Los ataques de amplificación DNS abusan de resolvers abiertos para inundar objetivos con tráfico reflejado. TR7 detecta consultas ANY, patrones de respuestas grandes e indicadores de spoofing de origen, aplicando rate limiting de respuesta y acciones de validación de origen antes de que ninguna reflexión llegue al cable. El gateway nunca se convierte en un vector de amplificación.
Las consultas pueden evaluarse por país de origen, ASN, rango de IP o ventana temporal. Las políticas de lista de bloqueo, lista de permitidos y acción condicional se aplican en la capa DNS de la misma forma que se aplican en la capa HTTP de TR7 WAAP — usando el mismo editor de política y el mismo modelo de aplicación.
DNS over TLS (DoT, RFC 7858), DNS over HTTPS (DoH, RFC 8484) y DNS over QUIC (DoQ, RFC 9250) se terminan en el gateway. La gestión de certificados usa el mismo almacén de certificados de TR7 que los servicios HTTP. Los resolvers stub modernos y los clientes DoH de navegador se conectan de forma nativa.
La información ECS pasada por los resolvers downstream puede ser honrada, sobreescrita, enmascarada a un prefijo que preserve la privacidad o eliminada por completo. El comportamiento es por política, permitiendo cumplimiento de privacidad para algunos flujos mientras se preserva la precisión geográfica para otros.
Cada consulta, decisión y acción se escribe en un flujo de log estructurado con formato compatible con SIEM. Las métricas en tiempo real exponen tasa de consultas, tiempo de respuesta, ratio de aciertos de caché, salud del backend y contadores de coincidencias de regla. Los operadores ven el tráfico DNS con la misma profundidad de observabilidad que el resto de TR7 ofrece para HTTP.
DNS Firewall y Balanceador de Carga se opera junto con el orden de reglas, la topología de pools, el ajuste de la caché, la elección de protocolo de transporte y la retención de auditoría.
Las reglas de firewall se evalúan de arriba abajo con first-match-wins por defecto. Las etiquetas por regla permiten que las reglas downstream actúen de forma diferente según coincidencias previas. Las reglas allow explícitas en lo alto de la cadena fijan el tráfico conocido como bueno antes de que se apliquen las reglas genéricas de bloqueo, eliminando falsos positivos en producción.
Los pools backend agrupan resolvers por propósito: corporativo interno, recursión pública, zonas de partner, pool sinkhole. Las reglas de routing por pool dirigen las consultas según QName, IP de origen o etiquetas coincidentes. Los umbrales de failover por pool evitan que un único backend en mal estado absorba todo el tráfico.
Tamaño de caché, comportamiento de TTL, caché consciente de ECS y bypass selectivo para zonas sensibles son todos controlados por el operador. El caching de respuestas negativas (NXDOMAIN, NODATA) reduce la carga del backend para cargas de alta tasa de NX típicas de redes infectadas con DGA.
DNS plano UDP/TCP, DoT, DoH y DoQ pueden habilitarse por listener de vService. Los clientes modernos negocian su transporte preferido; los más antiguos hacen fallback a UDP. La política de certificados y cifrados se alinea con el pool central de perfiles TLS de TR7.
Los registros de auditoría por consulta pueden retenerse durante ventanas de cumplimiento; puede aplicarse muestreo para entornos de alto volumen. Los logs JSON estructurados se transmiten directamente al SIEM. Los operadores eligen entre retención completa, retención muestreada y retención solo de eventos por pool.
Las sesiones DNS son sin estado a nivel de protocolo, así que el failover entre nodos activos es transparente para la mayoría de consultas. Las sesiones DNS TCP y las conexiones DoH largas se coordinan entre el par HA para minimizar la disrupción. El estado de health-check y el estado de caché se gestionan de forma independiente por nodo.
Los resolvers corporativos que sirven a la red interna ganan rate limiting, filtrado de consultas, logging de auditoría y alta disponibilidad. Los endpoints ya no pueden consultar resolvers externos arbitrarios; los hosts infectados con DGA se detectan y bloquean en el gateway.
Las organizaciones que operan servicios DNS públicos — ISPs, proveedores de hosting, portales del sector público — terminan los ataques de amplificación en el gateway. El rate limiting, la validación de origen y las comprobaciones de patrones de respuesta evitan que el resolver sea abusado como vector de reflexión.
Las redes sanitarias, financieras y gubernamentales añaden una capa de detección para técnicas de exfiltración y tunelización basadas en registros TXT. Los flujos sospechosos se redirigen a sinkhole o se registran con contexto completo de sesión para revisión del analista.
Cuando TR7 GTM sirve DNS autoritativo para aplicaciones multi-región, DNS Firewall y Balanceador de Carga se coloca delante de GTM como capa de rate limiting, caché y firewall. GTM se mantiene centrado en la inteligencia de routing; el gateway absorbe el tráfico hostil.
Balanceo de carga inteligente, health checks activos, transportes modernos y un motor de reglas de firewall completo — todo en un gateway. Permítanos hacer un recorrido en vivo sobre su infraestructura DNS.