Knowing how queries work, and the difference between authoritative and caching nameservers, puts you most of the way to understanding DNS best practices. The remaining important concepts are the topology of how and where you deploy DNS servers, and the configuration files that dictate how they operate.
- Network topology. Redundancy helps your domain continue to exist even if a server fails or a network cable is cut somewhere in the world. BIND supports redundancy through a masterslave relationship where a master nameserver pushes its name mappings to one or more slave servers through a zone transfer.
- Configuration files. BIND’s configuration is in a file named.conf. The named.conf file tells the server whether it is authoritative and/or caching, and whether it is the master or slave for a given zone. The file points to zone files that contain actual name mapping information. Zone files contain lines, or records, that define, among other things, name-to-address and address-to-name mappings for a specific domain or range of addresses. Some of the most important record types are summarized inTable 1.
You will typically have a zone file for forward mappings visible to the outside, a zone file for forward mappings visible to the inside, and reverse maps for both. One of the beauties of BIND 9 is that it supports views. Views tell BIND how to respond to requests based on where they come from. They allow you to run a single server that hands out private addresses for internal systems, and public addresses for services that you provide on the Internet.
Example DNS and Active Directory configuration
The best way to show how all of these concepts come together is by walking through an example. The network topology diagram shows how DNS servers might be deployed and configured for a company having anywhere from two to 10,000 employees. Our example, barkingseal.com, has two subdomains, one for engineering and one for marketing. Like most companies, it uses private (RFC 1918) addresses for its internal systems and public IP addresses for the services it provides to the outside world. It uses a combination of BIND and Microsoft Active Directory to support both Windows desktops and other servers and workstations. The network topology, along with the inside and outside forward maps, is illustrated in Figure 2. The corresponding inside and outside reverse maps are illustrated in Table 2.
External authoritative nameservers
barkingseal.com’s domain registration information points to the minimum of two nameservers, in this case a master that’s in the company’s DMZ and one that’s located far away across the Internet so that a failure that takes the company offline doesn’t make the domain disappear. Always, always, have a slave nameserver on a different network (a different ISP backbone) in a different location than your master. If you don’t want to host one yourself, there are DNS hosting services that will do it for a fee. Protect your authoritative nameservers with a firewall, but don’t hide them with network address translation. You want them to be available at the same address whether accessed from inside or outside of your network, and there is a specific, serious vulnerability that can occur if you put NAT in front of a caching nameserver.
The master authoritative nameserver supports an inside view and an outside view. The outside view provides forward and reverse mappings for the following two classes of public addresses. The outside view does not support caching or recursion.
- Public addresses are for externally provided services, such as Web (barkingseal.com) and mail (mail.barkingseal.com) servers.
- Masked NAT addresses are the public addresses used when internal systems request external services. This is usually a pool of addresses that your firewall uses when passing requests from internal, private addresses to external, public ones. Network address translation masks your internal network topology, and DNS helps to support that masking. The example in Figure 1 translates internal, private addresses to one of two public addresses, nat[1,2].barkingseal.com.
Regardless of what addresses you do or don’t mask, for a variety of reasons forward and reverse maps should be an exact mirror of one another.
Internal authoritative nameservers The master authoritative nameserver supports an inside view that describes barkingseal.com’s internal systems. This view allows caching and recursion. All requests for addresses from internal systems are serviced by the inside view. This view has zones including the following:
- Forward and reverse mappings for public addresses such asbarkingseal.com and mail.barkingseal.com.
- Forward and reverse mappings for addresses that point to file servers, printers, internal services, and Linux desktops — anything that’s not a Windows workstation. Addresses such as fileserver.barkingseal.com resolve to private RFC 1918 addresses such as 192.168.2.21.
- A delegation of authority to the subdomain eng.barkingseal.com, which is a domain controller running Windows DNS. This is done through a simple NS record and a corresponding A record as illustrated inTable 1.
The master authoritative nameserver has at least one slave in each physical location. The slave is a caching, recursive nameserver that acts as the primary nameserver for all non-Windows systems and indirectly for Windows workstations. It is placed topologically close to its clients, preferably on the same subnet. If the caching nameserver fails, the internal authoritative nameserver is the backup, at the cost of queries having to traverse the firewall, adding some latency to each request. Depending on the size of the organization, the locations of its subnets, and the importance of performance, two caching and slave authoritative servers might be provided.
Active Directory Servers
Two Windows servers run Active Directory. These servers are authoritative nameservers for the eng.barkingseal.com subdomain, which includes all Windows desktops run by engineering. Two servers are used for redundancy, and their multi-master configuration keeps the two servers synchronized. The servers accept secure dynamic updates, but they do not propagate updates to upstream BIND servers, where they will be rejected. The servers are caching, but non-recursive. Instead, they forward any queries they can’t answer to the caching nameserver, which recursively resolves requests.
Keep your eye on the ball
The lessons of this example include the following:
- Distribute your external authoritative nameservers across more than one ISP.
- Never use a private (RFC 1918) address for a nameserver visible to the outside world (even for its inside address).
- Use split views to mask internal addresses. The outside view’s forward map is a small subset of the systems on your network. Addresses are provided for services exposed to the outside world, and all others are translated to a pool of NAT addresses. In contrast to the outside view, the inside view is complete. It can include both public and private addresses.
Leave a Reply
You must be logged in to post a comment.