Skip to content

CONCEPT Cited by 1 source

Latency-based DNS routing

Definition

Latency-based DNS routing is a DNS resolution policy in which a single hostname resolves to different IP addresses depending on the measured network latency from the resolver's location to each candidate endpoint. The resolver returns the address of the POP with the lowest measured latency to the client's network, giving callers the "CDN effect" without BGP anycast.

AWS Route 53's latency routing policy is the canonical implementation: operators publish one DNS record per region; Route 53 keeps a rolling internal latency table (measured from monitoring probes around the Internet to each AWS region endpoint), and at resolution time it picks the record whose region has the lowest latency from the resolver's source. GCP and Azure offer equivalent primitives.

Canonical reference from PlanetScale's 2024-04-17 launch post: "The Optimized endpoint is backed by a latency-based DNS resolver. In AWS, for example, this is their Route53 latency-based routing policy. Which is most of the magic to resolve aws.connect.psdb.cloud to the nearest edge region to you. This means whether you're connecting from your local machine with pscale connect or from the datacenter next to your database, you get routed through the closest region to you, which gives us the CDN effect." (Source: sources/2026-04-21-planetscale-introducing-global-replica-credentials.)

How it compares to anycast

Both latency-DNS and anycast solve the same problem — "send the client to the nearest POP" — but operate at different OSI layers.

Axis Latency-based DNS BGP Anycast
Layer DNS (application) BGP (network)
Decision made by DNS resolver Internet routing fabric
Granularity Per DNS query (TTL-bounded) Per packet
Measurement source Cloud provider's internal probe mesh BGP best-path (usually hop-count / AS-path)
Supported protocols Any (client resolves hostname) Any (IP-layer)
Failover on POP loss TTL-bounded; update DNS records BGP withdraw; seconds
Requires BGP / IP announcement No Yes
Caller sees different IP per POP Yes No (same IP everywhere)
Session stickiness Natural (DNS TTL pins resolver → IP for TTL) Disrupted by BGP path changes

Latency-DNS is the easier primitive to adopt for an operator without their own anycast prefix or peering relationships — the cloud provider handles the measurement and routing table. Anycast is the lower-latency + faster-failover answer when you own the network layer.

Structural caveats

  • Resolver-location-based, not client-location-based. The decision is made at the client's DNS resolver, not the client itself. A client in Tokyo using Google's 8.8.8.8 anycast resolver may be routed based on which Google resolver POP actually handles the query — often but not always matches the client's region.
  • TTL determines failover speed. If a POP goes down, the DNS record must be updated and the old TTL must expire before clients re-resolve; typical TTLs of 30–60s mean failover delays on that order.
  • Latency tables are statistical. Cloud providers measure from probe meshes, not from individual clients. A client on an unusual path may not get truly-lowest-latency routing.
  • Only works for initial connection. Once the client resolves and connects, it sticks with that IP until the connection closes or it re-resolves; per-query "next hop" routing (e.g. PlanetScale's latency-sorted cluster list) requires additional routing decisions inside the network fabric at the edge POP, which latency-DNS alone can't provide.

Seen in

Last updated · 378 distilled / 1,213 read