 |
The Internet Cookbook by Robert J. Kohlhepp
Recipe 4: Building a DNS
One DNS architecture, preferably distributed Motivation With implementation of IP on the network, you also invite the issues related to locating services. Most other network architectures, such as AppleTalk and NetWare, make heavy use of discovery protocols to advertise services on the network. In the beginning of the Internet, memorizing IP addresses was a fact of life. But, since the introduction of BIND (Berkeley Internet Name Domain), users need only memorize words, which is easier for most.
DNS still doesn't allow advertising of services. It only makes descriptors easier to remember. More advanced users can make use of tools such as n slookup and dig to mine information from DNS servers. But, that still isn't for end users.
The web makes resources much more accessible in this respect. Most users can remember a single access point, such as www.such-and-such.com. Using HTML, embedded hostnames can automatically point users to the proper resources. This doesn't make DNS easier to use, as it really is only a bi-product of a naming service. But, it does allow administrators to move machines to different networks without impacting users. A simple hostname to IP address record needs to be changed.
In this recipe, we will discuss a proper architecture of DNS servers. This will include a discussion of the basic architecture and some configuration file tweaking. A well prepared DNS directory architecture will help define areas of your network as well as lend itself to a redundancy that will keep your users up and running.
A good starting reference point for DNS configurations is: http://pluto.iis.nsk.su/docs/bsd-4.3/named.html Architecture
Once embarked on a the mission to create a DNS infrastructure, you will soon realize that you need a way to isolate certain portions of your DNS hierarchy. Not only will you want a separate DNS server external to your network with limited information, you will want servers distributed throughout your network to prevent unnecessary DNS traffic on the WAN and LAN and reduce lookup latency.
Splitting the internal and external servers will allow you to advertise certain hosts to the outside world and protect your internal hosts. A simple way to do this is by creating a hierarchy. Since you are probably already locked in to your second level domain (first level probably being .com), such as company.com, you will need to add a third level to discern departments, such as acct.company.com and engr.company.com.
Once you have a hierarchy established, you can start thinking about strategic locations for the primary s ervers for those subdomains. You will want to co-locate them with the bulk of the users in those departments so those users can use the server as an initial DNS contact. More than likely, they will be using mostly machines in their department and those hostnames will reside on their local DNS server.
Taking a glance at the following figure,
we have a DNS architecture that segregates all of the working departments yet provides corporate-wide DNS lookups. By making each DNS server a primary for it's location and a secondary for the others, we have created redundancy. In addition, each desktop can be configured to query the local server first and fall back to another department's server.
The external DNS server will handle all of the
By only publishing a certain number of hosts on your external DNS server, you keep the topology of your internal network a secret. However, for internal users to be able to look up hosts on the Internet in general, you will need to configure your internal DNS server with the root DNS server on the Internet. In addition, you will have to add a number of rules to your firewall to allow them to make external queries, such as:
| |||||
| rule | source | destination | protocol | action | logging |
| X | Engr DNS | root servers | DNS | allow | none |
|
Configurations Using BIND for UNIX as an example, we will go through some of t he configuration files that make all this happen. The applicable files are /etc/named.boot (the configuration of the service) and the DNS host files (usually in /usr/named or /var/named and called zone files). These govern the way the DNS reacts to outside queries.
The primary server Your first server for the corporation should be your main, internal DNS server, which holds the internal version of the company.com zone. This server will also delegate authority for the subdomains within the company. An example named.boot file for the main server is:
cache . /usr/named/named.ca
The first line points to the "cache" file, which is actually only a list of the root name servers out on the Internet. The second line is the reverse lookup for the loopback IP address which will have only one entry for the local machine. The third line tells that we are the primary server for the company.com zone and which file list all of the hosts, associated IP addresses, and other DNS information for the company.com zone. The last is a reverse lookup file for the IP addresses that your company uses. This file will be used to map IP addresses back to hostnames (reverse resolution).
So, your starting files will look something like this:
company.zone
This will be the bases of your main, internal name server. With this setup, you have made this machine the master server for the company.com zone and you have delegated the engr.company.zone to the name server in the engineering department.
The last step for the main server is to set up a minimal reverse address space. This will allow machines on the network to take an IP address and look up a name for the machine. This is shown above with the file zzz.yyy.xxx.rev (zzz.yyy.xxx would be the first three bytes of a class C address space, for example).
zzz.yyy.xxx.rev
After this initial setup of the main DNS server, most of the secondary servers follow a very similar method. So far, we have defined two name servers, one for company.com and one for engr.company.zone. In addition, users can look up the IP numbers of either of these servers or look up the hostnames from the IP address. Additional hosts are added in much the same method (using the "IN A" notation in the for ward lookup file and "IN PTR" in the reverse lookup file). Subdomain authority Starting a subdomain architecture is a matter of creating servers that will serve the subdomains, such as engr.company.com, and giving authority to those servers. Authority is configured at the main server for company.com.
To add authority for your subdomain servers you will need to add that information to your zone file for company.com. Say that we create a name server for engr.company.com on a server called ns.engr.company.com. We would delegate authority by an addition to the main company.com one file:
ns.engr.company.com IN NS
This tells the main company.com server where the machine is and what it is responsible for. If a DNS request comes in for a host called charley.engr.company.com, the main server will pass that request off to ns.engr.company.com. Secondary name servers Implementing secondary name servers is a cinch, if you already have name servers dispersed throughout the enterprise. Using our example for engr.company.com, we could add secondary name service for company.com zone. A simple addition to the boot file for named (on UNIX /etc/named.boot) on ns.engr.company.com:
secondary company.com
This will make your engineering name server a primary for engr.company.com and a secondary for company.com. Likewise, you may want to add entries for accounting and other departments. Then users in the engineering department that are looking up names other than those in the engr subdomain will not have to look any further than their local server.
A secondary name server will respond to queries for the primary server. To keep its information up to date, it polls the primary server at regular intervals to check for changes in the DNS entries. So, if you update files on the primary server, those changes will not propagate to the s econdary servers until the next polling time.
You can tweak the secondary refresh time by modifying the one files on the primary server. Within the header files of every zone file, they are a bunch of number that dictate whether the file has changed, how long the information can be cached, and how often secondary servers need to check back for changes.
In the header we find:
@ IN SOA internal-ns.company.com. root.company.com. (
The first line in our example just starts the authority for this file (not really important for refresh rates). The second line is a timestamp that tells when the file was last changed. After that, we get into the information that tells caching servers (including secondary servers) how to handle the data.
The refresh time is how often the cache needs to check for any changes. The retry is how often the cache needs to check back if it can't contact the server for a refresh. The expire is how long the cache can hang onto the data before it has to throw it away.
So, in our example, ns.engr.company.com is a secondary for the company.com zone. It will check the primary for company.com every hour to see if any files have changed. Should the primary server go down, ns.engr.company.com will keep trying to refresh every hour for 5 days. After five days of the primary server being down, ns.engr.company.com (the secondary) will throw away the data it has for the company.com zone.
Nicknames (short names) Once the subdomains are created, users will need to type in hostname.(department).company.com to get to their local resources. But, there are some hosts tha t reside in a department that others need to access. To make name lookups a bit easier, you can add aliases in the main company.com server.
For instance, say you have a corporate-wide intranet server that users can access payroll information on. Since that server is in payroll, you may name it payroll.acct.company.com. To simplify, you can also add an alias that allows users to access it via payroll.company.com, since it is used by all departments. This simple entry in the company.com zone file will add this functionality (headers for company.com file)
payroll IN CNAME payroll.acct.company.com.
Updated February 19, 1997
Print This Page
 E-mail this URL |
|||||
