Em uma arquitetura GTM, uma mudança no estado de health-check pode mudar a resposta DNS — mas uma operação raramente é apenas uma resposta DNS. Quando um data center fica offline, o sistema de alarme, sistema de ticketing, automação de DR, pipeline de auditoria e a equipe de aplicação precisam todos saber. Sem essa conexão, o GTM toma a decisão enquanto o resto da cadeia operacional da organização fica sabendo tarde demais.
Resolver isso com uma camada separada de orquestração é possível, mas isso significa um novo serviço, novas credenciais, novo monitoramento e um novo ponto de falha. O health check já roda dentro do GTM; propagar mudanças de estado para sistemas externos deve ser gerenciado a partir da mesma plataforma.
No lado do forwarding DNS, o problema é semelhante. Alguns domínios pertencem ao DNS interno, alguns a um resolver externo, alguns à própria zona autoritativa do TR7. Quando um forwarder simples envia tudo para um único destino, split-DNS, zonas internas, domínios de parceiros e comportamentos de geo-roteamento colidem.
Se as informações ECS são perdidas, o problema se aprofunda. Decisões baseadas em geo e topologia dependem do contexto de rede do cliente; se o forwarder descarta esse contexto, o roteamento geográfico upstream pode ser feito contra a localização errada. Um forwarder não deve apenas carregar a consulta — deve também preservar o contexto da decisão.
Os Gatilhos e Forwarders do TR7 GTM amarram mudanças de estado de health-check a cadeias de ação HTTP/HTTPS ou Oracle DB e tornam o forwarding DNS operacionalmente gerenciável por meio de encaminhamento seletivo por domínio, forward de zona para localhost e pass-through de ECS.
O TR7 desenha o GTM não meramente como um motor DNS que responde consultas, mas como uma camada operacional ativa que reage ao estado de saúde e encaminha consultas DNS conforme o contexto.
Quando o estado base do cenário HC muda, as ações turn ou return podem rodar. Quando o cenário é ativado, triggerTurnActions executa em ordem; quando retorna ao normal, triggerReturnActions executa em ordem.
Os gatilhos HTTP/HTTPS são definidos com método, URI, cabeçalhos, corpo, códigos de status esperados e timeout. O corpo da resposta pode ser validado com um content check JSONata ou básico para determinar se a ação foi bem-sucedida.
Os gatilhos Oracle operam com uma string de conexão e um array de passos de cenário. Passos wait e executeCmd podem rodar verificações ou ações contra o banco de dados; contagens esperadas de linhas ou valores de texto esperados podem ser verificados.
O forwarder pode enviar domínios específicos para alvos DNS específicos; um alvo padrão pode ser definido para o domínio raiz. O pass-through de ECS preserva o contexto de subnet do cliente para que as decisões de geo-roteamento não sejam quebradas.
Os Gatilhos e Forwarders do GTM reúnem ações de health-check, validação HTTP/HTTPS e Oracle, fluxos encadeados de gatilhos e forwarding DNS seletivo em um único modelo de gerenciamento.
Um gatilho HTTP é definido com endereço de destino, porta, método de requisição, URI, lista de cabeçalhos e corpo da requisição. Uma lista de códigos de status esperados determina se a chamada foi bem-sucedida. Um timeout limita chamadas longas a sistemas externos. Alvos baseados em HTTP, como runbooks de DR, endpoints de auditoria ou sistemas de alarme, podem ser disparados por meio desse modelo.
Um gatilho HTTPS aplica o mesmo modelo de requisição que o HTTP, sobre TLS. A flag verifyCertificate determina se o certificado de destino é validado. Manter a validação de certificado habilitada é recomendado em produção. Esse padrão é usado para entregar mudanças de cenário do GTM a sistemas externos seguros de ação.
As respostas de gatilho HTTP/HTTPS podem ser parseadas como JSON ou XML e validadas com uma expressão JSONata. O contexto da expressão inclui body, bodyRaw, headers e status. Por exemplo, mesmo que o sistema externo de runbook retorne 200, um campo success=true dentro do corpo da resposta pode ser verificado separadamente. Isso permite uma validação de gatilho mais robusta que não depende apenas do código de status.
Onde JSONata não é necessário, um content check básico pode ser usado. O corpo da resposta é testado quanto à presença de uma string específica usando semântica .includes(). Isso é suficiente para integrações pequenas, sistemas legados ou endpoints que retornam uma resposta simples de saúde. Os operadores podem validar rapidamente sem escrever uma expressão complexa.
Um gatilho Oracle conecta ao banco de dados com usuário, senha e string de conexão. Os passos de cenário podem incluir operações wait e executeCmd. Contagens esperadas de linhas ou valores de texto esperados de executeCmd podem ser verificados. Esse modelo é usado para validar de forma cruzada o estado do banco de dados da aplicação ou para executar ações controladas no lado do banco.
Os arrays triggerTurnActions e triggerReturnActions executam múltiplos IDs de gatilho em ordem. Se uma ação falha, a cadeia se rompe e ações subsequentes não rodam. Isso impede que passos dependentes de runbook avancem de forma descontrolada. Fluxos como escrever em um endpoint de auditoria primeiro e depois iniciar um job de DR podem ser construídos dessa forma.
turn representa o momento em que o cenário é ativado; return representa o momento em que ele é desativado e retorna ao normal. Uma lista de gatilhos e condição separadas podem ser definidas para cada direção. Diferentes ações podem disparar durante o failover e durante a recuperação. Essa separação permite um design mais limpo dos fluxos operacionais.
Quando uma nova chave de grupo chega, processos antigos de gatilho podem ser interrompidos. O ciclo de vida do gatilho é rastreado com entradas de log started, succeeded e failed; após um curto atraso, o evento activeTrigger é limpo. Esse comportamento reduz a chance de ações antigas colidirem com um novo fluxo quando mudanças de estado de saúde ocorrem em rápida sucessão. O serviço principal permanece isolado do fork de gatilho.
Em um cluster, os gatilhos rodam apenas no nó master. Outros nós que veem a mesma mudança de estado de saúde não re-disparam a ação externa. Isso impede o duplo disparo de ações de webhook ou DB. O comportamento do cluster fica mais determinístico.
A camada de forwarder é posicionada como um processo recursor separado. Recebe consultas DNS pela faixa forwarderInnerPort e as encaminha aos alvos upstream definidos. O DNS autoritativo e o comportamento de forwarding recursor ficam desacoplados. Essa separação permite que o TR7 gerencie suas próprias zonas e a resolução DNS externa de forma controlada dentro da mesma arquitetura.
A lista domainBasedForwarding permite que domínios específicos sejam direcionados a endereços DNS específicos. Domínios internos podem ir para o DNS corporativo; outras consultas podem ir para o resolver upstream padrão. Esse design importa para arquiteturas split-DNS e DNS híbridas. Vai além de um forwarder grosseiro que envia toda consulta a um único destino.
O forwarder passa informações ECS para resolvers upstream para que possam tomar decisões com contexto de subnet do cliente. O comportamento ECS é controlado por meio das configurações ecs-ipv4-bits, ecs-add-for e allow-list. Esse contexto é crítico para roteamento geo ou decisões upstream baseadas em topologia. Se o ECS é descartado, o roteamento geográfico pode ser feito contra a localização errada do resolver.
Os gatilhos do GTM e o forwarder são operados em conjunto com comportamento de timeout, rastreamento de ciclo de vida, isolamento de processo filho, prioridade de parse, ordenação de zonas de forward e linhas de metadados.
O timeout padrão para um gatilho HTTP pode ser de 120 segundos. Um gatilho Oracle pode rodar mais tempo dependendo do próprio tempo de processamento. O processo geral de gatilho pode ser limitado em 24 horas — um limite superior importante para runbooks longos ou cenários multi-passo de banco de dados.
Não há retry automático na cadeia de gatilhos. Se um gatilho falha, a cadeia se rompe e ações subsequentes não rodam. Os sistemas de destino devem, portanto, ser desenhados para serem idempotentes e confiáveis.
Os gatilhos são registrados com estados started, succeeded e failed. Esses registros mostram qual ação rodou durante um evento de failover ou recuperação. O estado de gatilho ativo é limpo após um curto atraso.
A execução de gatilho pode rodar como um processo filho separado. Esse modelo impede que o serviço principal do GTM seja afetado por chamadas externas longas ou operações de DB. Um gatilho que falha não derruba o serviço principal.
O corpo da resposta HTTP é primeiro parseado como JSON, depois como XML, com base no tipo de conteúdo. Se nenhum dos dois tem sucesso, um fallback para string bruta é usado. A expressão JSONata é avaliada contra esse contexto.
As linhas forward-zones-recurse são produzidas em uma ordem definida. A primeira definição de forward de domínio é escrita como linha primária; definições subsequentes são escritas como linhas adicionais. Essa ordenação importa para a aplicação limpa do comportamento de forwarding seletivo.
O campo forwarder.metaData carrega linhas adicionais de configuração do recursor. Fornece um ponto de extensão para configurações customizadas de cache, política ou operacionais. Linhas de metadados em uso devem ser validadas com cuidado.
Quando o cenário de health-check é ativado, um gatilho HTTP POST dispara. O sistema de alarme ou de gerenciamento de incidentes recebe a notificação de data center caído. A decisão de failover de DNS fica visível para o sistema externo de operações no mesmo momento.
Quando um cenário DR é ativado, um gatilho HTTPS pode iniciar um job na plataforma de automação. O primeiro gatilho cria um registro de auditoria; o segundo gatilho executa o job de bring-up de DR. Se a cadeia de gatilhos falha, o próximo passo não avança de forma descontrolada.
Em cada evento turn e return, um gatilho HTTP pode enviar um registro de evento ao endpoint de auditoria. Informações sobre qual zona, qual cenário e em qual horário a mudança ocorreu são enviadas ao sistema externo de log. As decisões do GTM se tornam auditáveis.
Quando um heartbeat de aplicação falha, um gatilho Oracle pode rodar uma verificação independente no DB. Se a contagem de linhas ou o valor de texto esperado é retornado, o evento é validado de forma cruzada. Isso produz um sinal de decisão mais forte sem depender unicamente do resultado de health-check HTTP.
Domínios como internal.example.com podem ser encaminhados a alvos DNS corporativos via domainBasedForwarding. Outras consultas vão para o DNS upstream padrão. As próprias zonas autoritativas do TR7 podem ser encaminhadas ao processo DNS local via localhost.
Clientes internos podem resolver domínios de aplicação internos pelo recursor corporativo, enquanto clientes externos recebem respostas autoritativas do TR7 GTM. Forwarding seletivo e pass-through de ECS usados juntos desacoplam o comportamento de resolução interna e externa. A arquitetura DNS não fica travada em forwarding unidirecional.
Cadeias de gatilhos HTTP/HTTPS e Oracle DB, forwarding DNS seletivo e um recursor ciente de ECS. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.