Many organizations rely on external DNS and GSLB services for global traffic routing. The model appears practical, but zone content, query logs, geo decisions and traffic routing policies are all held on a platform outside the organization. For finance, government, healthcare and regulation-sensitive environments, this raises serious data sovereignty questions.
Outsourcing the GSLB decision layer also introduces operational continuity risk. An outage, configuration incident or API access problem at the external provider directly affects the organization's DC failover and DNS response policy. Your applications may be up, but traffic may not reach the right DC.
A separate disconnect emerges when authoritative DNS and health checking are different products. The health-check system sees that a DC is unhealthy, but if the DNS system does not reflect that automatically, a script, manual runbook or separate automation must bridge the gap. During an incident, that bridge becomes the weakest link.
The right approach is to consolidate authoritative DNS, health-check scenarios, DC failover and topology routing decisions on the same local platform. DNS responses should be regenerated on the appliance based on real DC health and traffic policy; query data and zone content must remain under organizational control.
TR7 On-Prem GSLB delivers this model: authoritative DNS and the GSLB decision engine run on the same platform, providing DC failover and geographic routing without data leaving the premises.
TR7 builds the on-prem GSLB architecture around authoritative DNS, a cloud-free decision model, health scenarios and a multi-DC priority chain.
TR7 does not split zone management and GSLB decisions across separate systems. DNS records, DC health, topology rules and response generation all operate within the same management model.
GeoIP databases run locally and DNS query context is never sent to an external service for decisioning. This approach provides a meaningful advantage for organizations with data-residency and sovereignty requirements.
When a DC or record becomes unhealthy, the corresponding IPs can be dropped from DNS responses automatically. There is no need for a manual script bridge between health-check results and DNS answers.
Each record can carry multiple DC entries and evaluate them in priority order. Primary, secondary, tertiary or DR chains are managed within a single record model.
On-Prem GSLB delivers DNS record management together with DC health, topology routing, DNSSEC and local statistics.
TR7 uses the authoritative DNS layer together with a locally running record database and decision logic. Zone data stays on premises and DNS responses are produced by the local platform. This reduces dependency on external DNS services. The organization operates its GSLB policy on its own appliances.
TR7 supports a wide DNS record set including A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSSEC-related records and other advanced types. This provides the flexibility needed for full zone management, not just simple A-record steering. Different service and security requirements can be brought under the same DNS management model. The organization manages its DNS architecture more consistently from a single point.
TR7 can use EDNS Client Subnet information to avoid making geographic decisions solely on the resolver IP. DC or record selection can be based on the real client subnet. This reduces the risk of users on public resolvers being directed to the wrong region. More accurate traffic distribution is achieved in global access scenarios.
TR7 topology rules can select DNS responses across network/CIDR, country, city, continent and ASN dimensions. Each rule can be written as a positive or negative condition. The same domain can therefore return different IP lists in different geographic or network contexts. Geo routing becomes more precise than a simple country-level split.
Each record can be managed with a recordConfig structure that carries the DC order. When the primary DC is unhealthy, secondary or tertiary DC records can be activated. This model allows a multi-DC priority chain to be built within a single record. Operators can apply different continuity strategies per domain or per record.
noResponse mode keeps a passive DC silent under normal conditions. onlyNew mode can prevent a DC that has been down for an extended period from serving responses based on outdated data. This behavior targets only DCs in the correct state — not just those that are technically up. Data consistency is preserved during failover and failback.
TR7 can run a recursive forwarder process alongside authoritative DNS. Internal zones are directed to the local authoritative layer while external domain resolution is handled through the forwarder. domainBasedForwarding can route specific domains to different resolution paths. This helps consolidate internal DNS and GSLB decisions within the same appliance family.
TR7 can offer signed zone management with DNSSEC support. NSEC/NSEC3, DNSSEC key cache and zone signing processes increase the verifiability of DNS responses. DNSSEC can be enabled or disabled on a per-domain basis. This strengthens the integrity security of critical domains.
TR7 can support zone transfer behavior in both primary and secondary DNS roles. AXFR and IXFR allow records to be carried between different DNS nodes. This simplifies integration with existing enterprise DNS architecture. Deploying on-prem GSLB does not require completely abandoning the existing DNS operation model.
Maintenance mode can be applied per DC. During planned maintenance, a DC can be removed from DNS responses even if it is healthy, and traffic is directed to another DC. When maintenance is complete, the normal health scenario resumes. This model provides a controlled cutover without manual zone changes.
TR7 can support dynamic DNS update behavior, allowing records to be updated by automation systems. This capability is valuable for variable infrastructure, automated service publication or temporary record needs. Record updates can be evaluated alongside the GTM decision model. Operations teams can reduce manual DNS tasks.
TR7 can collect statistics such as DNS queries, cache, rcode, qtype, latency, memory and uptime. Per-record query counts reveal which record receives how many queries. This data is available for local reporting and capacity planning without going to an external provider platform. DNS becomes a measurable traffic layer, not just a response generator.
On-prem GSLB operation covers port separation, cache TTL behavior, threading, SOA defaults, statistics collection, state file persistence and master election.
TR7 GTM components can use separate port ranges for authoritative DNS, API, forwarder inner and forwarder API processes. This separation makes it easier to monitor and manage each service independently. Operations teams can track the access and health status of each component individually.
Query cache, negative query cache, DNSSEC key cache and zone cache refresh intervals can all be derived from the primary cacheTtl value. This structure balances performance with freshness. Shorter TTLs allow faster propagation of changes; longer TTLs reduce query load.
Signing, distributor, receiver and retrieval processes can scale according to CPU core count. This approach increases parallel processing capacity under heavy DNS traffic. Threading settings should be planned based on hardware capacity and query profile.
Default SOA structure for new zones can be created with refresh, retry, expire and TTL values. These values determine the fundamental timing behavior of DNS operation. SOA values should be reviewed separately according to organizational requirements.
DNS statistics can be read via API and fed into RRD or similar time-series structures. Metrics such as qtype, rcode, cache hit/miss, UDP/TCP queries, latency and memory usage are tracked. This data is used for capacity planning and incident investigation.
DC information, local health state, scenario state, dynamic config and zone dynamic config can be stored at file level. After a restart, GTM can restore its previous evaluation context. This reduces unnecessary DNS fluctuation during transient service restarts.
Financial institutions can build a primary, secondary and tertiary DC chain. Internet and access health-check scenarios remove an unhealthy DC from DNS responses and redirect traffic to the backup DC.
Government organizations can run GTM without sending zone content, query logs or geo decision data to external DNS services. On-prem GSLB supports data sovereignty and audit expectations.
Hospital information systems and critical health services can be monitored with health-check scenarios. Unhealthy endpoints are removed from DNS responses automatically, reducing the need for manual intervention.
Telecom teams can select different DCs or PoP locations using geographic and network-based topology rules. Client subnet, country, ASN or CIDR information is included in DNS response decisions.
E-commerce teams can use weighted record behavior to direct a small share of traffic to a new IP group. As testing succeeds, the weight is increased until the transition completes in a controlled manner.
GTM nodes can operate in master and standby roles within an HA cluster. If the master node fails, the standby takes over the role and maintains continuous DNS response generation.
Authoritative DNS, DC failover, geographic routing and health-check scenarios — all running on the organization's own appliances. Let's walk through a setup that fits your infrastructure.