4 ms·

Correct. Using a DNS service like Google's can reduce throughput from location-aware CDNs, since you end up reading off of a CDN edge very far away from you.

by cheald 16y ago

fleitz 16y ago
Incorrect, the CDN is not location aware if it's using DNS. It's making a bunch of unnecessary assumptions about a DNS server's network proximity to the clients it serves. The root servers themselves run on Anycast so that you can get a 'root server' closest to your network location. A much better way of locating a resource on the network is its IP address, since this is what IP was designed to do and not what DNS is designed to do (resolve names to IP addresses) DNS is designed to be forwarded and cached. A much better way of optimizing network routes is to advertise a better route, since this is what routing was designed to do. (To pick the fastest way to get from your IP to a destination block. (aka. anycast.)) It's simply amazing how well things work when you use things for what they were intended for. Why reinvent the wheel at such a high level?
- foobarbazetc 16y ago
  The point is that you don't know the IP address of the client, so you can't locate it. Most CDNs couple DNS (for a large region) and Anycast (within the region) -- they're not idiots.
  - fleitz 16y ago
    How does the CDN send data back to the client with out knowing its IP address? I'd like to know.
    - foobarbazetc 16y ago
      The point is that by the time you've heard from the client on the CDN (after resolving host to IP), they've already contacted a non-optimal CDN POP. Providing IP addresses (locations) to host queries is exactly what DNS is built to do. :)
    - evgen 16y ago
      You don't know the ip address of the real client when they are doing the dns lookup, so you start by assuming that they are close (in network terms) to the server that is performing the dns lookup. When you are not dealing with a borked dns service this assumption you will get into the right general region of the world. Once you are in the right region you can use anycast because within a relatively small region you are less likely to see big route shifts that will pop an anycast connection and hose your content delivery.
- evgen 16y ago
  Yes, it is location aware even if it is using DNS. The DNS lookup is the first chance you have to direct a user to the right data center. You examine the source of the dns lookup and figure out the best bgp path from each data center that will get you back to the source. You then respond with an answer to the dns request that directs the user to what you think is the closest data center. You may be wrong if the user is using a useless dns cache like google dns or if they are using a big ISP that keeps its dns in one location (10 or so years ago Comcast did all dns out of its east-coast data center, people learned real fast to not try to do geodns on queries coming from these servers...) OTOH, if the user is using their ISP's "local" dns server then you are going to get a result that will be very, very close to optimal. If you guessed incorrectly then the tcp handshake will start from the user to your server and you will know that they are not at the right server. If the nature of the eventual exchange allows it (e.g. it will be repeated queries or a long data exchange) then you just hit them with a redirect and let the user re-open the connection to a server that is closer to them, or you seed the response data so that follow-up queries are all exchanged with the closest data center. If the exchange is quick and not going to be repeated a lot then you will end up adding more perceived latency by trying to re-direct once the connection is established. Putting this sort of smarts down at the application server is expensive. It is much easier to do this job at the dns lookup phase and you will get a good return on the amount of investment that this approach requires. You do need to be smart though, and make sure that you do not let geodns end up directing large batches of users that are getting service from google dns or opendns to overload a particular location. Anycast is not the solution, it is just a different approach that brings its own set of headaches into the equation (e.g. pop switches during extended exchanges)
- cheald 16y ago
  GeoDNS allows you to return different zone files depending on the location of the source query. If you are in New York, query for foo.cdnbar.com, and the nameserver serving that CDN is geo-aware, you might get a northeast-based IP. Google then caches that. 5 minutes later, I, in Arizona, come along and ask for foo.cdnbar.com, and it just gives me your northeast-based IP, meaning I have an extra four hops and 3000 miles for my packets to travel than if I'd pulled that IP off of my ISP's DNS.

Correct. Using a DNS service like Google's can reduce throughput from location-aware CDNs, since you end up reading off of a CDN edge very far away from you.

by cheald 16y ago

Correct. Using a DNS service like Google's can reduce throughput from location-aware CDNs, since you end up reading off of a CDN edge very far away from you.

fleitz 16y ago

Incorrect, the CDN is not location aware if it's using DNS. It's making a bunch of unnecessary assumptions about a DNS server's network proximity to the clients it serves. The root servers themselves run on Anycast so that you can get a 'root server' closest to your network location. A much better way of locating a resource on the network is its IP address, since this is what IP was designed to do and not what DNS is designed to do (resolve names to IP addresses) DNS is designed to be forwarded and cached. A much better way of optimizing network routes is to advertise a better route, since this is what routing was designed to do. (To pick the fastest way to get from your IP to a destination block. (aka. anycast.)) It's simply amazing how well things work when you use things for what they were intended for. Why reinvent the wheel at such a high level?

foobarbazetc 16y ago
The point is that you don't know the IP address of the client, so you can't locate it. Most CDNs couple DNS (for a large region) and Anycast (within the region) -- they're not idiots.
- fleitz 16y ago
  How does the CDN send data back to the client with out knowing its IP address? I'd like to know.
  - foobarbazetc 16y ago
    The point is that by the time you've heard from the client on the CDN (after resolving host to IP), they've already contacted a non-optimal CDN POP. Providing IP addresses (locations) to host queries is exactly what DNS is built to do. :)
  - evgen 16y ago
    You don't know the ip address of the real client when they are doing the dns lookup, so you start by assuming that they are close (in network terms) to the server that is performing the dns lookup. When you are not dealing with a borked dns service this assumption you will get into the right general region of the world. Once you are in the right region you can use anycast because within a relatively small region you are less likely to see big route shifts that will pop an anycast connection and hose your content delivery.
evgen 16y ago
Yes, it is location aware even if it is using DNS. The DNS lookup is the first chance you have to direct a user to the right data center. You examine the source of the dns lookup and figure out the best bgp path from each data center that will get you back to the source. You then respond with an answer to the dns request that directs the user to what you think is the closest data center. You may be wrong if the user is using a useless dns cache like google dns or if they are using a big ISP that keeps its dns in one location (10 or so years ago Comcast did all dns out of its east-coast data center, people learned real fast to not try to do geodns on queries coming from these servers...) OTOH, if the user is using their ISP's "local" dns server then you are going to get a result that will be very, very close to optimal. If you guessed incorrectly then the tcp handshake will start from the user to your server and you will know that they are not at the right server. If the nature of the eventual exchange allows it (e.g. it will be repeated queries or a long data exchange) then you just hit them with a redirect and let the user re-open the connection to a server that is closer to them, or you seed the response data so that follow-up queries are all exchanged with the closest data center. If the exchange is quick and not going to be repeated a lot then you will end up adding more perceived latency by trying to re-direct once the connection is established. Putting this sort of smarts down at the application server is expensive. It is much easier to do this job at the dns lookup phase and you will get a good return on the amount of investment that this approach requires. You do need to be smart though, and make sure that you do not let geodns end up directing large batches of users that are getting service from google dns or opendns to overload a particular location. Anycast is not the solution, it is just a different approach that brings its own set of headaches into the equation (e.g. pop switches during extended exchanges)
cheald 16y ago
GeoDNS allows you to return different zone files depending on the location of the source query. If you are in New York, query for foo.cdnbar.com, and the nameserver serving that CDN is geo-aware, you might get a northeast-based IP. Google then caches that. 5 minutes later, I, in Arizona, come along and ask for foo.cdnbar.com, and it just gives me your northeast-based IP, meaning I have an extra four hops and 3000 miles for my packets to travel than if I'd pulled that IP off of my ISP's DNS.