4 ms·

So I'm a little fuzzy on how DNS works and this seems like a good place to ask: I was under the impression that end users typically talked to DNS cache servers

by gibybo 15y ago

So I'm a little fuzzy on how DNS works and this seems like a good place to ask: I was under the impression that end users typically talked to DNS cache servers rather than directly to the authoritative servers in the domain's registration. If that's true, how can AWS provide different records based on the requesting user? If end users are talking directly to one of the ~4 authoritative name servers listed in the registration, how does that scale to billions of queries?

electrum 15y ago
The caching servers are typically close to the user: at your ISP, in your office's server closet, in your data center, etc. In the case of public recursive DNS providers such as OpenDNS and Google Public DNS, this requires a recent extension to DNS: http://arstechnica.com/telecom/news/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup.ars http://arstechnica.com/telecom/news/2011/08/opendns-and-goog...
mcpherrinm 15y ago
The most important thing going on here is Anycast. See http://en.wikipedia.org/wiki/Anycast http://en.wikipedia.org/wiki/Anycast for a complete description, but basically, multiple machines have the same IP address, and different routes are advertised to different networks. This results in packets being routed to the nearest DNS server. Then, that DNS server can decide where the other end is and provide them with the correct IP. You're right that most users use a caching DNS server, so it is actually the location of the DNS caching server. Of course, since most users choose a DNS server close to them (usually, their ISP), this should still result in a correct approximation. If you're using, say, 8.8.8.8 (google public dns), that's (probably) more than 1 server -- you're using the closest one to you. So then AWS will provide you with the closest AWS region to the closest Google DNS server, which is hopefully the closest one to you.
- isb 15y ago
  As mcpherrinm described, anycast plays a big part in how queries are routed to a DNS server in Route 53's global fleet. You are right that a DNS server sees the query coming from the resolver instead of the user. So how does it pick the region closest to the user? As the blog post describes, we measure latencies from client networks to AWS regions and we also have a mapping of which resolvers are used by which client networks. If you put both of them together, you can compute which region is closest to the users of the resolver.
  - deleted 15y ago
    [deleted]
  - nl 15y ago
    we also have a mapping of which resolvers are used by which client networks How did you build this map? I can think of a few complicated ways to go about it, but I'm wondering if there is something easy I'm missing.
    - colmmacc 15y ago
      Take a look at http://whatsmyresolver.stdlib.net/ http://whatsmyresolver.stdlib.net/ for one simple way. Full-disclosure: I work on Amazon Route 53, and although we don't quite use that same method - it will give you an idea of what's possible. PS; we're hiring.
      - nl 15y ago
        How does it work? 1) I visit the site, it gets my IP address 2) Magic happens 3) It displays my nameserver address. What is going on in step 2? Edit: worked it out. For those interested, it uses a Javascript include from a unique subdomain name. Because the subdomain is unique the app can work out the relationship between client IP and resolver.
        colmmacc 15y ago
        The html page at http://whatsmyresolver.stdlib.net/ http://whatsmyresolver.stdlib.net/ loads a javascript script from the url http://whatsmyresolver.stdlib.net/resolver/ http://whatsmyresolver.stdlib.net/resolver/. Fetching http://whatsmyresolver.stdlib.net/resolver/ http://whatsmyresolver.stdlib.net/resolver/ triggers a 302 redirect to a url of the form; http://$guid.nonce.stdlib.net/resolver/ The DNS server authoritative for nonce.stdlib.net has a simple wildcard configured, so *.nonce.stdlib.net all resolve to the same web-server. Obviously the DNS request for the globally unique id domain name has to come before any HTTP request to the guid url, so when the DNS request comes in the authoritative server can record it in a simple lookup store (guid -> resolver source ip). Then, when the HTTP request makes it to the web-server, it can inspect the Host: header to determine what the guid was. It then uses this guid to correlate the HTTP request it is handling and the resolver source ip, and generates some javascript with the data we need; var resolver="192.0.2.53";var edns=true; It's just a hack I wrote up for my own reasons years ago. But if you'd like to avail of it for any reason (ie helping end-users debug things), feel free to embed; <script language="javascript" src="http://whatsmyresolver.stdlib.net/resolver/"/> and use the variables it populates. No warrantees or guarantee implied :-)
- donavanm 15y ago
  > The most important thing going on here is Anycast. ... This results in packets being routed to the nearest DNS server. Nearest in terms of AS path. This can be wildly different than latency as BGP isn't really implemented with cost/performance in mind. Anyone relying on anycast to answer their latency story is doing a lazy/poor/ignorant job of it. > You're right that most users use a caching DNS server, so it is actually the location of the DNS caching server. And another case where end users would be better served by providers implementing edns client-subnet extensions. This would allow savvy content providers to route to the actual end user, and not their resolver.
- nl 15y ago
  Anycast is good in the absence of better options, but I don't think this is Anycast. It sounds like here Amazon is doing unicast DNS, but dynamically changing the response depending on the IP address the query comes from. Since they have a big database of IP addresses and latency, they can choose the best response. The missing thing here is that they don't get the IP address of the client computer, only the DNS server. In many cases that (along with geo-location of the DNS Server) might be enough, but it is possible to do better. I'd speculate what they do here is correlate the IP addresses with the DNS server either by subnet or by using active measurement techniques.

