Best Practices

If you're a network provider, you're almost certainly going to have to provide DNS services to your customers.

DNS is a critical piece of network infrastructure, but because it usually runs on general-purpose hosts (as opposed to dedicated hardware most network engineers are familiar with, such as hubs, switches, routers, etc...), it usually does not get the attention from them which it deserves.

However, because DNS is a piece of network infrastructure, it's also alien to most of your typical systems administrators, who are more likely to be familiar with host services such as web, mail, etc....

The end result is that almost no one ever pays any attention to the DNS, until something screws up. At which point, it's too late to do anything to fix the problem -- you're already toast.

Caching Versus Authoritative[]

There are two flavors of DNS you're likely to need to provide.

First is caching/recursive DNS for your clients, so that they can look up information on machines in the outside world (these are the "DNS server addresses" end user customers configure into workstations, if DHCP doesn't do it for them).

The software on those clients that does the looking up is called a "resolver" -- commonly the only configuration resolvers require is to be told the addresses (note: not names; that would get you into a recursive loop) of the caching servers you want them to talk to. This can be done manually by the end-user, or more commonly these days (for non-IT-managed clients, anyway) by the DHCP server from which they also get their IP address.

Second is authoritative-only, or "zone", service for the clients that you are hosting, so that everyone in the world can find out where they are and access their site.

Another way of stating this distinction is proxy service versus hosting. When you run caching/recursive nameservers, you are providing a proxy service for clients so that they do not have to make requests directly to external nameservers. When you run authoritative nameservers you are hosting a domain so that all Internet users can have access to the names in that domain.

The early nameservers lumped all these functions into a single piece of software but that does not mean this is a good way to operate the software. Now that it is acknowledged best practice to separate these two functions, it is also possible to find DNS server software that specialises in only one of the two functions.

Open Caching/Recursive Servers[]

In the olden days, we'd run both types of service on one machine, and not worry about locking down the security so that no one could abuse it. In the modern Internet, that is not only unsafe, but may well lead to serious legal liabilities. Pharming may be the most recent type of attack, but it is certainly not the only one.

If your caching/recursive nameservers are open to the world, then spammers can "virtually host" their domain through your servers. They register their authoritative servers with the Internet Registrar, but give them very low TTLs. In their own servers, they list your nameservers as being authoritative. Normally, this would be a "lame delegation", but since your servers are caching/recursive they will go ahead and provide whatever information they've got anyway. Any illegal activity that occurs as a result of this "virtual hosting" on your machines could potentially lead to legal liability on your part.

Therefore, it is important that you secure your caching/recursive nameservers so that only your own clients can use them (use the nameserver software itself to restrict them by the netblocks you own, as well as preventing incoming queries coming to them at the network firewalls).

Cache Poisoning[]

A second part of the security problem occurs if you mix caching and authoritative services in the same nameserver -- through "cache poisoning," the Bad Guys may be able to cause your server to hand out whatever information they want about your own domains.

If the caching services are physically separate from the authoritative services, then this is no longer possible. You don't necessarily need to run two separate sets of machines, although that would be advisable. At the very least, you should run two separate sets of nameserver processes -- one for caching-only, one for authoritative-only.

Note that this is not a panacea. Even if you do have completely separate caching-only and authoritative-only services, it is entirely possible that attackers may be able to poison the caches of your caching-only servers. You can't do anything to stop that. But, you can protect your authoritative-only servers, and you can limit the damage your caching-only servers can cause should they become poisoned/polluted.

Nameserver Chaining[]

Note that even if your own servers are not necessarily vulnerable to cache poisoning, if there are any servers for parent domains that are vulnerable, you may well still be screwed. Most types of naieve security depend merely on hostnames, even if they do the forward/reverse/forward triple-check dance. But if there is a server for a parent domain that is vulnerable to cache poisoning, they may be able to stuff bogus information into those servers so that the triple-check dance appears to work okay.

The servers for .com are probably secure against cache-poisoning, but recent surveys have shown that many TLD servers are not secure against cache-poisoning, and anyone in any of those TLDs is basically an accident waiting to happen -- or be discovered.