In a GTM architecture, a change in health-check state can change the DNS response — but an operation is rarely just a DNS answer. When a data center goes offline, the alarm system, ticketing system, DR automation, audit pipeline and application team all need to know. Without that connection, GTM makes the decision while the rest of the organization's operation chain learns about it too late.
Solving this with a separate orchestration layer is possible, but that means a new service, new credentials, new monitoring and a new failure point. The health check already runs inside GTM; propagating state changes to external systems should be managed from the same platform.
On the DNS forwarding side the problem is similar. Some domains belong on the internal DNS, some on an external resolver, some on TR7's own authoritative zone. When a simple forwarder sends everything to a single destination, split-DNS, internal zones, partner domains and geo-routing behaviors collide.
If ECS information is lost the problem deepens. Geo and topology-based decisions depend on client network context; if the forwarder drops that context, geographic routing upstream can be made against the wrong location. A forwarder should not just carry the query — it should preserve the decision context as well.
TR7 GTM Triggers and Forwarders bind health-check state changes to HTTP/HTTPS or Oracle DB action chains, and make DNS forwarding operationally manageable through selective domain forwarding, localhost zone forward and ECS pass-through.
TR7 designs GTM not merely as a DNS engine that answers queries, but as an active operations layer that reacts to health state and forwards DNS queries according to context.
When the HC scenario base state changes, turn or return actions can run. When the scenario activates, triggerTurnActions executes in order; when it returns to normal, triggerReturnActions executes in order.
HTTP/HTTPS triggers are defined with method, URI, headers, body, expected status codes and timeout. The response body can be validated with a JSONata or basic content check to determine whether the action succeeded.
Oracle triggers operate with a connection string and a scenario step array. wait and executeCmd steps can run checks or actions against the database; expected row counts or expected text values can be verified.
The forwarder can send specific domains to specific DNS targets; a default target can be defined for the root domain. ECS pass-through preserves the client subnet context so geo-routing decisions are not broken.
GTM Triggers and Forwarders bring health-check actions, HTTP/HTTPS and Oracle validation, chained trigger flows and selective DNS forwarding together in a single management model.
An HTTP trigger is defined with destination address, port, request method, URI, header list and request body. A list of expected status codes determines whether the call succeeded. A timeout limits long-running external system calls. HTTP-based targets such as DR runbooks, audit endpoints or alarm systems can all be fired through this model.
An HTTPS trigger applies the same request model as HTTP, over TLS. The verifyCertificate flag determines whether the target certificate is validated. Keeping certificate validation enabled is recommended in production. This pattern is used to deliver GTM scenario changes to secure external action systems.
HTTP/HTTPS trigger responses can be parsed as JSON or XML and validated with a JSONata expression. The expression context includes body, bodyRaw, headers and status. For example, even if the external runbook system returns 200, a success=true field inside the response body can be checked separately. This enables more robust trigger validation that does not rely on status code alone.
Where JSONata is not needed, a basic content check can be used. The response body is tested for the presence of a specific string using .includes() semantics. This is sufficient for small integrations, legacy systems or endpoints that return a simple health response. Operators can validate quickly without writing a complex expression.
An Oracle trigger connects to the database with a user, password and connection string. Scenario steps can include wait and executeCmd operations. Expected row counts or expected text values from executeCmd can be verified. This model is used to cross-validate application database state or to run controlled actions on the database side.
The triggerTurnActions and triggerReturnActions arrays execute multiple trigger IDs in order. If one action fails, the chain breaks and subsequent actions do not run. This prevents dependent runbook steps from advancing uncontrolled. Flows such as writing to an audit endpoint first and then starting a DR job can be built this way.
turn represents the moment the scenario activates; return represents the moment it deactivates and returns to normal. A separate trigger list and condition can be defined for each direction. Different actions can fire during failover and during recovery. This separation allows cleaner design of operational flows.
When a new group key arrives, old trigger processes can be stopped. The trigger lifecycle is tracked with started, succeeded and failed log entries; after a short delay the activeTrigger event is cleared. This behavior reduces the chance of old actions colliding with a new flow when health state changes occur in rapid succession. The main service stays isolated from the trigger fork.
In a cluster, triggers run only on the master node. Other nodes that see the same health state change do not re-fire the external action. This prevents double-firing of webhook or DB actions. Cluster behavior becomes more deterministic.
The forwarder layer is positioned as a separate recursor process. It receives DNS queries over the forwarderInnerPort range and forwards them to defined upstream targets. Authoritative DNS and recursor forwarding behavior are decoupled. This separation lets TR7 manage its own zones and external DNS resolution in a controlled way within the same architecture.
The domainBasedForwarding list lets specific domains be steered to specific DNS addresses. Internal domains can go to the corporate DNS; other queries can go to the default upstream resolver. This design matters for split-DNS and hybrid DNS architectures. It moves beyond a coarse forwarder that sends every query to a single destination.
The forwarder passes ECS information to upstream resolvers so they can make decisions with client subnet context. ECS behavior is controlled through ecs-ipv4-bits, ecs-add-for and allow-list settings. This context is critical for geo-routing or topology-based upstream decisions. If ECS is dropped, geographic routing can be made against the wrong resolver location.
GTM triggers and the forwarder are operated together with timeout behavior, lifecycle tracking, child process isolation, parse priority, forward zone ordering and metadata lines.
The default timeout for an HTTP trigger can be 120 seconds. An Oracle trigger may run longer depending on its own processing time. The overall trigger process can be capped at 24 hours — an important upper bound for long runbooks or multi-step database scenarios.
There is no automatic retry in the trigger chain. If a trigger fails, the chain breaks and subsequent actions do not run. Target systems should therefore be designed to be idempotent and reliable.
Triggers are logged with started, succeeded and failed states. These records show which action ran during a failover or recovery event. The active trigger state is cleared after a short delay.
Trigger execution can run as a separate child process. This model prevents the main GTM service from being affected by long-running external calls or DB operations. A failing trigger does not bring down the main service.
The HTTP response body is parsed first as JSON, then as XML, based on content type. If neither succeeds, a raw string fallback is used. The JSONata expression is evaluated against this context.
forward-zones-recurse lines are produced in a defined order. The first domain forward definition is written as the primary line; subsequent definitions are written as additional lines. This ordering matters for the clean application of selective forwarding behavior.
The forwarder.metaData field carries additional recursor configuration lines. It provides an extension point for custom cache, policy or operational settings. Metadata lines in use should be carefully validated.
When the health-check scenario activates, an HTTP POST trigger fires. The alarm or incident management system receives the data center down notification. The DNS failover decision becomes visible to the external operations system at the same moment.
When a DR scenario activates, an HTTPS trigger can start a job in the automation platform. The first trigger creates an audit record; the second trigger runs the DR bring-up job. If the trigger chain fails, the next step does not advance uncontrolled.
On every turn and return event, an HTTP trigger can send an event record to the audit endpoint. Information about which zone, which scenario and at what time the change occurred is pushed to the external log system. GTM decisions become auditable.
When an application heartbeat fails, an Oracle trigger can run an independent DB check. If the expected row count or text value is returned, the event is cross-validated. This produces a stronger decision signal without relying solely on the HTTP health-check result.
Domains such as internal.example.com can be forwarded to corporate DNS targets through domainBasedForwarding. Other queries go to the default upstream DNS. TR7's own authoritative zones can be forwarded to the local DNS process via localhost.
Internal clients can resolve internal application domains through the corporate recursor while external clients receive TR7 GTM authoritative responses. Selective forwarding and ECS pass-through used together decouple internal and external resolution behavior. The DNS architecture is not locked into single-direction forwarding.
HTTP/HTTPS and Oracle DB trigger chains, selective DNS forwarding and an ECS-aware recursor. Let's walk through a live setup in your own environment.