This configuration example covers global server load balancing of multiple distributed servers using the edgedirector geobalancing dns service.
To avoid publishing details that might apply to servers belonging to other parties, the domain name used in the example will be example.com and the addresses used will be private ip ranges. This practice is in accordance with the recommendations of the IETF as published in various RFC's.
example.com wants to ensure visitors from around the globe are served by the closest server. Multiple servers are in place at geographically distributed data centres. The site is published as example.com and www.example.com
1. Create one example.com address record for each distributed server ip address.
2. Create one alias record for www.example.com pointed at example.com with a matching ttl. The www.example.com alias record will follow the example.com target automatically.
3. Set the geo coverage for each server according to physical location. Leave the global coverage enabled for all servers.
4. Create administrative access records for each of the servers. These records are used by administrators to access the correct server unambigously by name.
5. Publish dns records using the red link at the top of the dns management page. The records will be available in the next two minutes.
The backend system generates multiple records matching the geodns parameters set by the dns administrator. These records are pushed to the public facing dns servers.
When queries arrive, the address record most closely matching the geographical location of the query source is selected as the answer record. Matches are made from smallest to largest qualifying records. The visitor will in turn receive the dns answer and initiate a connection to the server determined to be closest according to these rules.
When queries arrive for the www.example.com alias, an address record is also returned in the answer packet. The address record is selected using the same rules as a direct query for an address record.
It is important to understand that dns queries will generally originate from the dns cache servers operated by the visitor's internet service provider. Some cache servers are geopraphically distant from the visitor, or, their ip addresses do not bear a direct relationship with their geographical location. This limitation is unavoidable, so users must recognise and allow for some leakage.