Cover V09, I01
Table 1


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 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 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    ; HP9000 Workstation
yan        IN    A    ; Digital Workstation
helen      IN    A    ; IBM RS/6000 Workstation
longinus   IN    A    ; 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    ; Primary DNS Server
ns2    IN    A   ; Secondary DNS Server

By using CNAME records, we can point and to As capacity needs warrant, we can later modify this arrangement so that is handled by a new server, say 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 is 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 but for client names, we $INCLUDE the file: clients/ In short, it looks like this:

clcpc60        IN    A
clcpc61        IN    A
clcpc228       IN    A
clcpc229       IN    A

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
61    IN    PTR
228    IN    PTR
229    IN    PTR

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.


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: