CDN: How is it possible that my DNS delivers a different IP depending on the visitors location?
Ok it seems I can now give a rough answer to my own question. Anurag Bhatia says that there exist two methods how a CDN works:
DNS
Have DNS to do the magic i.e when users from network ISP A lookup for cdn.website.com, they should get a unicast IP address of Cache A in return, similarly for users coming from ISP B network, Cache B’s unicast IP should return.
Lets say we have a server with the IP 1.2.3.4 located in USA and a cache-server with the IP 2.3.4.5 located in Germany. Now a visitor tries to resolve the domain example.org. If he did not change his network settings he uses the DNS server of his internet service provider (ISP). And this ISP asks now dns1.example.com (the nameserver of the domain) for the IP. Now it depends on the location of the ISP. If its located in Germany the dns1.example.com returns 2.3.4.5 and if its located in the USA it returns 1.2.3.4.
But there might be a disadvantage with this method: Every time a user changed his network settings and uses an EDNS0 (see IETF draft) incompatible DNS provider (for example a corporate's central DNS server) the dns1.example.com will answer again with the nearest IP to those DNS locations, but this time the visitor is most likely in a different location causing a higher latency.
EDNS0 compatible DNS providers are passing information about the user to the authoritative DNS server. So the authoritative DNS server can respond with the IP next to the location of the user:
Today, if you’re using OpenDNS or Google Public DNS and visiting a website or using a service provided by one of the participating networks or CDNs in the Global Internet Speedup then a truncated version of your IP address will be added into the DNS request. The Internet service or CDN will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server.
...
; EDNS: version: 0, flags:; udp: 512 ; CLIENT-SUBNET: 130.89.89.0/24/21
Anycast
Have routing to route to nearest cache node based on “anycast routing” concept. Here Cache A, Cache B and Cache C will use same identical IP address and routing will take care of reaching the closest one.
I don't really understand Anycast because of BGP, etc., but I think the further explanation of Anurag Bhatia gives an idea how it could work:
- Optimization is based on BGP routing and announcement with little role of DNS.
- This setup is very hard to build up and scale since for anycast to work perfectly at global level, one needs lot’s and lot’s of peering and consistent transit providers at each location. If any of peers leaks a route to upstream or other peers, there can be lot of unexpected traffic on a given cluster due to break of anycast.
- This setup has no dependency on DNS recursor and hence Google DNS or OpenDNS works just fine.
- This saves a significant amount of IP addresses since same pools are used at multiple locations.
Anycast has also a disadvantage: Routing is flexible. While at the start of a TCP session the target node might be located in network A it may change to network B. Therefore Anycast will be used in practice for UDP only. UDP is a session-less protocol.
Most CDN are using DNS for HTTP/HTTPS traffic and Anycast for DNS requests.