Considering DNS Server Design

Not everyone has the experience necessary to design solutions for infrastructure-level applications, such as DNS (or for Web and mail, but that's another topic). If you follow a basic set of guidelines, though, you can have a stable and scalable DNS server without much hassle. Stability and scalability are the two qualities that all architects strive for. Of course, DNS servers can be implemented in other ways; every systems administrator seemingly has her own tricks for configuring a system. Keep in mind that every clever trick you use in configuring a system is one more headache you have when you're troubleshooting the system later on. Strive for simplicity, and your sanity will thank you.

Keeping the server secure

Security is paramount when you're configuring a DNS server. You may think that security is truly important only in an Internet Service Provider (ISP) setting, to avoid Web page hijacking or e-mail spoofing, but it's equally important in a corporate setting. DNS security is quite important in an ISP. If an intruder gains access to your DNS server, he can point A records to other servers containing defaced Web pages, which is as good as gaining access to the original Web server itself and defacing the page. The intruder's access can also be used to change the MX record for a domain, which has even worse consequences. By pointing the MX record to a mail server, the intruder controls and even takes ownership of the domain by submitting changes to the domain registry. Note that this insecurity is not so much a fault in the DNS infrastructure as it is the fault of the domain administrators who use MAIL-TO as an authentication method for their domains.

DNS security is equally important in a corporate setting, although it has a more subtle importance. The problem in a corporate environment is the same as in an ISP: An intruder can change DNS records to point to a server he controls. In this case, he can steal important data by making users think that it's going to a real server when it's really going to the rogue server. Remember that most attacks on corporate networks come from inside the corporation, so DNS security is important even if you have a firewall or even no Internet connection.

DNS does not run in a vacuum. Not only does your DNS service need to be secured, but the operating system you use and the physical server also need to be thoroughly examined and tested. Even if you have secured the DNS services properly, all is for naught if a network intruder can gain administrative- or root-level control of the server that is hosting DNS.

Perhaps most obvious, you should physically secure the server in a location where only authorized users can gain access. You should also restrict, using operating system policies, nonadministrative personnel from being able to log on to the server. Regularly check with your operating system vendor for software updates and security alerts. The security of the server that is hosting DNS is "Job #1" — if you let it slide, you'll probably regret it.

In case of emergency

When planning out your DNS infrastructure, you always need to have at least two DNS servers for the purpose of redundancy. If one server goes down, the other one can still serve clients. DNS servers in many cases aren't redundant, but that situation is absolutely not recommended. If you're using a single DNS server and it fails, you will probably get the unenviable task of answering lots of nasty phone calls.

You can provide DNS redundancy in two ways:

• Master/slave: In the traditional master/slave DNS relationship, (one or more) DNS slave servers load zone data from the master server on startup and at intervals specified in the start of authority (SOA) record for each zone. This method of redundancy has one huge advantage: When a zone file is changed, the changes are automatically propagated to the slave servers. This process normally happens as soon as the changes are made if the NOTIFY DNS feature is supported, and it happens after the time interval in the SOA record if NOTIFY is not supported.

The master/slave DNS server relationship has a disadvantage also: If the master goes down, the slave is restarted, and the zone data cannot be transferred. Also, if the master goes down and isn't restored by the time the DNS record becomes stale (because it cannot update from the master server), the zone is no longer accessible.

• Multiple master: If you're more concerned with having DNS available at all times rather than having the convenience provided by a master/slave configuration, you can use a multiple master configuration. This concept is simple: All DNS servers are master servers for each zone. The most difficult part of having multiple master DNS servers comes when a change is made to a zone file or the DNS configuration. The change must be made to every master DNS server and isn't automatically propagated.

Don't put all the eggs in one basket

The location of the DNS servers is important for a number of reasons. (This section overlaps slightly with the preceding two sections.) Most environments use two DNS servers — a master and a slave or two masters if they're caching only — although no limit exists on the number of servers you can have.

You must consider two separate but related issues for the DNS server location:

• Placement in relation to a firewall: In most cases, internal DNS servers are placed on the internal network, and externally accessible servers are placed in the demilitarized zone (DMZ) of the firewall, which is secure but also accessible from the public network. If you have only one set of DNS servers for both internal and external DNS (although that arrangement isn't recommended), you should place them in the DMZ and have internal users access them from the internal network rather than place them in the internal network and open a hole in your firewall for external DNS requests.

• Placement on your network segments geographically or in some other logical fashion: You have a number of reasons to place your DNS servers on separate network segments and separate locations —primarily, redundancy. If one network segment goes down, or even an entire location is lost because a disaster of some sort, you still can provide DNS service. In addition, performance increases for internal DNS servers may result if you configure systems to use the local DNS server first and use the remote DNS server if the local server is down. Having at least one internal DNS server at each geographical location is common practice.