El DNS es la capa de seguridad y rendimiento más pasada por alto en la empresa.
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 Application Delivery Controller 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.
Nuestro enfoque
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.
Balanceo de carga inteligente entre backends DNS
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é.
El monitoreo activo de salud mantiene sano el camino DNS
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.
Las reglas de firewall DNS aplican política de seguridad en cada consulta
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.
Rate limiting y bloqueo dinámico a nivel DNS
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.
Capacidades
TR7 DNS Firewall y Application Delivery Controller 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.
Cinco algoritmos de balanceo de carga afinados para cargas DNS
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.
Resolución recursiva desde la raíz, con validación DNSSEC
El resolver recorre la cadena por sí mismo y valida las firmas de lo que vuelve, así una respuesta falsificada se rompe antes de entrar en caché. Regido por lista de acceso; un perfil solo-reenvío cubre redes sin salida a internet.
Zonas de política de respuesta alimentadas en vivo por AXFR/IXFR
La inteligencia de amenazas llega como zona DNS y se refresca en minutos sin reiniciar. Dispara por el nombre consultado, el cliente, la dirección devuelta o el servidor de nombres tras la zona — y una fuente que deja de refrescarse genera alarma en lugar de servirse obsoleta.
Cinco transportes cifrados terminados en el equipo
Do53, DoT, DoH, DoH sobre HTTP/3 y DNS over QUIC, además de DNSCrypt. Una frase en un pliego — «las consultas deben aceptarse por DNS over QUIC» — y el campo se reduce a una sola plataforma.
Los pools de servidores enrutan distintas categorías de consulta a distintos backends
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.
Health checks activos con múltiples tipos de sonda
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.
La caché de paquetes reduce la carga del backend y acelera la respuesta
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.
Coincidencia por regla sobre QName, QType, IP de origen y EDNS
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.
El conjunto de acciones cubre bloquear, descartar, refusar, truncar, suplantar y enrutar
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.
Detección de DGA y tunelización DNS
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.
Mitigación de ataques de amplificación en el gateway
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.
Políticas de control geográfico, ASN y acceso
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.
Soporte de transportes DNS modernos — DoT, DoH, DoQ
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.
Tratamiento de EDNS Client Subnet (ECS)
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.
Logging estructurado y métricas en tiempo real
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.
Métricas de consultas por zona y por registro, con distribución de RCODE
El DNS se mide, no se supone: recuentos de consultas por zona y por registro, distribuciones por tipo de consulta y código de respuesta (RCODE), visibilidad de aciertos y fallos de caché, e historial de comprobaciones de salud con registros de eventos de conmutación. Un aumento de SERVFAIL o NXDOMAIN pasa a ser una cifra en un panel en lugar de una llamada a soporte.
Profundidad operativa
DNS Firewall y Application Delivery Controller 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.
Orden de evaluación de reglas y semántica explícita
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.
Topología y selección de pool
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.
Ajuste de la caché de paquetes
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.
Selección de protocolo de transporte
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.
Retención de auditoría y streaming a SIEM
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.
Comportamiento de alta disponibilidad
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.
Cinco transportes cifrados, tres modos de resolución, un motor de políticas
La consulta llega cifrada, se resuelve en el modo que usted eligió y se responde bajo una política legible. <b>DNS over QUIC se termina aquí — ninguna plataforma competidora de entrega de aplicaciones lo termina.</b>
Transportes cifrados — terminados en el equipo
Resolución — autoritativa, recursiva, de reenvío
Política — zonas de política de respuesta y acciones de firewall
Cuándo utilizarlo
Endurecimiento del DNS interno empresarial
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.
Protección de resolver recursivo expuesto al público
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.
Prevención de exfiltración de datos basada en DNS
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.
Línea frontal de DNS autoritativo para TR7 GTM
Cuando TR7 GTM sirve DNS autoritativo para aplicaciones multi-región, DNS Firewall y Application Delivery Controller 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.
Preguntas frecuentes
¿Es esto lo mismo que TR7 GTM?
¿Qué transportes DNS están soportados?
¿Cómo protege esto frente al malware DGA?
¿Se convierte el gateway en sí mismo en un vector de amplificación?
¿Podemos cachear respuestas firmadas con DNSSEC?
¿Cómo trabaja esto junto con TR7 ADC y TR7 WAAP?
Lleve el DNS a la misma capa de entrega y protección que su tráfico HTTP
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.