Dyn’s Traffic Director allows customers to define many different rulesets and response pools based on geographic location. When a DNS query is received, the source IP address is analyzed against our geolocation data, the appropriate ruleset is matched, and the ruleset’s assigned response pool is used to provide a response.
The source IP address that is provided to Traffic Director in a DNS query is the IP address of the recursive DNS server, not the end-user’s IP address. This recursive DNS server is often, but not always, operated by the Internet Service Provider (ISP) of the end-user.
It can be the case where the end-user is located in a different geographic area compared to the recursive DNS server. This is most common when an end-user uses an open recursive DNS server, such as Google Public DNS or OpenDNS, as an alternative to the ISP’s recursive DNS server. While popular open recursive DNS servers often operate large anycast networks, there is still a fairly large chance that end-users are in different geographic locations compared to the recursive server. This could result in some significant geolocation differences and could result in sub-optimal routing by Traffic Director in some cases.
For example, Google Public DNS at this time does not have a POP in India, which means all end-users in India using Google Public DNS are routed to the closest Google POP to their location, most likely Singapore. From Traffic Director’s perspective, these end-users will appear as if they come from Singapore, not India, since a DNS query only provides the source IPs of Google’s recursive servers in Singapore, not the end-user’s IP address.