Geo-closest routing
Geo-closest routing returns the records that are closest to the client.
DNScaster’s Geo-closest support is designed to be super easy to configure. There is no need to group regions according to what servers should be seen. Instead, simply identify the location of the servers themselves and DNScaster will handle the rest.
; Configured records:
your-domain.com GEO 1 _geo.your-domain.com
www.your-domain.com GEO 1 _geo.your-domain.com
gb._geo.your-domain.com 300 A 203.0.113.1 ; server located in Great Britain
ca.us._geo.your-domain.com 300 A 192.0.2.2 ; server located in California
ny.us._geo.your-domain.com 300 A 198.51.100.3 ; server located in New York
GEO record
Start by creating a GEO record for the name(s) that should be resolved. In this case it’s your-domain.com and www.your-domain.com. As you can see, it’s possible to point multiple names to a single Geo-closest configuration set.
The GEO record’s data field is two parts: the number of matches to return and the base subdomain to look for the rest of the records.
Valid values for number of matches are 1-3. In this case, the number of matches is 1, meaning that the closest single result (from gb, ca.us, and ny.us) will be returned. If it was 2, then the closest 2 would be returned. 3 would simply return all 3 results, which wouldn’t make sense here, but would might be a great fit if you had numerous endpoints.
The second part, _geo.your-domain.com here, tells DNScaster where to look for the location-named records. You can change the _geo prefix to something else, but it may be easier to follow our docs if you use _geo.
The rest of the base domain must be the same domain that you’re configuring. You cannot point a GEO record to another domain. Sharing a GEO config with another domain is possible though: create an ALIAS on that domain pointing to the GEO record itself, like so:
other-domain.com 300 ALIAS www.your-domain.com
www.other-domain.com 300 ALIAS www.your-domain.com
Location records
The next step is to create location records. Location records may be A, AAAA, or ALIAS types.
Location records are named according to this pattern: {loc}.{base-domain-from-GEO-data}, where Location is either the 2-letter ISO code of the country in which the server is located, or in the case of the USA and Canada, the 2-letter state/province, a ., and then us or ca.
As mentioned above, there is no need to be concerned with where users are coming from. The goal of Geo-closest is to connect users to a nearby server. If you need to guide traffic to inside or outside certain political boundaries, use Geo boundaries instead.
Hint: As a general rule, we recommend using either A + AAAA or ALIAS. That is, don’t mix ALIAS with the other two. This helps ensure the “closest 1-3” calculations are optimal.
As always, if you have any questions about your particular use case, please don’t hesitate to contact us!
Technical details & Combinations
The TTL on the GEO record itself will be ignored. TTLs from individual location records will be used instead.
Geo-closest is processed after boundaries, making it possible to include or exclude certain hosts from the potential GEO result set. Get in touch if you’d like assistance in configuring this combo.
The “closest” determination only includes online hosts. If the closest server is offline, users will be directed to the next closest (strictly speaking, next 1-3 closest, as configured).
If a location record is an ALIAS and the ALIAS maps to 2 or more A or AAAA records, all mapped IPs will be included. If the target ALIAS is known to return multiple IPs (such as some load balancers), choosing “closest 1” would still return the entire load balancer IP set, which is usually what’s wanted. Likewise, “closest 3” would return all IPs for 3 full ALIAS sets which could potentially be a lot of IPs!