How is latency-based routing different from GeoDNS?

GeoDNS maps location to answer. Latency-based routing maps observed or estimated performance to answer. Geography is often an input, but the best endpoint is not always the geographically closest one because peering, congestion, and resolver placement matter.

Can DNS really route every user to the lowest-latency endpoint?

Not perfectly. DNS sees recursive resolvers, not always end users, and answers are cached for the TTL. Latency-based DNS is an approximation that works best for large resolver populations and regional services, not per-request millisecond optimization.

What measurements matter?

Health first, then latency, packet loss, error rate, and capacity. A low-latency endpoint that is returning 500s or saturating should not receive traffic. DNS steering must include health and load thresholds, not just ping time.

What causes DNS route flapping?

Flapping happens when small measurement changes constantly change the preferred endpoint. Prevent it with hysteresis, minimum switch intervals, weighted transitions, and clear thresholds before changing answers.

Should APIs use latency-based DNS routing?

Only if the API is multi-region active-active or has safe failover semantics. Stateful APIs, write-heavy systems, and region-pinned data often need application-layer routing or explicit regional hostnames instead of automatic DNS steering.

Latency-Based DNS Routing - Measurement-Driven Traffic Steering

Learn how latency-based DNS routing chooses endpoints using health checks, regional probes, resolver measurements, and TTL-aware failover.

Updated 5 May 2026

TL;DR

Latency-based DNS routing returns the endpoint expected to be fastest for the querying resolver or client region. Unlike simple GeoDNS, it should use measurements: probe latency, packet loss, health, and sometimes resolver-specific telemetry. The hard parts are stale caches, resolver centralization, health-check accuracy, and avoiding route flapping. Use it when you have multiple active regions and real latency differences; keep deterministic fallbacks for outages.

What you'll learn

Understand latency-based DNS routing and how it differs from GeoDNS
Identify the measurements needed for safe routing decisions
Avoid flapping, cache-staleness, and resolver-location mistakes
Choose when DNS-layer latency routing is better than application routing

Latency-based DNS routing returns the endpoint expected to respond fastest for a user population. It is a step beyond GeoDNS: geography may be an input, but the decision should be based on measured performance and health.

The goal is simple: if api-eu.example.com is faster for one resolver and api-us.example.com is faster for another, return the better endpoint for each query.

The implementation is not simple, because DNS is cached and recursive resolvers hide individual users.

What DNS Can See

Authoritative DNS usually sees:

Recursive resolver IP
Query name and type
EDNS Client Subnet if the resolver sends it
Source ASN and rough location
Historical latency/health telemetry if measured externally

It usually does not see:

The individual client IP
The user's browser RTT to your application
Per-request application state
Whether the client has a stale cached answer

That means latency-based DNS routing is population-level steering, not per-request load balancing.

Inputs for Good Routing

Good latency routing combines:

Input	Why it matters
Endpoint health	Never route to a dead endpoint.
Probe latency	Baseline network performance from many regions.
Packet loss	High loss makes low average latency misleading.
HTTP/TCP success	DNS-level reachability is not enough for web/API endpoints.
Resolver/ASN history	Some resolvers consistently perform better to non-obvious regions.
Capacity	Fast but saturated endpoints should receive less traffic.

Health should win over latency. A slow healthy endpoint is better than a fast dead one.

Routing Example

You operate three regions:

api-eu.example.com
api-us.example.com
api-apac.example.com

Policy:

Resolver population	Primary	Fallback
EU resolvers	EU	US
US resolvers	US	EU
APAC resolvers	APAC	US
Unknown	Global weighted pool	US

If APAC latency spikes or health checks fail, APAC resolvers receive the fallback answer until the region is stable again.

TTL and Cache Reality

DNS answers are cached. If a resolver receives api-apac.example.com with a TTL of 300 seconds, it can keep returning that answer for five minutes. Some clients also cache separately.

Practical TTLs:

60 seconds for active incident-sensitive routing
300 seconds for most latency steering
900 seconds when endpoints are stable and query volume matters

Do not rely on TTL alone for instant failover. Critical clients should retry alternate endpoints at the application layer too.

Avoiding Flapping

Measurement noise can cause constant answer changes. Prevent this with:

Minimum health duration before adding an endpoint back
Minimum outage duration before removing an endpoint
Hysteresis, such as requiring a 20 percent latency improvement before switching
Weighted transitions instead of instant 100 percent shifts
Manual override during incidents

Routing stability is part of performance. A system that changes every minute is hard to debug.

DNS vs Application Routing

Use DNS-layer latency routing when:

Endpoints are regionally independent
Data can be served safely from multiple regions
Failover semantics are clear
Cache delay is acceptable
You want resolver-population steering

Use application-layer routing when:

Users have sessions tied to a region
Writes must stay near a primary database
Compliance requires explicit region selection
Per-request latency matters
Clients can follow redirects or use service discovery

Many mature systems use both: DNS chooses a regional entry point, and the application handles final routing.

Relationship to Anycast

Anycast routes the DNS query to a nearby authoritative nameserver. Latency-based DNS routing decides which application endpoint to return.

DNScale's Global DNS Resolution Balancing makes the DNS lookup itself fast and resilient. Your application-level latency strategy decides whether the answer should point to EU, US, APAC, or another service endpoint.

Frequently asked questions

How is latency-based routing different from GeoDNS?: GeoDNS maps location to answer. Latency-based routing maps observed or estimated performance to answer. Geography is often an input, but the best endpoint is not always the geographically closest one because peering, congestion, and resolver placement matter.
Can DNS really route every user to the lowest-latency endpoint?: Not perfectly. DNS sees recursive resolvers, not always end users, and answers are cached for the TTL. Latency-based DNS is an approximation that works best for large resolver populations and regional services, not per-request millisecond optimization.
What measurements matter?: Health first, then latency, packet loss, error rate, and capacity. A low-latency endpoint that is returning 500s or saturating should not receive traffic. DNS steering must include health and load thresholds, not just ping time.
What causes DNS route flapping?: Flapping happens when small measurement changes constantly change the preferred endpoint. Prevent it with hysteresis, minimum switch intervals, weighted transitions, and clear thresholds before changing answers.
Should APIs use latency-based DNS routing?: Only if the API is multi-region active-active or has safe failover semantics. Stateful APIs, write-heavy systems, and region-pinned data often need application-layer routing or explicit regional hostnames instead of automatic DNS steering.

Ready to manage your DNS with confidence?

DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

Start free