Muchas organizaciones dependen de servicios externos de DNS y GSLB para el routing de tráfico global. El modelo parece práctico, pero el contenido de zona, los logs de consulta, las decisiones geo y las políticas de routing de tráfico se mantienen todos en una plataforma fuera de la organización. Para entornos sensibles de finanzas, gobierno, sanidad y regulación, esto plantea serias cuestiones de soberanía de datos.
Externalizar la capa de decisión GSLB también introduce riesgo de continuidad operativa. Una caída, un incidente de configuración o un problema de acceso a API en el proveedor externo afecta directamente al DC failover y a la política de respuesta DNS de la organización. Sus aplicaciones pueden estar arriba, pero el tráfico puede no llegar al DC correcto.
Una desconexión separada emerge cuando el DNS autoritativo y el health checking son productos distintos. El sistema de health-check ve que un DC está en mal estado, pero si el sistema DNS no lo refleja automáticamente, un script, un runbook manual o una automatización separada deben cerrar la brecha. Durante un incidente, ese puente se convierte en el eslabón más débil.
El enfoque correcto es consolidar el DNS autoritativo, los escenarios de health-check, el DC failover y las decisiones de routing por topología en la misma plataforma local. Las respuestas DNS deberían regenerarse en el appliance basándose en la salud real del DC y la política de tráfico; los datos de consulta y el contenido de zona deben permanecer bajo control de la organización.
TR7 On-Prem GSLB entrega este modelo: el DNS autoritativo y el motor de decisión GSLB se ejecutan en la misma plataforma, proporcionando DC failover y routing geográfico sin que los datos salgan de las instalaciones.
TR7 construye la arquitectura GSLB on-prem en torno al DNS autoritativo, un modelo de decisión sin nube, escenarios de salud y una cadena de prioridad multi-DC.
TR7 no divide la gestión de zona y las decisiones GSLB entre sistemas separados. Los registros DNS, la salud del DC, las reglas de topología y la generación de respuestas operan todos dentro del mismo modelo de gestión.
Las bases de datos GeoIP corren localmente y el contexto de consulta DNS nunca se envía a un servicio externo para la decisión. Este enfoque proporciona una ventaja significativa para organizaciones con requisitos de residencia de datos y soberanía.
Cuando un DC o registro queda en mal estado, las IPs correspondientes pueden eliminarse automáticamente de las respuestas DNS. No hay necesidad de un puente manual de script entre los resultados de health-check y las respuestas DNS.
Cada registro puede llevar múltiples entradas de DC y evaluarlas en orden de prioridad. Las cadenas primario, secundario, terciario o DR se gestionan dentro de un único modelo de registro.
GSLB On-Prem entrega gestión de registros DNS junto con salud de DC, routing por topología, DNSSEC y estadísticas locales.
TR7 usa la capa DNS autoritativa junto con una base de datos local de registros y lógica de decisión. Los datos de zona permanecen on-premises y las respuestas DNS son producidas por la plataforma local. Esto reduce la dependencia de servicios DNS externos. La organización opera su política GSLB sobre sus propios appliances.
TR7 soporta un conjunto amplio de registros DNS que incluye A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, registros relacionados con DNSSEC y otros tipos avanzados. Esto proporciona la flexibilidad necesaria para la gestión completa de zona, no solo la dirección simple por registro A. Distintos requisitos de servicio y seguridad pueden traerse al mismo modelo de gestión DNS. La organización gestiona su arquitectura DNS de forma más consistente desde un único punto.
TR7 puede usar la información EDNS Client Subnet para evitar tomar decisiones geográficas únicamente sobre la IP del resolver. La selección de DC o registro puede basarse en la subred real del cliente. Esto reduce el riesgo de que usuarios en resolvers públicos sean dirigidos a la región equivocada. Se logra una distribución de tráfico más precisa en escenarios de acceso global.
Las reglas de topología de TR7 pueden seleccionar respuestas DNS a través de las dimensiones red/CIDR, país, ciudad, continente y ASN. Cada regla puede escribirse como condición positiva o negativa. El mismo dominio puede así devolver listas de IPs distintas en contextos geográficos o de red distintos. El geo routing se vuelve más preciso que una simple división por país.
Cada registro puede gestionarse con una estructura recordConfig que lleva el orden de DC. Cuando el DC primario está en mal estado, pueden activarse los registros de DC secundario o terciario. Este modelo permite construir una cadena de prioridad multi-DC dentro de un único registro. Los operadores pueden aplicar distintas estrategias de continuidad por dominio o por registro.
El modo noResponse mantiene un DC pasivo en silencio en condiciones normales. El modo onlyNew puede evitar que un DC que ha estado caído un periodo prolongado sirva respuestas basadas en datos desactualizados. Este comportamiento apunta solo a DCs en el estado correcto — no simplemente a los que están técnicamente up. La consistencia de datos se preserva durante el failover y el failback.
TR7 puede ejecutar un proceso forwarder recursivo junto al DNS autoritativo. Las zonas internas se dirigen a la capa autoritativa local mientras que la resolución de dominios externos se gestiona a través del forwarder. domainBasedForwarding puede enrutar dominios específicos a caminos de resolución distintos. Esto ayuda a consolidar las decisiones de DNS interno y GSLB dentro de la misma familia de appliances.
TR7 puede ofrecer gestión de zona firmada con soporte DNSSEC. NSEC/NSEC3, la caché de claves DNSSEC y los procesos de firma de zona aumentan la verificabilidad de las respuestas DNS. DNSSEC puede habilitarse o deshabilitarse por dominio. Esto refuerza la seguridad de integridad de dominios críticos.
TR7 puede soportar comportamiento de transferencia de zona tanto en rol de primario como de secundario. AXFR e IXFR permiten transportar registros entre distintos nodos DNS. Esto simplifica la integración con la arquitectura DNS empresarial existente. Desplegar GSLB on-prem no requiere abandonar por completo el modelo de operación DNS existente.
El modo mantenimiento puede aplicarse por DC. Durante un mantenimiento planificado, un DC puede eliminarse de las respuestas DNS incluso si está sano, y el tráfico se dirige a otro DC. Cuando el mantenimiento se completa, el escenario de salud normal se reanuda. Este modelo proporciona un cutover controlado sin cambios manuales de zona.
TR7 puede soportar comportamiento de actualización dinámica DNS, permitiendo que los registros sean actualizados por sistemas de automatización. Esta capacidad es valiosa para infraestructura variable, publicación automatizada de servicios o necesidades temporales de registros. Las actualizaciones de registros pueden evaluarse junto con el modelo de decisión del GTM. Los equipos de operaciones pueden reducir tareas DNS manuales.
TR7 puede recopilar estadísticas como consultas DNS, caché, rcode, qtype, latencia, memoria y uptime. Los conteos de consulta por registro revelan qué registro recibe cuántas consultas. Estos datos están disponibles para reportes locales y planificación de capacidad sin ir a una plataforma de proveedor externo. El DNS se vuelve una capa de tráfico medible, no solo un generador de respuestas.
La operación GSLB on-prem cubre la separación de puertos, el comportamiento de TTL de caché, el threading, los valores por defecto de SOA, la recolección de estadísticas, la persistencia de fichero de estado y la elección de maestro.
Los componentes de TR7 GTM pueden usar rangos de puertos separados para los procesos de DNS autoritativo, API, forwarder inner y forwarder API. Esta separación hace más fácil monitorizar y gestionar cada servicio de forma independiente. Los equipos de operaciones pueden rastrear el estado de acceso y salud de cada componente individualmente.
Los intervalos de refresco de caché de consultas, caché negativa de consultas, caché de claves DNSSEC y caché de zona pueden derivarse del valor cacheTtl primario. Esta estructura equilibra rendimiento y frescura. TTLs más cortos permiten una propagación más rápida de los cambios; los más largos reducen la carga de consulta.
Los procesos de firma, distribuidor, receptor y recuperación pueden escalar según el número de núcleos de CPU. Este enfoque incrementa la capacidad de procesamiento paralelo bajo tráfico DNS pesado. Los ajustes de threading deben planificarse según la capacidad del hardware y el perfil de consultas.
La estructura SOA por defecto para nuevas zonas puede crearse con valores refresh, retry, expire y TTL. Estos valores determinan el comportamiento temporal fundamental de la operación DNS. Los valores SOA deben revisarse por separado según los requisitos de la organización.
Las estadísticas DNS pueden leerse vía API y alimentarse a RRD u otras estructuras similares de series temporales. Se rastrean métricas como qtype, rcode, cache hit/miss, consultas UDP/TCP, latencia y uso de memoria. Estos datos se usan para planificación de capacidad e investigación de incidentes.
La información de DC, el estado local de salud, el estado de escenarios, la configuración dinámica y la configuración dinámica de zona pueden almacenarse a nivel de fichero. Tras un reinicio, el GTM puede restaurar su contexto de evaluación anterior. Esto reduce fluctuaciones DNS innecesarias durante reinicios transitorios de servicio.
Las instituciones financieras pueden construir una cadena primario, secundario y terciario de DCs. Los escenarios de health-check de internet y acceso eliminan un DC en mal estado de las respuestas DNS y redirigen el tráfico al DC de backup.
Las organizaciones gubernamentales pueden operar el GTM sin enviar contenido de zona, logs de consulta o datos de decisión geo a servicios DNS externos. GSLB On-Prem da soporte a la soberanía de datos y a las expectativas de auditoría.
Los sistemas de información hospitalaria y los servicios sanitarios críticos pueden monitorizarse con escenarios de health-check. Los endpoints en mal estado se eliminan automáticamente de las respuestas DNS, reduciendo la necesidad de intervención manual.
Los equipos de telecomunicaciones pueden seleccionar distintos DCs o ubicaciones PoP usando reglas de topología basadas en geografía y red. La información de subred del cliente, país, ASN o CIDR se incluye en las decisiones de respuesta DNS.
Los equipos de e-commerce pueden usar comportamiento de registro ponderado para dirigir una pequeña fracción del tráfico a un nuevo grupo de IPs. A medida que las pruebas tienen éxito, se incrementa el peso hasta completar la transición de forma controlada.
Los nodos GTM pueden operar en roles maestro y standby dentro de un clúster HA. Si el nodo maestro falla, el standby asume el rol y mantiene la generación continua de respuestas DNS.
DNS autoritativo, DC failover, routing geográfico y escenarios de health-check — todo ejecutándose sobre los propios appliances de la organización. Hagamos un recorrido por una configuración que encaje con su infraestructura.