Reaction: DNS is Part of the Stack

Over at ipspace.net, Ivan is discussing using DNS to program firewall rules—

Could you use DNS names to translate human-readable rules into packet filters? The traditional answer was “no, because I don’t trust DNS”.

This has been a pet peeve of mine for some years—particularly after my time at Verisign Labs, looking at the DNS system, and its interaction with the control plane, in some detail. I’m just going to say this simply and plainly; maybe someone, somewhere, will pay attention—

The Domain Name System is a part of the IP networking stack.

Network engineers and application developers seem to treat DNS as some sort of red-headed-stepchild; it’s best if we just hide it in some little corner someplace, and hope someone figures out how to make it work, but we’re not going to act like it should or will work. We’re just going to ignore it, and somehow hope it goes away so we don’t have to deal with it.

Let’s look at some of the wonderful ideas this we’ll just ignore DNS has brought us over the years, like, “let’s embed the IP address in the packet someplace so we know who we’re talking to,” and “we must build all filters based on IP addresses” (the instance Ivan is talking about). We’ve gone for years treating one thing as the other, so that now we actually want to split the IP address space up so we can have “locators” and “identifiers.”

It’s all nonsense—IP addresses are topological locations on the network, and DNS names are host identifiers. If you want to know which host you’re talking to, you need to know what it’s DNS name is, not where it is attached to the network. So why don’t we use DNS names for hosts? Because “DNS is too slow,” and “it would be too much work to make DNS interactive, so that individual hosts can tell the DNS system where they are.”

Perhaps this was all true years ago—but it was also true that routing was slow years ago. Why was routing slow? Because processors were slow, bandwidth was slow, and memory was precious. Routing is now fast because processors are fast, bandwidth is high, and memory is (at least) not extremely expensive. Today we stream HD movies in near real time, and yet we still whine about a couple of DNS packets. Really?

What we’ve done is carted out the same old tired excuses for not using DNS for years on end, rather than fixing it. As a result, we’ve moved policy and identification into routing, making a complete mess to solve problems that don’t really make sense to solve in routing.

The reality is: if you own the DNS system in your network, DNS is only as limited and slow as you make it.

Even on the global ‘net, it’s not as slow as you think. We’re all so conditioned to our service providers telling us “it could take up to 24 hours for DNS information to propagate throughout the Internet,” that we just think even the best run DNS servers always take 24 hours to “get the information out.” There are even services out there promising to solve this problem, making your DNS changes fast. I can’t find any real information on this, so I’m going to fall back to anecdotal evidence—I shift a few sites around from service provider to service provider from time to time, and I’ve never seen it take more than 2-3 minutes to switch from IP address to another.

The bottom line is this—don’t be afraid to use DNS for what it’s designed for in your network. There are specific applications where it might not make sense to use a DNS query—when the destination address is an anycast for a specific service, for instance, or when milliseconds actually count. But by and large, the more you stick with using DNS to indicate devices, and addresses to indicate locations, the easier your network is going to be to manage over the long term.

Location and identity are definitely two different things, but we don’t need to treat IP addresses as if they were identifiers to solve the locater/identifier problem set.

We need to learn to treat DNS like it’s a part of the IP stack, rather than something that “only the server folks care about,” or “a convenience for users we don’t really take seriously for operations.”