by gibybo 15y ago

electrum 15y ago

The caching servers are typically close to the user: at your ISP, in your office's server closet, in your data center, etc. In the case of public recursive DNS providers such as OpenDNS and Google Public DNS, this requires a recent extension to DNS: http://arstechnica.com/telecom/news/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup.ars http://arstechnica.com/telecom/news/2011/08/opendns-and-goog...

mcpherrinm 15y ago

The most important thing going on here is Anycast. See http://en.wikipedia.org/wiki/Anycast http://en.wikipedia.org/wiki/Anycast for a complete description, but basically, multiple machines have the same IP address, and different routes are advertised to different networks. This results in packets being routed to the nearest DNS server. Then, that DNS server can decide where the other end is and provide them with the correct IP. You're right that most users use a caching DNS server, so it is actually the location of the DNS caching server. Of course, since most users choose a DNS server close to them (usually, their ISP), this should still result in a correct approximation. If you're using, say, 8.8.8.8 (google public dns), that's (probably) more than 1 server -- you're using the closest one to you. So then AWS will provide you with the closest AWS region to the closest Google DNS server, which is hopefully the closest one to you.

isb 15y ago
As mcpherrinm described, anycast plays a big part in how queries are routed to a DNS server in Route 53's global fleet. You are right that a DNS server sees the query coming from the resolver instead of the user. So how does it pick the region closest to the user? As the blog post describes, we measure latencies from client networks to AWS regions and we also have a mapping of which resolvers are used by which client networks. If you put both of them together, you can compute which region is closest to the users of the resolver.
- deleted 15y ago
  [deleted]
- nl 15y ago
  we also have a mapping of which resolvers are used by which client networks How did you build this map? I can think of a few complicated ways to go about it, but I'm wondering if there is something easy I'm missing.
  - colmmacc 15y ago
    Take a look at http://whatsmyresolver.stdlib.net/ http://whatsmyresolver.stdlib.net/ for one simple way. Full-disclosure: I work on Amazon Route 53, and although we don't quite use that same method - it will give you an idea of what's possible. PS; we're hiring.
    - nl 15y ago
      How does it work? 1) I visit the site, it gets my IP address 2) Magic happens 3) It displays my nameserver address. What is going on in step 2? Edit: worked it out. For those interested, it uses a Javascript include from a unique subdomain name. Because the subdomain is unique the app can work out the relationship between client IP and resolver.
      - colmmacc 15y ago
        The html page at http://whatsmyresolver.stdlib.net/ http://whatsmyresolver.stdlib.net/ loads a javascript script from the url http://whatsmyresolver.stdlib.net/resolver/ http://whatsmyresolver.stdlib.net/resolver/. Fetching http://whatsmyresolver.stdlib.net/resolver/ http://whatsmyresolver.stdlib.net/resolver/ triggers a 302 redirect to a url of the form; http://$guid.nonce.stdlib.net/resolver/ The DNS server authoritative for nonce.stdlib.net has a simple wildcard configured, so *.nonce.stdlib.net all resolve to the same web-server. Obviously the DNS request for the globally unique id domain name has to come before any HTTP request to the guid url, so when the DNS request comes in the authoritative server can record it in a simple lookup store (guid -> resolver source ip). Then, when the HTTP request makes it to the web-server, it can inspect the Host: header to determine what the guid was. It then uses this guid to correlate the HTTP request it is handling and the resolver source ip, and generates some javascript with the data we need; var resolver="192.0.2.53";var edns=true; It's just a hack I wrote up for my own reasons years ago. But if you'd like to avail of it for any reason (ie helping end-users debug things), feel free to embed; <script language="javascript" src="http://whatsmyresolver.stdlib.net/resolver/"/> and use the variables it populates. No warrantees or guarantee implied :-)
donavanm 15y ago
> The most important thing going on here is Anycast. ... This results in packets being routed to the nearest DNS server. Nearest in terms of AS path. This can be wildly different than latency as BGP isn't really implemented with cost/performance in mind. Anyone relying on anycast to answer their latency story is doing a lazy/poor/ignorant job of it. > You're right that most users use a caching DNS server, so it is actually the location of the DNS caching server. And another case where end users would be better served by providers implementing edns client-subnet extensions. This would allow savvy content providers to route to the actual end user, and not their resolver.
nl 15y ago
Anycast is good in the absence of better options, but I don't think this is Anycast. It sounds like here Amazon is doing unicast DNS, but dynamically changing the response depending on the IP address the query comes from. Since they have a big database of IP addresses and latency, they can choose the best response. The missing thing here is that they don't get the IP address of the client computer, only the DNS server. In many cases that (along with geo-location of the DNS Server) might be enough, but it is possible to do better. I'd speculate what they do here is correlate the IP addresses with the DNS server either by subnet or by using active measurement techniques.