Capability

DNS Geographic Routing

Shape DNS responses based on the user's real client subnet — not the resolver's location.

TR7 DNS Geographic Routing does not make DNS decisions solely based on the IP of the forwarding resolver. With EDNS Client Subnet support, the real client subnet can be factored in, producing more accurate responses at the region, country, city, network or ASN level. Geographic routing does not stop at "pick a DC by country." TR7 lets you define topology rules across five dimensions: network/CIDR, country, city, continent and ASN. Each rule can be written as a positive or negative condition — returning a specific answer for certain countries, a separate IP for certain ASNs, or an alternative record excluding specific networks. GeoIP decisions are made using offline databases stored on the device. DNS query context is never sent to an external service for geographic resolution — a significant advantage in environments with data residency or privacy requirements. The result: TR7 GTM elevates geographic DNS routing beyond simple country-based selection, turning it into a precise, controlled, on-prem DNS decision layer driven by client subnet, CIDR, city, ASN, fallback logic and selector behavior.

5
Geographic decision dimensions: network, country, city, continent, ASN
3
Offline GeoLite2 databases: ASN, City, Country
32-bit
IPv4 ECS subnet precision

DNS routing based on resolver IP does not always reflect the user's real location.

In classic geographic DNS solutions, decisions are usually made based on the DNS resolver's IP address. When a user relies on a remote public resolver, however, the DNS system sees the resolver's location rather than the user's actual position. As a result, a user in Turkey may be directed to a data center in the wrong region or an unnecessarily distant PoP.

Single-layer, country-only routing is also insufficient for most enterprise scenarios. Within the same country, different carriers, different ASNs, different cities or different private network blocks may each require separate routing. Needs such as telco peering, compliance, latency, CDN-like PoP selection and campaign routing all demand finer granularity.

Using an online GeoIP API for geographic decisions introduces additional risk. Sending DNS query context to an external service can create problems for data residency and query privacy. Having a critical traffic decision layer like GTM depend on an external API is also a weak point for operational continuity.

The correct model is to support client subnet information, make geographic decisions using offline databases on the device, and extend topology rules beyond the country level to include city, ASN and CIDR. Producing a controlled final response through fallback records when no match is found should be part of the same model.

TR7 DNS Geographic Routing delivers exactly this: EDNS Client Subnet, five-dimensional topology rules, offline GeoIP databases and selector-based record selection bring DNS responses closer to the real user context.

Our approach

TR7 implements geographic DNS decisions through client subnet, multi-dimensional topology, offline GeoIP and a Lua-based selection pipeline.

EDNS Client Subnet uses real client subnet instead of resolver location

With EDNS Client Subnet support, the DNS decision is no longer bound to the resolver IP alone. Geographic decisions are made from the actual client subnet, enabling more accurate DC or PoP selection.

Five-dimensional topology goes beyond country-level decisions

TR7 can define rules across network/CIDR, country, city, continent and ASN. Each rule can be written with normal or negate behavior.

Offline GeoIP databases keep query context on-device

Geographic decisions are made using ASN, City and Country databases stored locally on the device. DNS query context is never sent to an external GeoIP service.

The topology pipeline evaluates rules, conditions and records together

TR7 evaluates topology rules in order and selects matching record candidates using selector logic. Different distribution strategies can be built with all, closest, round-robin, weighted or random behavior.

Capabilities

DNS Geographic Routing produces country, city, ASN and CIDR-based DNS responses with client subnet precision.

EDNS Client Subnet support enables decisions closer to the user's real location

TR7 can factor in client subnet information instead of relying on the resolver IP. This reduces the risk of clients using public resolvers being directed to the wrong region. Geographic DNS decisions move closer to the real user network. This is especially critical for accurate DC selection in services with global user traffic.

Country-based routing meets compliance and performance requirements

Country granularity allows different DNS responses to be produced based on the client's country code. Data center selection can be tailored to Europe, Turkey, the Middle East or a specific country. Country-level control is important for financial institutions, public sector organizations and environments with data residency requirements. Country codes are normalized for more consistent matching.

Continent-based routing provides broad regional traffic distribution

Continent granularity allows clients to be directed to different record groups at the continent level. Separate PoP or DC sets can be defined for Europe, Asia, North America or other regions. This approach offers a simple solution where country-level detail is not required but regional proximity matters. It is useful in global SaaS and content delivery scenarios.

City-based routing supports local campaigns and PoP selection

City granularity matches users from specific cities to different records. Separate landing page, edge PoP or data center responses can be produced for Istanbul, Ankara or other cities. This is useful for local campaigns, city-level compliance or low-latency traffic distribution goals. City information is evaluated using the offline GeoIP database.

CIDR-based network rules separate private networks and customer segments

Network/CIDR granularity allows custom DNS responses to be defined for specific IPv4 or IPv6 network blocks. Enterprise customer subnets, partner networks, private carrier ranges or internal access blocks can be separated this way. CIDR-level routing is more deterministic than country or city. It is powerful for per-customer endpoints or peering DC selection.

ASN-based routing refines carrier and peering decisions

ASN granularity selects a DNS response based on the carrier or network owner the client is connected to. Separate DC records can be returned for specific telecom carriers, ISP networks or CDN peering preferences. This approach creates value where different carriers within the same country have different network quality. Traffic is routed according to real network topology rather than a national boundary.

The negate flag enables exclusion-based geographic rules

Negate behavior can be applied to any topology rule. This allows inverse rules such as "every country except this one", "every ASN except this one" or "every network except this CIDR". Exclusion logic is useful for enforcement, access separation, alternative IP delivery or high-risk region exclusion scenarios. Operators can build both matching and exclusion policies.

Fallback records produce a controlled response when no match is found

