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.
Prev. page
[1]
2
3
next page 
