DNS is one of the Internet's oldest and most ubiquitous protocols. It's also one of the most misunderstood and misconfigured. DNS is an efficient hierarchal distributed-database mechanism, but the effectiveness of that mechanism strongly depends on proper configuration. How you design your organization's DNS infrastructure can have a huge impact on the performance and security of your entire network.
What's the best way to configure DNS in an enterprise scenario? The key to effective and secure DNS design—particularly in large networked environments—is to segregate DNS servers into distinct roles, with each server dedicated to a single role. In this ideal scenario, each server's configuration, features, and zone data distinguish it from the next. Here's how to do it.
A Functional Foundation
Before we dive into the various DNS roles, you need to be familiar with how
the various DNS server functions work. These functions are to provide authoritative
responses, recursion, forwarding, and caching.
Authoritative responses. A DNS server's most basic function is to provide an authoritative response to a host-name lookup. When a server provides an authoritative response, it's essentially confirming that the answer it returns is the final answer and there's no need to look any further. When you register a domain name on the Internet, you must provide the registry with name servers that are authoritative for your domain. Those servers will always provide authoritative responses for your domain. The catch is tracking down the appropriate server for each domain.
Recursion. Recursion is what makes DNS a hierarchal database mechanism. When a DNS server doesn't know a particular host name, it sends out queries to other servers to find out which server knows the answer. The process starts with the DNS server taking what information it already knows, then working its way through the global system until it finds the authoritative server for a particular host name. To accomplish this process, the DNS server sends queries through the DNS hierarchy until it finds the correct server.
The recursion process might start at one of the well-known root servers scattered throughout the Internet. Suppose your browser needs to look up the IP address for www.example.com. If your DNS server doesn't know that address, it asks one of the root servers. The root server likely doesn't know that particular host address, either, but it does know the IP address for the DNS server that handles the com top-level domain, so it refers you there. In turn, your DNS server queries the com DNS server, which probably doesn't know the IP address for that particular host, but it does know which DNS server handles example.com, so it refers you to the IP address of that DNS server. Because the example.com DNS server happens to be authoritative for that entire domain, it returns an authoritative answer for www.example.com.
Although the query that a user sends to your organization's DNS server is a recursive query, the queries that your DNS server in turn sends out are non-recursive, or iterative, queries. Sending out iterative queries means that each remote DNS server queried will either return an authoritative response or point you to a server that gets you closer to an authoritative response, but that remote server will never make any attempt to contact other DNS servers on your behalf. Your local DNS server will do all the work necessary to track down a response and return the final answer to your browser—it will perform the recursion itself.
Forwarding. Although a DNS server will usually send out non-recursive queries, there is an exception, and that is when the server is configured as a forwarding DNS server. A forwarding server accepts client queries and relays them to another DNS server as recursive queries, requiring that the other server do the work to track down an authoritative response. Forwarding is an important part of the DNS infrastructure because it simplifies the client DNS configuration, provides a central location for DNS queries, and might provide access to networks that a client can't reach directly.
Caching. DNS servers also provide caching features. As a DNS server traverses the DNS hierarchy looking for authoritative responses, it learns a lot about the worldwide DNS infrastructure. To speed up future queries, it saves all this information, along with the host names that it resolves. Other servers in the DNS hierarchy also cache this information, making the whole infrastructure much more efficient. Caching can greatly shorten response times and significantly reduce network traffic. For example, if your DNS server already knows the IP address for the example.com DNS servers, it doesn't have to bother querying any servers beyond those, taking a huge load off the root servers and other high-level servers.
Essential DNS Roles
With this understanding of DNS fundamentals, you can see that DNS can play several
roles in your organization. The most common mistake that network administrators
make is configuring every DNS server on a network to perform all roles. (To
learn about the common threats that plague typical DNS implementations, see
the sidebar, "DNS Threats.") Keeping these roles isolated can stop or at least
minimize exposure to a variety of attacks.
When you design your DNS infrastructure, you should strategically segregate your DNS servers into three basic roles, with at least two servers—for load balancing and fault tolerance—dedicated to each role. The three basic DNS server roles are as follows
- Advertisers—These are Internet-facing DNS servers that provide host information for publicly available servers.
- Internal domain masters—Often integrated into Active Directory (AD), these provide authoritative answers for hosts in your local domain.
- Resolvers—These are centrally located DNS servers that provide forwarding and caching features for clients on your network.
By isolating these three DNS server roles, you can set specific features to maximize the security of each role.
Although each DNS server should be dedicated to a specific role, the entire server doesn't need to be dedicated to DNS. Because DNS services aren't generally resource hogs, you can often safely install them on servers that are dedicated to other purposes. For example, you might use public Web or mail servers for your advertisers, domain controllers (DCs) for your internal domain masters, and proxy servers or other gateways for your resolvers.
Configuring Advertisers
DNS advertisers let anyone resolve addresses for your publicly available hosts, such as your Web, FTP, and mail servers. These servers have the highest exposure to attack, so it's important that you carefully select the information that you make available on these servers. Advertisers should contain information about only publicly accessible hosts and should never contain private IP addresses. You should also configure your advertisers so that they share zone information only with your other DNS advertisers.
Many organizations use their ISP to host public DNS records, in which case you don't have much control over DNS configuration. However, if you host your own public DNS servers, you can use DNSCmd, one of the support tools in Support.cab, which you'll find in the \support\tools directory on the Windows Server 2003 CD-ROM. First, you'll configure the advertiser to listen only on a single IP address. For example, suppose your public DNS server has a public IP address of 192.0.34.166. You would use the command
dnscmd resetlistenaddresses 192.0.34.166
Next, you'll want to disable recursion so that the DNS server responds to requests only in its own zones. To do so, use the command
dnscmd /Config /NoRecursion 1
The next step is to make the DNS server a root server by adding the root zone. If a server thinks it's a root server, it assumes it already knows everything it needs and therefore will never attempt to contact other DNS servers. You would use the command
dnscmd /ZoneAdd . /Primary
Because this server is a public-facing DNS server, I recommend setting a few other restrictions to help prevent exposure to future attacks. First, use the following command to stop the DNS server from using the RPC protocol:
dnscmd /Config /RPCProtocol 0
Second, if all your zone names strictly consist of ANSI characters (i.e., they contain no special or foreign characters), you can configure the name server to handle only proper RFCcompliant names. To do so, use the command
dnscmd /Config /NameCheckFlag 0
Third, to prevent possible abuse of your DNS server, you can set a limit on how many host records it can return for each query. The following command sets a minimum of five records:
dnscmd /Config /AddressAnswerLimit 5
Configuring Internal Domain Masters
Your internal domain masters are the DNS servers that handle all name resolution for your local AD domains. If you haven't done so already, you should configure these servers as AD-integrated zones to take advantage of the more granular security control and improved replication features that setup provides. These servers are authoritative for their own zones but shouldn't attempt to perform lookups for foreign zones.
To configure your domain masters, you first need to disable recursion, as you did for your advertisers. You should also make internal domain masters root servers so that they never attempt to contact other DNS servers:
dns /zoneadd . /Primary
Configuring Resolvers
Now you can configure your resolvers. These servers should be centrally located so that clients on the internal network can reach them but so that they can also connect to external DNS servers. Your first task is to ensure that the resolver listens only on internal IP addresses. If one of your resolvers listens on the IP address 192.168.0.54, you would use the command
dnscmd resetlistenaddresses 192.168.0.54
Note that this IP address and the one you set for any additional resolvers will be the IP addresses that you configure on each client system as the DNS server in TCP/IP Properties.
Your second task is to have each resolver conditionally forward internal domain lookups to your internal domain masters. If your domain is example.corp and your domain masters are located at 192.168.0.11 and 192.168.0.12, you would use the command
dnscmd /zoneadd example.corp /forwarder 192.168.0.11 192.168.0.12 /slave
The /slave parameter tells this resolver to not attempt to find the address itself if the DNS servers don't respond. Because these are the DNS servers for your local domain, there's no point in trying to locate the IP address anywhere else.
Your third task is to set up a forwarder to handle all other DNS requests. This DNS server would be an external DNS server, such as the one that your Internet provider supplied. So, for example, if your ISP provides DNS server IP addresses of 192.14.9.22 and 192.15.9.23, you would use the command
dnscmd /resetforwarders 192.14.9.22 192.15.9.23
If you maintain a tight firewall policy, you might not want your resolvers to be able to perform recursive lookups on their own. If you prefer that your resolvers contact only your external DNS servers, add the /slave parameter to the previous command.
To test the setup, set the DNS servers on your network adaptor to those you used for your resolvers. Then, use Nslookup to search for several local and public host names.
Good Plan
If you follow this article's DNS server plan, you'll find that your DNS infrastructure will perform more efficiently and securely, and you'll experience more uptime. And you'll be capable of scaling to just about any size your organization requires.