If the geographic topology rule produces no record candidates, fallbackRecords can be activated. These records can represent a default DC, maintenance service or global endpoint. Fallback behavior ensures a controlled last-resort response instead of an empty or unexpected DNS reply. This is especially important for new regions or missing GeoIP matches.

Per-record geo policy establishes different behavior within the same domain

TR7 can define independent topology policies for each record. Under the same domain, A records, AAAA records or different service records can operate with different geographic decisions. This allows different routing strategies to be applied to different application components under a single domain. Operators manage topology behavior at the record level rather than globally.

Selector options distribute across matching record candidates

A geographic match can produce multiple record candidates. TR7 can then select among those candidates using selector behaviors such as all, closest, round-robin, weighted round-robin, random or weighted random. Geographic filtering and load distribution are thus combined in the same chain. For example, weighted selection can be applied between two DCs within the same country.

Offline GeoLite2 databases reduce data residency risk

ASN, City and Country databases are stored on-device and geographic decisions are made locally. DNS query context is never sent to an external GeoIP API. This is an important advantage for organizations with query privacy and data residency expectations. Update flow should be planned separately; page behavior relies on the offline decision model.

TTL awareness is planned together with geo cache behavior

The TTL value for each DNS record affects geographic routing behavior. Shorter TTL offers advantages for fast policy changes and failover; longer TTL reduces resolver cache load. When designing geo routing, TTL, DC health and traffic distribution goals should be planned together. The operator sets the balance between performance and the speed of change.

Operational depth

Geographic DNS routing is operated alongside topology rule types, normalized fields, CIDR rendering behavior, fallback logic and Lua execution limits.

01

Topology rule types

The topology decision pipeline uses network, country, city, continent and ASN rule types. Each rule type can be evaluated with positive or negate behavior. This structure allows multiple geographic decision dimensions to be combined within the same record.

02

Country and continent normalization

Country and continent codes are lowercased before comparison. This prevents case differences from different sources from breaking matches. Normalized values make policy authoring more consistent.

03

CIDR rendering behavior

Network rules evaluate IP and CIDR together. If no CIDR is specified, per-IP precision behavior can be used for IPv4. This model allows both private network blocks and single IP targets to be handled within the same policy structure.

04

GeoIP database coverage

TR7 can make geographic decisions using ASN, City and Country databases. These three data sources form the foundation for ASN, city, country and continent decisions. Because the databases reside on-device, runtime decisions do not depend on an external service.

05

No-match behavior

If the topology evaluation produces no record candidates, fallbackRecords is checked. If a fallback exists, a final response can be produced with failSafe status. If no fallback is defined, an empty or standard DNS behavior may occur — a fallback plan is therefore recommended for all production records.

06

Lua execution limits

Topology selection runs through a Lua-based decision pipeline. Execution limits and health check intervals help keep DNS decisions deterministic and controlled. Performance impact should be considered for very complex rule sets.

When to use it

Carrier-based routing with ASN separation within Turkey

Different peering DC records can be returned for different carrier networks in Turkey. The ASN topology rule helps direct users within the same country to a more accurate network path.

Country-based DC selection for European financial services

Different compliance or data residency targets can be defined for countries such as Germany, France or Italy. The country rule returns the appropriate DC record based on the client's country.

Continent-based PoP routing for global distribution

Global services can direct clients to the most appropriate PoP or data center group at the continent level. Continent rules and selector behavior can be combined for regional load distribution.

Geographic exclusion for alternative response delivery

With negate flag, different records can be returned to clients outside specific countries, ASNs or CIDRs. This model is useful for enforcement, licensing, compliance or high-risk region separation.

City-based campaign and landing page routing

A custom landing page IP can be returned to users from cities such as Istanbul or Ankara. The city rule provides precise DNS-level routing for marketing and local service delivery scenarios.

Frequently asked questions

How does EDNS Client Subnet work and why does it matter?
In classic DNS, the decision is based on the IP address of the forwarding resolver. When EDNS Client Subnet (RFC 7871) is active, the resolver appends the real client subnet to the request. TR7 uses this information to make the decision based on the user's actual network location rather than the resolver's position. This reduces the risk of users relying on public resolvers being sent to the wrong DC.
Which geographic dimensions can topology rules be defined for?
TR7 supports topology rules across five dimensions: network/CIDR, country, city, continent and ASN. Each rule can operate with positive or negate behavior. Multiple dimensions can be combined within the same record — for example, all Turkey traffic except a specific ASN can be placed under the same rule.
Does the GeoIP decision depend on an external service?
No. TR7 holds ASN, City and Country databases offline on-device. Geographic decisions are made using these local databases; DNS query context is never sent to an external GeoIP API. This approach both meets data residency requirements and eliminates external dependency.
When and how do fallback records activate?
If the topology evaluation produces no record candidates, fallbackRecords activates and a response is produced with failSafe status. If no fallback is defined, empty or standard DNS behavior may result. Defining a fallback for all records in production environments is recommended — this is especially critical for new regions or missing GeoIP matches.
How do selector behaviors work together with geographic routing?
A geographic match can return multiple record candidates. The selector determines how to choose among them: all returns all candidates, closest picks the nearest, round-robin and weighted round-robin provide cyclic distribution, and random and weighted random apply stochastic selection. Geographic filtering and load distribution are thus combined in the same pipeline.
In which scenarios is the negate flag used?
The negate flag is used to define the inverse of a geographic condition as a rule. For example, "send this IP to all users except this country" or "use this DC for all clients except this ASN" are written with negate. It creates value in enforcement, license restriction, high-risk region exclusion or alternative record scenarios.

Bind DNS decisions to the user's real location

Geographic DNS routing with EDNS Client Subnet, five-dimensional topology rules and offline GeoIP. Let's walk through a live setup on your own infrastructure.