(Editor’s Note: Phil Stanhope previously appeared on the Software Engineering Podcast. We have transcribed some of his interview below. Go here to listen to the entire podcast.)
[0:02:01.1] Jeff Meyerson: I want this conversation to go in a couple different steps. First, we’ll talk a bit about DNS and what it means for an engineering point of view. Then we’ll walk through some simple examples of how people use it and get to some more advanced modern complex infrastructure discussions of how DNS could be useful as a utility.
Starting from the beginning, DNS stands for Domain Name System, and this is the naming system that maps the entire internet. It associates information with domain names. More specifically, DNS specifies the mappings between numerical IP addresses and domain names. If I’m a software engineer, what are the other fundamentals of DNS that we should all know?
[0:02:51.7] Phil Stanhope: That’s a good question. Again DNS is what you just described, Domain Name System, and it’s for mapping addresses. Now, there are two address spaces. There’s the IPv4 address space that sort of most of us on the internet have grown up, but there’s also IPv6, and they’re running concurrently. That’s something that you need to consider because some of the very large players on the internet, they’re announcing both v4 and v6 space and the path that a packet may take over the internet can be very different for a v4 versus a v6. That’s one thing to consider sort of at the network level.
I guess the other thing that I’ve learned to say which some people like — It’s a bit pedantic, I guess, but is that there is an internet. There’s millions of internets in both v4 space and in v6 space. If I’m sitting in the same room with you and I try to go to a website by typing its common name in it, say, twitter.com, the path that my packets might take to get me to that webpage may be very very different based on my mobile carrier versus yours. It may be traversing a v4 network purely. It may be traversing a v6 network purely. It may be hopping in and out of both.
Often, you never have to know about that. Most people don’t even have to know how that really works but if you’re a developer and your mission-critical, high-availability, low-latency API endpoints, you really need to start to worry about these types of things.
[0:04:26.7] JM: If somebody in China opens up softwareengineeringdaily.com on their mobile phone versus me opening up softwareengineeringdaily.com on my mobile phone, give me a picture for how those two experiences might work at a lower level. What’s going on in the routing infrastructure along the millions of internets that is causing those domain names to both map to the same information?
[0:05:00.7] PS: Okay. There’re a couple things. One of the things that we do at Dyn also is we monitor the internet with a product that we call internet intelligence. Though we happen to know that on average every packet from your device, to the server you’re trying to communicate to, and there may be dozens of servers behind a particular web page, is on average about 13 hops. That means there are 13 public routers somewhere along the way. Some of those routers might not be performing very well. Some of those routers might have small pipes associated with them. Some of those routers might take you through proxies and firewalls which may induce packet loss or certainly induce latency into it. One thing that can happen is that you’ll take a different path and the many different paths you take, any one hop can be a problem area, and DNS can’t solve that for you. That’s a network monitoring level consideration.
There’s another consideration, which is we tend to think simply that, “Oh! I got a web server and I’ve got an IP address,” maybe I leased an IP. Say, I’m hosting it out of a cloud provider and a compute instance and I’ve been given a public IP. I’ve got a server and I’ve got one IP. If you’re really good with tools like Nginx, you know that you can host many different servers or services through the same HTTP, HTTPS proxy, and that’s just configuration issues. How well and good you are at configuring Nginx, but that’s one IP.
It’s also quite possible that if you’ve got one server, one IP, and that user is in China and your service is on the East Coast, they’ve got a long way to get there even though it still might be on average, 13 hops, it’s from the other side of the planet and physics gets involved; the speed of light. You can only push packet so fast down a fiber-optic wire. If I’m on the East Coast, short path, I’m probably going to get much better response time. That’s one level of consideration.
I’ll introduce another term because I’m looking through some of the notes and it’s not there. It’s Anycast. That single IP in v4 speak that’s a /32. It’s a single address out of one of a potential of 4 billion addresses, and that’s yours. With Anycast, you have to widen it at a minimum for it to work on the internet to what’s called a /24 in v4 space, so 255 potential addresses that you could communicate to.
Then with Anycast, I tend to refer it to as you can “lie to the internet.” You can say that you’re in more than one place at the same time. With Anycasting, you could have an Anycast edge that was very close to China, maybe in Taiwan or in Tokyo, or Seoul. Then if you’ve done that, you can do with Unicast or Anycast. You could have two Unicast addresses and have DNS steer you to the one that’s closer, or you could have a single Anycast address or what seems to be a single Anycast address and the networking routing infrastructure will take you to the closest address.
At Dyn, we’re very familiar with both of these techniques and we use them to manager our service and our top customers run a hybrid of Anycast and Unicasting on the public internet and allow us to provide naming over it.