How to do regional DNS like a CDN does?

The trouble with CDNs is that they don't direct you based on your own IP address - they direct you based on the IP address of your DNS server... That could be completely wrong. And do read Paul Vixie's ACM article, it's bang on the money.

Anyhow, if you've already got region.example.com set up and running, you could consider doing an HTTP redirect from example.com to the relevant webserver, based on the client's IP address.

That's pretty much what Google does, it's how I end up at google.co.uk having typed in google.com.

Do also ensure though that you provide a means for clients to get to the other variations. Clients don't like it when they're forced to a particular site, whether by mistakes in the Geo databases or simply because they actually need to see the site from another region.

Newer CDNs (Cloudflare, MaxCDN, fast.ly) use anycast for both DNS and actual content servers. This is somewhat better than trying to use the source IP of a DNS query and an ever changing mapping database.

In theory using anycast for both the DNS and content servers allows the network itself to find the "closest" servers to the client. In practice, this is mostly true, but some weird cases arise where people in Singapore will hit edge servers in California instead of Hong Kong due to the ever-changing peering relationships between ISPs.

Anycast is difficult to do well.

Older CDN like Akamai and Limelight generally use anycast to get you to the closest DNS server, but then take the guess-based-on-source-IP approach. This doesn't work as well in my experience, especially if a client is using DNS severs that aren't actually nearby in terms of network topology. However, a huge established CDN like Akamai has hundreds of content server locations, so returning a "close enough" answer results in a decent user experience. Obviously, having hundreds of sites is very expensive, which is why none of the all-anycast CDNs chose that route. Consequently, They also don't charge as much for mostly-equivalent service.

There are a number of ways to handle this, but they all boil down to figuring out where an IP address is, and pointing it accordingly. For example, you might specify a range of IPs for North America and one for Europe. If the IP requesting the information (from DNS, your webserver, your content server, etc.) falls in the European range, then your European servers should get the requests.

You could setup a default main page at example.com. The first time someone visits they select which region they want to be directed to. This is the same way that www.ups.com works.

The user can select a check box to make this his/her default choice from that point on, thus storing the selection in a cookie.

This gives you to benefit of using DNS in the manner it was designed for according to Paul Vixie, while allowing your user to make the most accurate decsion on which data center they should be directed to.

If you have a website that's hosted in multiple regions then you don't need to do anything at the DNS level. You can use an API such as http://ipinfo.io to get the visitor's country, and then redirect them to the appropriate URL.

If we're not talking about a website, or any protocol that handles redirects, then there are a few options at the DNS level. You could do the same IP country lookup and then return a record that matches the region (geolocation based DNS), or you could have a map of the latency between different networks, and return a record that represents the lowest latency for the user (latency based DNS). Amazon's Route53 DNS service offer both.