How To Get The Most Out Of DNS
For many network administrators, learning and leveraging TCP/IP and its services can be difficult. The solution has often been avoidance. By ignoring the services that you haven't had a chance to fully internalize, you may hope that you can postpone deploying them. But unfortunately, IP doesn't like being ignored and retaliates by becoming more complicated the longer it goes unnoticed. Anybody who has had to go back and catalog IP addresses, after casually assigning them, can testify to the time that would have been saved had the original assignments been handled in an orderly fashion.
The Domain Naming Service (DNS) is one of the better examples of this phenomenon at work. Administrators who are forced into prematurely deploying IP often ignore DNS, figuring that they can get by with using native IP addresses or relying on HOSTS files as a backup strategy. They'll get around to DNS "one day."
Meanwhile, the number and variety of IP-enabled systems on the LAN will have multiplied, with the same number and variety of local HOSTS files on all of those systems. The time it will take to rewire these devices into DNS will far outweigh the time spent learning and correctly configuring a DNS service. Here are 10 tips that will help you get the most out of DNS.
Read The Book!
Buying and reading O'Reilly and Associates' DNS and BIND is one of the greatest favors you can do for yourself and the rest of the Internet community. It takes only a few days to read, and if you practice on a nonproduction machine, you'll be a DNS master in no time flat. Earmark the sections that give you grief, and ask a knowledgeable colleague or support engineer about them. You also can find help from the comp.protocols.tcp-ip.domains newsgroup.
Use Descriptive Host Names
It can be difficult to figure out who has the host named "MYCOMPUTER." Wouldn't it be easier to locate a troublesome system if it were named "FREDSMITH-PC?" At least you would know that it was the PC used by Fred Smith. Granted, you can't always get away with this, but the concept holds true. Having PCs named "ACCOUNTING001" is infinitely better than systems called "MYCOMPUTER."
Some might argue that this actually is a bad idea, since the devices may get moved around a company or may be used by many people. If a device is relocated, you'll need to change the address anyway, so changing the hostname is no big deal. And if you didn't have to relocate a device, you would have to buy a new one, thereby incurring more labor than a name change would require. You cannot escape managing your network, so do yourself a favor by managing it well.
The benefits of being able to locate any device far outweigh any fractional increase in management time. If you think that having to rename hosts as they transfer ownership is troublesome, just wait until you have to locate a host whose name is meaningless. You will quickly discover the merits of descriptive hostnames. We are not promoting this naming system for multiuser systems or servers. Those devices should not be called "FREDSMITH-SERVER."
A word of warning: The only "legal" characters are letters, numbers and the hyphen. Using underscores or other illegal characters—even if your software seems to allow it—eventually will result in problems. In addition, a name is not supposed to be all numbers, but a name that starts with a number (3COM.COM, for example) is fine. Also, be careful not to use names that may be misinterpreted by the DNS client. For example, a hostname of "0xa" is legal, but it also looks like hexadecimal notation, and some systems will translate it as such.
Implement Appropriate Resource Records
Newbie DNS administrators generally provide no more information than the A (address) record for the hosts that are under their control. There are, however, loads of advanced records that let you exploit DNS. If you implement even a few of these, you'll be able to increase your overall productivity.
For example, the host info (HINFO) resource record will provide information about the device hardware and operating systems, letting you use your DNS as a low-cost, functional resource-tracking tool. For each system on your network, you can store information like "DTK 8086 CLONE" and "PC-DOS 3.1."
One tip: Use quotes around the hardware and operating system strings. Since the HINFO resource record supports only the hardware and the operating system descriptors, you will need to use quoted strings to pass detailed information successfully. Not all DNS servers support the use of quotes either, so test before you implement on a wholesale basis.
Another resource record is the TXT type. TXT lets you store any string you want and associate it with a specific host. So, just as we are storing the hardware and operating system information using the HINFO record, we also could store information such as "Word processor: WordPerfect 4.0" and "Username: Jeff Newman" or "Home telephone: 415-555-1234." This information is then readily available wherever you are on the network. Make sure to enclose the comments with quote marks. Also, the TXT record as defined requires that any leading or trailing spaces be stripped, so if you want this info in your TXT records, you need to preface them with the accent character.
Also, rather than use the TXT record for storing information about a system administrator or user, you instead could use the RP record, or Responsible Party. The RP record lets you look up the name and e-mail address for any host's "responsible party." Granted, this same information can be stored in TXT records, but having it in an RP field makes it easier to filter out in a hurry.
A word of caution about these resource records: You may not want to make this information available to systems outside of your organization!
Take Advantage of MX Records
A very common resource record is the MX, or Mail eXchange, entry. MX records let you redirect mail for any host or domain to any other host or domain. For example, you can reach me at ehall@nwc.com, even though there isn't a host called NWC.COM. Instead, we have an MX record for our NWC.COM domain name that redirects mail to a system that accepts mail on its behalf. This host then places the mail into the EHALL mailbox.
By separating mail delivery from physical hosts, users can send mail to anybody@nwc.com, regardless of what host the mail actually ends up on. If we need to change the destination mailhost, we could at any time. If instead we were to rely on explicit hostnames for delivery, we could not easily move systems or users without worrying about who might still have an old explicit address.
Note that MX records do not provide mail routing for individual user accounts, but instead provide mail routing services for destination systems. End-user mail routing is generally provided by system-specific ALIAS databases or other system specific tools.
MX records can be implemented for an entire domain, as described in this example, or on a host-by-host basis. Just as you can have mail that is destined for a domain rerouted to a specific host, you can have mail that is destined for a specific host rerouted to another host. If for example we chose to have mail sent to our NetWare server, we could have easily sent it to our NT server by adding an MX record.
This comes in handy when a server is down. By defining MX records for our hosts, we can have mail sent to a temporary destination rather than have it bounced back to the sender. When the target system is brought back online, the temporary host will forward any waiting mail to the final destination.
For the temporary host to do this, however, it must know that the mail is not intended for itself, but is to be sent to another system for final delivery to the user's mailbox. If there is only one MX record, then the temporary host will not know this, since it would be identified as the final destination.
This problem can be circumvented by specifying multiple MX records for each host or domain for which you want to provide mail-routing services, as well as by specifying the preference for each of those hosts. Our MX entries can be seen in "Sample Mail Exchange Entries," on page 102.
In this scenario, mail addressed to user@nwc.com is sent to NTAS. If NTAS is down or unreachable, mail is sent to SPARC10. SPARC10 will subsequently attempt to deliver the mail to NTAS.
If you wish, you can redirect mail for all hosts in a domain by using a wild card character. In our case, this would translate to an entry for *.NWC.COM in the first line above. Any mail that is sent to any host in the NWC.COM domain will be routed to the host specified by the wild card MX record. Note that this will not override any hosts that do have an MX record of their own, but will intercept only MX requests for hosts that do not have their own MX record.
Get Reverse Lookups Working
Most administrators forced into dealing with DNS the first time invariably forget to add reverse pointer information to new records. This can lead to problems ranging from FTP servers refusing to support your users to higher-level services reporting false security breaches.
Reverse address entries are stored in pointer (PTR) records in the reverse lookup files associated with the specific subnet where the nodes are located. This is the reverse of "normal" DNS, where in getting an address for a known hostname, you try to find the hostname associated with a known IP address.
Unlike more common domain names, such as .COM and .EDU, reverse lookups occur through the IN-ADDR.ARPA domain. For example, if you have authority over the 192.155.15.0 subnet, then your DNS server will have authority over the 15.155.192.IN-ADDR.ARPA domain. If 192.155.15.12 connects to a system that logs fully qualified domain names (the FQDN), then it will issue a lookup for the 12.15.155.192.IN-ADDR.ARPA "hostname" and store the resulting PTR data. For this information to be returned, you must create and serve it.
Use Different Internal and External Servers
There are plenty of reasons for not wanting to publish your entire network via DNS. Hackers could easily obtain a profile of your network and identify weaknesses used in attacks against you. Rather than avoid the situation, it's easy enough to confront it head-on by building two distinct DNS servers: one for internal use and one for external lookups.
This is accomplished by providing two different sets of IP addresses to the internal clients and the outside world. All DNS clients use a RESOLV.CONF, or similar, configuration file that instructs the client where to issue DNS requests. On your internal systems, you can point your clients to an internal DNS server that has all of the known information. Outside systems would not know about this host, however, and instead would use the nameserver pointer returned by the root nameservers.
When you registered your domain with the Internet, you had to provide the IP address of a primary DNS server that would respond to public queries about nodes in your domain. Any external entity that wants to look up information about your domain will query this host. All you need to provide here is very basic information, such as "A" and "PTR" records. You could even return the same PTR data for all of the nodes, thereby protecting yourself further.
For complete security, you may want to have your Internet router or firewall block all DNS queries. Another solution may be to have your service provider publish the public DNS on your behalf.
This process is described in Separating Internal and External DNS Servers.
Implement Hierarchical Subdomains
If you've got more than one subnet, then you're going to have multiple IN-ADDR.ARPA domains. We suggest that if you have multiple departments or divisions, then you should bite the bullet and implement multiple subdomains under your primary domain as well.
For example, creating a subdomain for your accounting department makes sense if there's a few dozen nodes in that area. It makes monitoring your network—as well as applying access restrictions and security filters—much simpler. On the other hand, if you've got a small site with just a handful of nodes, then it's probably not worth the effort.
Creating subdomains is a straightforward affair. On your primary server, modify the master DNS configuration file to reference new subdomains underneath the primary. Then add new NS and A records for the subdomain's primary server in the primary domain's configuration file. In our case, we might want to implement MANHASSET.NWC.COM and SANMATEO.NWC. COM subdomains.
To implement this, we would create two new subdomain configuration files that contain the hosts in those areas and simply add NS and A records for those subdomains to the master NWC.COM configuration file. This takes less than 30 minutes, but makes monitoring the network much easier, especially when we're in a hurry.
Cross-Reference Servers
If you have multiple locations, each with their own primary nameserver for their specific subdomain, you should seriously consider making all of them secondary servers for each of the primary domains. This would allow local users at each site to obtain fast responses for any query within your organization, while simultaneously distributing the responsibility for administration of the subdomains to the distinct geographical locations.
For example, if we had a dedicated DNS server acting as the primary for the SANMATEO subdomain, we would also make the MANHASSET server a secondary of the SANMATEO server. Likewise, we would want to configure the SANMATEO server to act as a secondary for the MANHASSET subdomain. This way, we get free fault-tolerance and faster response times on queries, regardless of the location of the client.
If you want to take this concept even farther, you can modify the clients' RESOLV.CONF files so they query both servers. Then if the local primary server for their subdomain is taken out of action, they automatically will query the remote secondary, thereby allowing everything to continue functioning.
Make Every Server-Class System a Caching Server
Having multiple secondary servers in a single location is a good idea, up to a point. Then it becomes more of a management effort than the benefits justify. Keeping local copies of remote data is a great thing, however, so whenever possible, you should configure any server-class system as at least a caching-only server. This will let you reap most of the benefits outlined above, but without having to configure anything on the system beyond a simple reference to the master domain.
For example, every NetWare server on your WAN should be configured as a caching-only nameserver. Then you can point your local clients' RESOLV.CONF files to the local NetWare server. The caching-only server will issue lookups on behalf of the client and store the result in its cache for future use. Any subsequent query for the recently resolved name will be returned immediately from then on. This really makes a difference in mildly complex networks.
Put Commonly-Resolved Hosts in Top-Level Master Domain
For clients in LAB.SANMATEO.NWC.COM, there's nothing more annoying than having to type in FQDN MFS1.EDIT.MANHASSET.NWC. COM, especially when that host is queried several times a day. For this reason, you should place alias entries in the top-level master domain for any frequently queried hosts, letting users simply look up the MFS1 host regardless of where they are.
This is achieved through the use of CNAME entries in the configuration file for the NWC.COM master domain. An entry is added that simply points to the FQDN hostname of MFS1.EDIT.MANHASSET.NWC.COM. The use of the CNAME alias provides a layer of isolation from changes to the IP address of the target host itself, as the CNAME only refers to the FQDN hostname. If we added a completely new entry to the NWC.COM configuration file, we would have to make two changes if the address ever had to be modified, something we're not likely to remember to do.
Other Sources
For those of you who don't want to get this familiar with DNS, there are tools available that let you make changes without getting your hands dirty. For example, the source code for an HTML-based DNS management tool is available on the Internet at WEBDNS.LCS.MIT.EDU/cgi-bin/ webdns/listing. Written as a Common Gateway Interface-enabled Perl script optimized for Unix, it can easily be modified to support any OS with a Perl interpreter. Also, many vendors are providing graphical DNS management tools as part of their standard release. Novell has offered a character-based DNS menu system since the company's first release, and Windows NT Server 4.0 promises to include one, although it appears to be dependent upon Microsoft's proprietary WINS server structure.
Whichever platform you choose to use, DNS makes for an extremely effective lightweight directory service. It's fast, it's easy and it's a lot cheaper than off-the-shelf resource tracking products. There are many things that you cannot do with DNS that you can do with other advanced directory services such as NetWare's NDS or X.500, but it was not designed for that purpose, either. Many vendors are working on extending DNS with new resource record types, so this may not always be the case.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 1996 CMP Media, Inc. Used with permission.