When it comes to Content Delivery Networks (CDNs), there is something that has always puzzled me;
How do CDNs work with Anycast based DNS servers?
Background
For example, the way in which CDNs function is to serve content from nodes closest to the client. CDNs determine the closest node to the client via the IP address of the client's DNS server which is provided at the point the client issues a DNS request for the resource.
However, this model presents an issue. When the clients DNS server is using Anycast, such as Google's DNS service (8.8.8.8), the DNS server's IP address is the same, regardless of where it is in the world.
The Answer
After some quick Googling, I found a somewhat satisfying answer in the form of RFC7871 aka the edns-client-subnet EDNS0 option.
EDNS-Client-Subnet (ECS) uses the DNS extension - EDNS0 - that allows recursive DNS services to provide the client (end-user) subnet as part of the DNS query. This allows authoritative DNS providers (such as CDN providers) to use this extra information to make more informed traffic routing decisions.
In other words, ECS can be viewed as the DNS version of the HTTP X-Forwarded-For header.
Testing
Let's see it in action…
First, we test using an IP address from Singapore. Let's check the IP's location, like so:
$ curl -s http://ip-api.com/json/219.75.27.16 | jq
{
"as": "AS9506 Singtel Fibre Broadband",
"city": "Singapore",
"country": "Singapore",
"countryCode": "SG",
"isp": "Singtel ADSL",
"lat": 1.2931,
"lon": 103.8558,
"org": "Singtel Fibre Broadband",
"query": "219.75.27.16",
"region": "01",
"regionName": "Central Singapore Community Development Council",
"status": "success",
"timezone": "Asia/Singapore",
"zip": ""
}
Next, we will send the ECS to Google's Authoritative server:
$ dig +norecurse +subnet=219.75.27.16 www.google.com @ns3.google.com +short
172.217.194.105
172.217.194.104
172.217.194.147
172.217.194.99
172.217.194.103
172.217.194.106
Now let us check the location of the IPs provided:
$ curl -s http://ip-api.com/json/172.217.194.106 | jq
{
"as": "AS15169 Google LLC",
"city": "Singapore (Queenstown Estate)",
"country": "Singapore",
"countryCode": "SG",
"isp": "Google",
"lat": 1.27623,
"lon": 103.8,
"org": "Google",
"query": "172.217.194.106",
"region": "",
"regionName": "Central Singapore",
"status": "success",
"timezone": "Asia/Singapore",
"zip": ""
}
Great, now let's try another IP, but from Germany:
$ curl -s http://ip-api.com/json/85.214.132.117 | jq
{
"as": "AS6724 Strato AG",
"city": "Berlin",
"country": "Germany",
"countryCode": "DE",
"isp": "Strato AG",
"lat": 52.5167,
"lon": 13.4,
"org": "Strato AG",
"query": "85.214.132.117",
"region": "BE",
"regionName": "Land Berlin",
"status": "success",
"timezone": "Europe/Berlin",
"zip": "12529"
}
$ dig +norecurse +subnet=85.214.132.117 www.google.com @ns3.google.com +short
172.217.20.68
$ curl -s http://ip-api.com/json/172.217.20.68 | jq
{
"as": "AS15169 Google LLC",
"city": "Amsterdam",
"country": "Netherlands",
"countryCode": "NL",
"isp": "Google",
"lat": 52.3702,
"lon": 4.89517,
"org": "Google",
"query": "172.217.20.68",
"region": "NH",
"regionName": "North Holland",
"status": "success",
"timezone": "Europe/Amsterdam",
"zip": "1012"
}