GeoDNS

GeoDNS answers different IPs to visitors in different regions, so users reach the server nearest to them. It isn't a separate tab: it's the Region field on every A and AAAA record, in the zone's Records tab.

Note

The region selector only appears on Pro and Business zones. On a Free zone every record is global.

The regions

How it behaves

The mechanism that makes this safe is that the same name in a different region is a separate record. You aren't editing one record's answer per region; you're publishing several records under one name, each tagged with the audience it's for.

Publish one global record as the catch-all, then add regional records that override it nearby:

www  A  185.230.55.10   region = global     (fallback, everyone)
www  A  10.0.1.5        region = eu-west    (served in/near Amsterdam)
www  A  10.0.2.5        region = us-east    (served in/near Virginia, Miami)

A visitor in Madrid gets the eu-west answer, one in Texas gets us-east, and anyone with no regional match gets the global one. In the records list, a non-global record carries its region as a badge next to the value, so you can see the split at a glance.

Warning

Always keep at least one global record per name. Without it, a visitor whose resolver doesn't match any region gets no answer at all — not a slow answer, no answer.

What "the visitor's region" really means

We match on the resolver's location, not the visitor's. For the large majority of users those are the same place: their ISP's resolver sits near them. They diverge when someone uses a distant public resolver, a corporate resolver in another country, or a VPN. Those users get the answer for wherever their resolver is, which is the correct behaviour — that's where their traffic is actually coming from — but it's why a specific user can report "the wrong server" while the routing is working exactly as designed.

Using it well

• Start global, then add. Get one working global record first, then layer regions on top. That way the fallback is never missing.
• Pair it with a low TTL only if the targets move. Region routing itself doesn't need a low TTL; failover does. See Health checks.
• Put a real server in every region you publish. A regional record pointing at a machine on the other side of the world is slower than no regional record at all.
• Region and health check stack. One checked record per region plus a global fallback gives you nearest-server routing, automatic removal of dead servers, and an answer for everyone else.

Troubleshooting

Tip

GeoDNS distributes visitors between locations. It does not balance requests across servers inside one location, and it doesn't know anything about load. For that, put a Load Balancer behind the regional address.