Muitas organizações dependem de serviços externos de DNS e GSLB para roteamento global de tráfego. O modelo parece prático, mas o conteúdo da zona, os logs de consulta, as decisões geo e as políticas de roteamento de tráfego são todos mantidos em uma plataforma fora da organização. Para finanças, governo, saúde e ambientes sensíveis a regulamentação, isso levanta questões sérias de soberania de dados.
Terceirizar a camada de decisão GSLB também introduz risco de continuidade operacional. Uma interrupção, incidente de configuração ou problema de acesso à API no provedor externo afeta diretamente a política de DC failover e de resposta DNS da organização. Suas aplicações podem estar up, mas o tráfego pode não alcançar o DC certo.
Uma desconexão separada surge quando o DNS autoritativo e o health checking são produtos diferentes. O sistema de health-check vê que um DC está não saudável, mas se o sistema DNS não reflete isso automaticamente, um script, runbook manual ou automação separada precisa fazer a ponte. Durante um incidente, essa ponte se torna o elo mais fraco.
A abordagem correta é consolidar DNS autoritativo, cenários de health-check, DC failover e decisões de roteamento por topologia na mesma plataforma local. As respostas DNS devem ser regeneradas no appliance com base na saúde real do DC e na política de tráfego; os dados de consulta e o conteúdo da zona devem permanecer sob controle organizacional.
O TR7 On-Prem GSLB entrega esse modelo: DNS autoritativo e motor de decisão GSLB rodam na mesma plataforma, fornecendo DC failover e roteamento geográfico sem os dados saírem das instalações.
O TR7 constrói a arquitetura de GSLB on-prem em torno de DNS autoritativo, um modelo de decisão livre de nuvem, cenários de saúde e uma cadeia de prioridade multi-DC.
O TR7 não divide o gerenciamento de zona e as decisões de GSLB entre sistemas separados. Registros DNS, saúde de DC, regras de topologia e geração de resposta operam todos dentro do mesmo modelo de gerenciamento.
Bancos GeoIP rodam localmente e o contexto da consulta DNS nunca é enviado a um serviço externo para tomada de decisão. Essa abordagem oferece uma vantagem significativa para organizações com requisitos de residência e soberania de dados.
Quando um DC ou registro se torna não saudável, os IPs correspondentes podem ser descartados das respostas DNS automaticamente. Não há necessidade de uma ponte manual de scripts entre os resultados de health-check e as respostas DNS.
Cada registro pode carregar múltiplas entradas de DC e avaliá-las em ordem de prioridade. Cadeias primária, secundária, terciária ou DR são gerenciadas dentro de um único modelo de registro.
O GSLB On-Prem entrega gerenciamento de registros DNS em conjunto com saúde de DC, roteamento por topologia, DNSSEC e estatísticas locais.
O TR7 usa a camada de DNS autoritativo em conjunto com um banco local de registros e lógica de decisão. Os dados de zona permanecem on-premises e as respostas DNS são produzidas pela plataforma local. Isso reduz a dependência de serviços DNS externos. A organização opera sua política de GSLB em seus próprios appliances.
O TR7 suporta um conjunto amplo de registros DNS, incluindo A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, registros relacionados a DNSSEC e outros tipos avançados. Isso fornece a flexibilidade necessária para gerenciamento completo de zona, não apenas steering simples de registros A. Diferentes requisitos de serviço e segurança podem ser trazidos sob o mesmo modelo de gerenciamento DNS. A organização gerencia sua arquitetura DNS de forma mais consistente a partir de um único ponto.
O TR7 pode usar informações de EDNS Client Subnet para evitar fazer decisões geográficas exclusivamente com base no IP do resolver. A seleção de DC ou registro pode ser baseada no subnet real do cliente. Isso reduz o risco de usuários em resolvers públicos serem direcionados à região errada. Distribuição de tráfego mais precisa é alcançada em cenários de acesso global.
As regras de topologia do TR7 podem selecionar respostas DNS em dimensões de rede/CIDR, país, cidade, continente e ASN. Cada regra pode ser escrita como uma condição positiva ou negativa. O mesmo domínio pode, portanto, retornar diferentes listas de IPs em diferentes contextos geográficos ou de rede. O roteamento geo fica mais preciso do que uma simples divisão no nível de país.
Cada registro pode ser gerenciado com uma estrutura recordConfig que carrega a ordem dos DCs. Quando o DC primário está não saudável, registros de DCs secundários ou terciários podem ser ativados. Esse modelo permite construir uma cadeia de prioridade multi-DC dentro de um único registro. Os operadores podem aplicar diferentes estratégias de continuidade por domínio ou por registro.
O modo noResponse mantém um DC passivo silencioso sob condições normais. O modo onlyNew pode impedir que um DC fora do ar há um período prolongado sirva respostas baseadas em dados desatualizados. Esse comportamento mira apenas em DCs no estado correto — não apenas naqueles tecnicamente up. A consistência dos dados é preservada durante failover e failback.
O TR7 pode rodar um processo de forwarder recursivo ao lado do DNS autoritativo. Zonas internas são direcionadas para a camada autoritativa local enquanto a resolução de domínios externos é tratada pelo forwarder. O domainBasedForwarding pode rotear domínios específicos para diferentes caminhos de resolução. Isso ajuda a consolidar DNS interno e decisões de GSLB dentro da mesma família de appliances.
O TR7 pode oferecer gerenciamento de zona assinada com suporte a DNSSEC. NSEC/NSEC3, cache de chaves DNSSEC e processos de assinatura de zona aumentam a verificabilidade das respostas DNS. O DNSSEC pode ser habilitado ou desabilitado por domínio. Isso fortalece a segurança de integridade de domínios críticos.
O TR7 pode suportar comportamento de transferência de zona em ambos os papéis primary e secondary. AXFR e IXFR permitem que registros sejam levados entre diferentes nós DNS. Isso simplifica a integração com a arquitetura DNS empresarial existente. Implantar GSLB on-prem não exige abandonar completamente o modelo de operação DNS existente.
O modo de manutenção pode ser aplicado por DC. Durante manutenção planejada, um DC pode ser removido das respostas DNS mesmo estando saudável e o tráfego é direcionado a outro DC. Quando a manutenção termina, o cenário de saúde normal retoma. Esse modelo fornece um cutover controlado sem alterações manuais de zona.
O TR7 pode suportar comportamento de atualização dinâmica de DNS, permitindo que registros sejam atualizados por sistemas de automação. Essa capacidade é valiosa para infraestrutura variável, publicação automatizada de serviços ou necessidades temporárias de registro. As atualizações de registro podem ser avaliadas ao lado do modelo de decisão GTM. As equipes de operação podem reduzir tarefas manuais de DNS.
O TR7 pode coletar estatísticas como consultas DNS, cache, rcode, qtype, latência, memória e uptime. Contagens de consultas por registro revelam quais registros recebem quantas consultas. Esses dados ficam disponíveis para relatórios locais e planejamento de capacidade sem ir à plataforma de um provedor externo. O DNS se torna uma camada de tráfego mensurável, não apenas um gerador de respostas.
A operação de GSLB on-prem cobre separação de portas, comportamento de TTL de cache, threading, padrões SOA, coleta de estatísticas, persistência de arquivo de estado e eleição de master.
Os componentes do TR7 GTM podem usar faixas de portas separadas para processos de DNS autoritativo, API, forwarder inner e forwarder API. Essa separação facilita monitorar e gerenciar cada serviço independentemente. As equipes de operação podem rastrear o status de acesso e saúde de cada componente individualmente.
Cache de consulta, cache de consulta negativa, cache de chaves DNSSEC e intervalos de refresh de cache de zona podem todos ser derivados do valor primário cacheTtl. Essa estrutura equilibra desempenho com atualidade. TTLs mais curtos permitem propagação mais rápida de mudanças; TTLs mais longos reduzem a carga de consultas.
Processos de assinatura, distribuidor, receptor e retrieval podem escalar conforme a contagem de núcleos de CPU. Essa abordagem aumenta a capacidade de processamento paralelo sob tráfego DNS intenso. As configurações de threading devem ser planejadas com base na capacidade do hardware e no perfil de consulta.
A estrutura SOA padrão para novas zonas pode ser criada com valores de refresh, retry, expire e TTL. Esses valores determinam o comportamento de tempo fundamental da operação DNS. Os valores SOA devem ser revisados separadamente conforme os requisitos da organização.
As estatísticas DNS podem ser lidas via API e alimentadas em estruturas de séries temporais tipo RRD. Métricas como qtype, rcode, cache hit/miss, consultas UDP/TCP, latência e uso de memória são rastreadas. Esses dados são usados para planejamento de capacidade e investigação de incidentes.
Informações de DC, estado de saúde local, estado de cenário, config dinâmica e config dinâmica de zona podem ser armazenadas em nível de arquivo. Após uma reinicialização, o GTM pode restaurar seu contexto de avaliação anterior. Isso reduz a flutuação desnecessária de DNS durante reinicializações transitórias de serviço.
Instituições financeiras podem construir uma cadeia de DCs primário, secundário e terciário. Cenários de health-check de internet e acesso removem um DC não saudável das respostas DNS e redirecionam o tráfego para o DC de backup.
Organizações governamentais podem rodar o GTM sem enviar conteúdo de zona, logs de consulta ou dados de decisão geo a serviços DNS externos. O GSLB on-prem suporta expectativas de soberania de dados e auditoria.
Sistemas de informação hospitalares e serviços críticos de saúde podem ser monitorados com cenários de health-check. Endpoints não saudáveis são removidos das respostas DNS automaticamente, reduzindo a necessidade de intervenção manual.
Equipes de telecom podem selecionar diferentes DCs ou localizações de PoP usando regras de topologia baseadas em geografia e rede. Informações de subnet do cliente, país, ASN ou CIDR são incluídas nas decisões de resposta DNS.
Equipes de e-commerce podem usar comportamento de registro ponderado para direcionar uma pequena parcela do tráfego a um novo grupo de IPs. Conforme o teste é bem-sucedido, o peso é aumentado até que a transição se complete de forma controlada.
Os nós do GTM podem operar em papéis master e standby dentro de um cluster HA. Se o nó master falha, o standby assume o papel e mantém a geração contínua de respostas DNS.
DNS autoritativo, DC failover, roteamento geográfico e cenários de health-check — todos rodando nos próprios appliances da organização. Vamos percorrer uma configuração que se ajuste à sua infraestrutura.