En una arquitectura GTM, un cambio en el estado de health-check puede cambiar la respuesta DNS — pero una operación rara vez es solo una respuesta DNS. Cuando un centro de datos queda fuera de servicio, el sistema de alarma, el ticketing, la automatización DR, el pipeline de auditoría y el equipo de aplicación necesitan saberlo. Sin esa conexión, el GTM toma la decisión mientras el resto de la cadena operativa de la organización se entera demasiado tarde.
Resolver esto con una capa de orquestación separada es posible, pero significa un nuevo servicio, nuevas credenciales, nueva monitorización y un nuevo punto de fallo. El health check ya corre dentro del GTM; la propagación de los cambios de estado a sistemas externos debería gestionarse desde la misma plataforma.
En el lado del reenvío DNS, el problema es similar. Algunos dominios pertenecen al DNS interno, algunos a un resolver externo, algunos a la zona autoritativa propia de TR7. Cuando un forwarder simple envía todo a un único destino, el split-DNS, las zonas internas, los dominios de partner y los comportamientos de geo-routing entran en conflicto.
Si se pierde la información ECS, el problema se agrava. Las decisiones basadas en geo y topología dependen del contexto de red del cliente; si el forwarder descarta ese contexto, el routing geográfico upstream puede hacerse contra la ubicación equivocada. Un forwarder no debería limitarse a llevar la consulta — también debería preservar el contexto de decisión.
Triggers y Forwarders de TR7 GTM atan los cambios de estado de health-check a cadenas de acción HTTP/HTTPS u Oracle DB, y hacen que el reenvío DNS sea operativamente manejable mediante reenvío selectivo por dominio, reenvío de zona a localhost y pass-through de ECS.
TR7 diseña el GTM no solo como un motor DNS que responde consultas, sino como una capa de operaciones activa que reacciona al estado de salud y reenvía las consultas DNS según el contexto.
Cuando cambia el estado base del escenario HC, pueden ejecutarse las acciones turn o return. Cuando el escenario se activa, triggerTurnActions se ejecuta en orden; cuando vuelve a la normalidad, triggerReturnActions se ejecuta en orden.
Los triggers HTTP/HTTPS se definen con método, URI, cabeceras, cuerpo, códigos de estado esperados y timeout. El cuerpo de la respuesta puede validarse con una comprobación JSONata o de contenido básica para determinar si la acción tuvo éxito.
Los triggers Oracle operan con una cadena de conexión y un array de pasos de escenario. Los pasos wait y executeCmd pueden ejecutar comprobaciones o acciones contra la base de datos; pueden verificarse conteos de filas esperados o valores de texto esperados.
El forwarder puede enviar dominios específicos a destinos DNS específicos; puede definirse un destino por defecto para el dominio raíz. El pass-through de ECS preserva el contexto de subred del cliente para que las decisiones de geo-routing no se rompan.
Triggers y Forwarders del GTM reúnen las acciones de health-check, la validación HTTP/HTTPS y Oracle, los flujos de triggers encadenados y el reenvío DNS selectivo en un único modelo de gestión.
Un trigger HTTP se define con dirección de destino, puerto, método de petición, URI, lista de cabeceras y cuerpo de petición. Una lista de códigos de estado esperados determina si la llamada tuvo éxito. Un timeout limita las llamadas a sistemas externos de larga duración. Objetivos basados en HTTP como runbooks DR, endpoints de auditoría o sistemas de alarma pueden todos dispararse mediante este modelo.
Un trigger HTTPS aplica el mismo modelo de petición que HTTP, sobre TLS. El flag verifyCertificate determina si se valida el certificado del destino. Se recomienda mantener la validación de certificado habilitada en producción. Este patrón se usa para entregar cambios de escenario del GTM a sistemas de acción externos seguros.
Las respuestas de los triggers HTTP/HTTPS pueden parsearse como JSON o XML y validarse con una expresión JSONata. El contexto de la expresión incluye body, bodyRaw, headers y status. Por ejemplo, aunque el sistema de runbook externo devuelva 200, puede comprobarse por separado un campo success=true dentro del cuerpo de respuesta. Esto habilita una validación de trigger más robusta que no se basa solo en el código de estado.
Cuando no se necesita JSONata, puede usarse una comprobación de contenido básica. Se prueba que el cuerpo de la respuesta contenga una cadena específica usando semántica de .includes(). Esto es suficiente para integraciones pequeñas, sistemas heredados o endpoints que devuelven una respuesta de salud simple. Los operadores pueden validar rápidamente sin escribir una expresión compleja.
Un trigger Oracle se conecta a la base de datos con un usuario, contraseña y cadena de conexión. Los pasos de escenario pueden incluir operaciones wait y executeCmd. Pueden verificarse conteos de filas o valores de texto esperados desde executeCmd. Este modelo se usa para validar de forma cruzada el estado de base de datos de la aplicación o para ejecutar acciones controladas en el lado de la base de datos.
Los arrays triggerTurnActions y triggerReturnActions ejecutan múltiples IDs de trigger en orden. Si una acción falla, la cadena se rompe y las acciones posteriores no se ejecutan. Esto evita que pasos dependientes del runbook avancen sin control. Pueden construirse así flujos como escribir primero a un endpoint de auditoría y luego iniciar un job DR.
turn representa el momento en que el escenario se activa; return representa el momento en que se desactiva y vuelve a la normalidad. Pueden definirse una lista de triggers y una condición separadas para cada dirección. Pueden dispararse acciones distintas durante el failover y durante la recuperación. Esta separación permite un diseño más limpio de los flujos operativos.
Cuando llega una nueva clave de grupo, los procesos de trigger antiguos pueden detenerse. El ciclo de vida del trigger se rastrea con entradas de log started, succeeded y failed; tras un breve retraso el evento activeTrigger se limpia. Este comportamiento reduce la posibilidad de que acciones antiguas colisionen con un nuevo flujo cuando se producen cambios de estado de salud en sucesión rápida. El servicio principal permanece aislado del fork del trigger.
En un clúster, los triggers se ejecutan solo en el nodo maestro. Otros nodos que ven el mismo cambio de estado de salud no vuelven a disparar la acción externa. Esto evita el doble disparo de acciones webhook o DB. El comportamiento del clúster se vuelve más determinista.
La capa forwarder se posiciona como un proceso recursor separado. Recibe consultas DNS sobre el rango forwarderInnerPort y las reenvía a los destinos upstream definidos. El comportamiento de DNS autoritativo y de reenvío de recursor se desacopla. Esta separación permite a TR7 gestionar sus propias zonas y la resolución DNS externa de forma controlada dentro de la misma arquitectura.
La lista domainBasedForwarding permite dirigir dominios específicos a direcciones DNS específicas. Los dominios internos pueden ir al DNS corporativo; otras consultas pueden ir al resolver upstream por defecto. Este diseño importa para arquitecturas split-DNS y DNS híbridas. Va más allá de un forwarder grueso que envía cada consulta a un único destino.
El forwarder pasa la información ECS a los resolvers upstream para que puedan tomar decisiones con contexto de subred del cliente. El comportamiento de ECS se controla mediante los ajustes ecs-ipv4-bits, ecs-add-for y allow-list. Este contexto es crítico para decisiones upstream basadas en geo o topología. Si se descarta el ECS, el routing geográfico puede hacerse contra la ubicación equivocada del resolver.
Los triggers GTM y el forwarder se operan junto con el comportamiento de timeout, el rastreo del ciclo de vida, el aislamiento de procesos hijos, la prioridad de parseo, el orden de zonas de reenvío y las líneas de metadatos.
El timeout por defecto para un trigger HTTP puede ser de 120 segundos. Un trigger Oracle puede correr más tiempo dependiendo de su propio procesamiento. El proceso global del trigger puede limitarse a 24 horas — un límite superior importante para runbooks largos o escenarios de base de datos multietapa.
No hay reintento automático en la cadena de triggers. Si un trigger falla, la cadena se rompe y las acciones posteriores no se ejecutan. Los sistemas destino deberían diseñarse por tanto para ser idempotentes y fiables.
Los triggers se registran con estados started, succeeded y failed. Estos registros muestran qué acción se ejecutó durante un evento de failover o recuperación. El estado de trigger activo se limpia tras un breve retraso.
La ejecución de triggers puede correr como un proceso hijo separado. Este modelo evita que el servicio principal del GTM se vea afectado por llamadas externas o operaciones de BD de larga duración. Un trigger que falla no derriba el servicio principal.
El cuerpo de la respuesta HTTP se parsea primero como JSON, luego como XML, según el content type. Si ninguno tiene éxito, se usa un fallback a cadena bruta. La expresión JSONata se evalúa contra este contexto.
Las líneas forward-zones-recurse se producen en un orden definido. La primera definición de reenvío por dominio se escribe como línea primaria; las definiciones posteriores se escriben como líneas adicionales. Este orden importa para la aplicación limpia del comportamiento de reenvío selectivo.
El campo forwarder.metaData lleva líneas adicionales de configuración del recursor. Proporciona un punto de extensión para ajustes personalizados de caché, política u operativos. Las líneas de metadatos en uso deben validarse cuidadosamente.
Cuando el escenario de health-check se activa, se dispara un trigger HTTP POST. El sistema de alarmas o de gestión de incidentes recibe la notificación de caída del centro de datos. La decisión de failover DNS se hace visible para el sistema operativo externo en el mismo momento.
Cuando se activa un escenario DR, un trigger HTTPS puede iniciar un job en la plataforma de automatización. El primer trigger crea un registro de auditoría; el segundo trigger ejecuta el job de levantamiento DR. Si la cadena de triggers falla, el siguiente paso no avanza sin control.
En cada evento turn y return, un trigger HTTP puede enviar un registro de evento al endpoint de auditoría. La información sobre qué zona, qué escenario y a qué hora ocurrió el cambio se envía al sistema de logs externo. Las decisiones del GTM se vuelven auditables.
Cuando un heartbeat de aplicación falla, un trigger Oracle puede ejecutar una comprobación independiente en BD. Si se devuelve el conteo de filas esperado o el valor de texto esperado, el evento se valida de forma cruzada. Esto produce una señal de decisión más fuerte sin depender únicamente del resultado del health-check HTTP.
Dominios como internal.example.com pueden reenviarse a destinos DNS corporativos mediante domainBasedForwarding. Otras consultas van al DNS upstream por defecto. Las zonas autoritativas propias de TR7 pueden reenviarse al proceso DNS local vía localhost.
Los clientes internos pueden resolver dominios de aplicación internos a través del recursor corporativo mientras los clientes externos reciben respuestas autoritativas de TR7 GTM. El reenvío selectivo y el pass-through de ECS usados juntos desacoplan el comportamiento de resolución interna y externa. La arquitectura DNS no queda bloqueada en un reenvío de dirección única.
Cadenas de trigger HTTP/HTTPS y Oracle DB, reenvío DNS selectivo y un recursor consciente de ECS. Hagamos un recorrido en vivo en su propio entorno.