Practical IP and DNS Tips
Ron Jachim In the practice of systems administration, IP addressing and naming can eat you alive. Most networks aren't planned, they just grow. Consequently, an inordinate amount of time is spent handling the bookkeeping tasks like making client end changes. Although the reason for changing the email services to a new box may be valid, the process of implementing that change can be time consuming. Similarly, modifying client IP addresses and names is a nightmare unless some controls can simplify the process. In this brief article, I present a series of tips and tricks to help you better manage your DNS. This is not a tutorial on DNS. Instead, this is more of a field guide to good practices to help you effectively use DNS to reduce your workload. You can simplify addressing and naming by using several techniques. Standard IP address ranges are used to simplify client addressing and naming. A layer of abstraction is introduced between server hardware and software services. Finally, DHCP is used to assign IP addresses to clients, so routine client details are hidden in $INCLUDE files referenced by the DNS master files. IP Numbering Conventions Because the complexity of the environment I work in was expected to increase dramatically over time, considerable thought was given to standardizing as much as possible. Although our center is a part of the University's class B network, all areas use Class C networks as the basic administrative unit. We use the last octet of the IP address for the host ID. This provides each subnet with 254 possible addresses. In each subnet, we assign those addresses as shown in Table 1. This arrangement has worked well in our environment, however, you may find that varying these numbers makes more sense for your environment. For example, an NT shop might need more addresses in the server range and fewer in the client range. The db.center.unicollege.edu file is used to keep track of all IP address assignments. In theory, if an IP address is not assigned in the master file, it is not in use and therefore available. Unfortunately, sometimes an expedient solution must be provided, and an IP address is used without making an entry in the db.center.unicollege.edu master file. This is regulated by internal policy, rather than by strict requirement. DNS Naming Conventions For network equipment, naming conventions are not particularly important. Most users do not open up telnet sessions to a given piece of network equipment. Pick something that is flexible, so it will meet your needs today and in the future. The following table is one way of doing this:
r-anything Router b-anything Bridge s-anything Switch h-anything Hub ts-anything Terminal Server d-anything DHCP Server The key to using DNS effectively is to carefully choose your server host names. We handle server naming by differentiating the pieces of hardware that services run on and the software services that run on that hardware. Each piece of hardware (Sun, Digital, IBM, SGI, etc.) is named after a character in a book. In these examples, characters from books by Sienkiewicz are used (he received the Nobel Prize in Literature in 1905). These names are used internally by the systems staff to refer to a particular piece of hardware. These names should be obscure because they are not intended for general usage. This encourages users to use the names based on the services. Once assigned, these names never change. Here are some examples of hardware DNS names:
zagloba IN A 192.168.50.20 ; HP9000 Workstation yan IN A 192.168.50.25 ; Digital Workstation helen IN A 192.168.50.30 ; IBM RS/6000 Workstation longinus IN A 192.168.50.35 ; Sun Workstation On the other hand, users refer to the services provided by a particular server. Like many networks, we provide email, DNS, NIS, file services, etc. We use DNS names to refer to servers running the services on each server based on more conventional naming scheme. By doing this, we can shift which servers provide which services relatively easily. A well-implemented change can be completely transparent to the user community. Here are some examples:
www IN CNAME zagloba ; http server int IN CNAME yan ; Intranet server mail IN CNAME zagloba ; Mail server fs1 IN CNAME yan ; One bunch of shared files fs2 IN CNAME zabloba ; Another bunch of shared files dir IN CNAME yan ; Directory server cal IN CNAME yan ; Calendar server syb IN CNAME yan ; Sybase server orc IN CNAME yan ; Oracle server nis1 IN CNAME yan ; Primary NIS server nis2 IN CNAME zagloba ; Secondary NIS server ns1 IN A 192.168.50.20 ; Primary DNS Server ns2 IN A 192.168.150.20 ; Secondary DNS Server By using CNAME records, we can point mail.center.unicollege.edu and www.center.unicollege.edu to zagloba.center.unicollege.edu. As capacity needs warrant, we can later modify this arrangement so that www.center.unicollege.edu is handled by a new server, say helen.center.unicollege.edu. Under this arrangement, each hardware server will have an A record, and each software service will have a CNAME record -- both in the DNS master file. Typically, each IP address ends up with several DNS names associated with it. Also, note that DNS name servers are never handled by CNAME records. Over the past six years, in our dynamic environment, this has worked well. And, in cases where we haven't done this, we've wished we had! Printers are named after a two- or three-letter abbreviation of the department, followed by a number (to indicate which printer), and a p for printer. For example, epi4p is the fourth Epidemiology printer. Similarly, the Community Outreach network scanner is co1s. We also standardized on naming conventions for clients. The name is based on the location of the network and the host portion of the IP address. Thus, a research client whose IP address is 192.168.150.69 is respc69.center.unicollege.edu. Because the client name to client IP address mapping never changes over time, we use include files to hide the mundane, never-changed details of the DNS master files so that things likely to be changed are not lost in the chaff. The IP names are in db.center.unicollege.edu. but for client names, we $INCLUDE the file: clients/db.center.50-clients. In short, it looks like this:
clcpc60 IN A 192.168.50.60 clcpc61 IN A 192.168.50.61 ... clcpc228 IN A 192.168.50.228 clcpc229 IN A 192.168.50.229 The IP addresses and reverse lookups are in db.192.168.50. but for client addresses, we $INCLUDE the file: clients/db.192.168.50-clients. It looks like this:
60 IN PTR clcpc60.center.unicollege.edu. 61 IN PTR clcpc61.center.unicollege.edu. ... 228 IN PTR clcpc228.center.unicollege.edu. 229 IN PTR clcpc229.center.unicollege.edu. This also simplifies the implementation of DHCP, which is used to assign all client IP addresses. We use DHCP to dynamically assign IP addresses to all clients. We use a lease time of eight days. The DHCP server assigns an IP address to the client. IP address is associated with a DNS name by the DNS server. So, the IP address and hostname always match. A lease time of eight days assures that users can take a week off without their IP address changing. However, the users almost never need their IP address for anything. A couple of sophisticated users have requirements that mandate a static IP address. Static IP addresses are also assigned by the DHCP. Conclusion There are two main drawbacks to the approach to DNS shown here. In the server area, there is additional complexity because each important server has at least two names, and possibly several more. This permits shifting of software services based on projected usage. In the client area, there is additional overhead because there are always 170 client IP names defined, even if your subnet currently has two PCs on it. On the flip side, any PC tech can add a new PC to the network, without bothering you or crashing your DNS because of a mistake. In my opinion, the extra systems administration overhead is a small price to pay for the flexibility provided by the methods described here. While the systems administrators are impacted more up front, the support issues will decrease over a short time.
About the Author
Ron Jachim is Manager of Systems for the Barbara Ann Karmanos Cancer Institute where he is responsible for the systems half of the Information Systems Group. He has fifteen years of networking experience and both a B.A. and an M.S. in Computer Science. His thesis was on fuzzy queries. He can be reached at: rjachim@acm.org.
|