Novell is now a part of Micro Focus

Implementing DNS/DHCP @ Novell

Novell Cool Solutions: Feature
By Grettir Asmundarson

Digg This - Slashdot This

Posted: 1 Sep 1999

What's In A Name?

Names can provide us with insights into the purpose or nature of things and people. For instance, a company with a name like Lucent Technologies automatically benefits from the images conjured up by the word "lucent": clarity, luminescence, etc. elicits images of a vast river of knowledge, full of mystery and wonders to be discovered. Cisco benefits from being named after any of a variety of whitefish (genus Coregonus); especially Lake Herring. And Intel combined the words "celery" (an edible plant in the parsley family) and "Oberon" (the fairy king in Shakespeare's A Midsummer Night's Dream) to come up with Celeron, "The Bard's Relish Plate" of microprocessors.

Naming also has profound psychological importance. In The Psychological Attitude of Early Buddhist Philosophy, Anagarika B. Govinda wrote, "?things that could be named had lost their secret power over man, the horror of the unknown. To know the name of a force, a being or an object was (to primitive man) identical with the mastery over it."

A Rose By Any Other Name?

And naming is becoming even more important with NetWare 5. In the IPX world, you could afford to be lazy. If you wanted to attach to a particular server, you didn't need to know where that server was located, its IP address, its domain, or the NDS context in which the server resided. You could simply refer to the server by its short name. The same is not true in the world of Pure IP. In a Pure IP environment, naming (something you never really had to think about before) suddenly becomes a big issue. Because...

"A rose by any other name?
would have a different IP address."
- Grettir Asmundarson

With NetWare 5, any number of "names" can refer to the same server. If I want to use the Novell GUI Map utility to map a drive to the server that I have here at my desk, what "name" should I use?

Fully-Qualified DNS Name


Fully-Qualified NDS Name


Short Name


IP Address


DNS: The Namespace Of The Rose

Here @ Novell, we've standardized on fully-qualified DNS names. Why? Because DNS is the only naming standard that will work no matter where I am. Whether I'm mapping a drive locally, via a VPN client across the Internet, or dialing in with RADIUS, fully-qualified DNS names work everywhere. And if I ever have to change the IP address of the server, I simply point the DNS entry to the new IP address and everyone's still working.

DNS makes the TCP/IP world a much nicer place because it allows you to refer to things by user-friendly DNS name ( rather than obscure IP address ( It also allows us organize things into logical, geographic subnets that are easily understandable to the average user. For instance, our three main sites in the U.S. are:


DNS Subnet Name

Provo, Utah

Orem, Utah

San Jose, California

We've also standardized the DNS names of particular servers and/or services at most sites. For instance:

DNS Entry

Record Type



MX record for site. to reference GroupWise IP connection.


Site DNS Server


Site Newsgroup/Collaboration Server


HTTP and FTP Proxy/Cache Server


Site Web Werver


Site Directory Agent



Site Migration Agent



Site Post Office Agent



Site GroupWise WebAccess Service

Standardizing names allows us to cheat by configuring clients in shorthand. For instance, we configure all browsers with the hostname "proxy" as the proxy server. We could hard code all of the browsers in Provo to use "" but that means that if you go to Hong Kong and forget to reconfigure your browser, you'd be pulling information from a proxy server across a 56k WAN link, which sort of defeats the purpose. By simply specifying the hostname "proxy," the client will append your DHCP-assigned sub-domain name to that hostname to come up with the fully-qualified DNS name. For instance, if you were in Hong Kong, the hostname "proxy" along with the DHCP-assigned domain name "" would become "" which just happens to be the name of the local proxy server.

DHCP: Automatically Keeping Your Ducks In Rows

Anyone who has had to manage IP addresses on a large scale should already be familiar with the sanity-saving benefits of DHCP. But DHCP is especially useful with NetWare 5 because it not only simplifies the assignment and administration of client IP addresses, it also allows you to hand out Novell client configuration information such as Preferred Tree, Preferred Server, Directory and Migration Agent addresses, etc.

We have at least one DHCP server running at each site. At our major sites we use two servers (for redundancy) and split the available range of IP addresses between the two. And at those sites with multiple segments, we use forwarding to route DHCP packets to a local DHCP server.

In addition to the IP address, local DNS servers, and local subnet (, we also hand out the following NDS information via DHCP:

DHCP Option #

DHCP Option Name



NDS Servers

The addresses of at least two servers that contain replicas to which the user can connect to log in.


NDS Tree Name

"Novell_Inc," in our case?

This allows me to fly out to Des Moines, plug my notebook in, and automatically be off and running without having to piddle around with my IP settings or Novell Client configuration.

Lease times are one aspect of DHCP that we're still tweaking. By default we have an 8 hour lease time, with renew times at 50% and 85%. This means that a workstation's DHCP address is good for at least 8 hours. After 50% of that time (4 hours) the workstation will go out and renew the lease if it can. If the workstation hasn't been able to renew the lease with the original DHCP server after 85% of the lease time has expired, it will start broadcasting for another DHCP server.

This hasn't worked for some people who expect to have the same IP address when they come back every day. In some areas of Development and Testing, where a semi-static IP address is a Very Useful Thing, we've set the lease times anywhere from 21 to 25 hours. So, we're still experimenting with the right balance of convenience for the user vs. ease of administration.

Dynamic DNS: Updating The Name Of The Rose

We use Dynamic DNS to automatically create a DNS entry for a device when it is assigned an IP address from a DHCP server. We separate our static DNS entries from our dynamic ones by putting them in different DNS domains. We keep all of our devices with static addresses in the "" domain, while our Dynamic DNS entries are kept in the "" domain. This logically separates the company-wide, static devices from the local, dynamic devices and generally keeps things tidy.

We use the name of the workstation when creating the Dynamic DNS entry. For example, let's say that a person has a workstation named "BabeMagnet." When a Dynamic DNS entry is created for that workstation it would be ""

Another nice aspect of dynamic DNS is that I never really need to know the IP address of my workstation. Since the name of my notebook is "Ananas," I know that my workstation can always be found at ""

DNS & NDS: How Does Your Rose Garden Grow?

Exponentially. Implementing DNS/DHCP can add an enormous number of objects into your tree. If you were to set up your entire Class B address (approx. 65,000 addresses), once you got done with all of the in-addr.arpas, you could have well over 200,000 new objects in your tree. And if you're using Dynamic DNS those objects can get updated quite often. So if you want to optimize your NDS synchronization, you might want to seriously consider segregating DNS/DHCP data from the rest of your NDS data.

Here at Novell, we create a DNSDHCP container below every site container and create both DNS and DHCP containers under that. Like this:

We partition the DNS/DHCP data off in their own containers, with their own replication ring dedicated solely to DNS/DHCP. That way the synchronization of regular NDS data doesn't get bogged down if 10,000 workstations all decide to release and renew their DHCP-assigned addresses at the same time.

If you're particularly anal-retentive about having a tidy tree, you could even deploy DNS/DHCP in its own separate tree. There are obviously disadvantages to this (additional hardware requirements, maintaining two, separate administrator accounts in both trees, etc.), but it's an option.

We've delegated DNS/DHCP management to administrators in the various regions around the world, but we've only given them rights to manage their own particular regions. This is a good idea in general when it comes to DNS and, with our configuration, there's little reason that the administrator in Singapore would need to change the DNS entry of the Web server at the Chicago office.

And speaking of regional administration, keep in mind that when you start the DNS/DHCP Management Console, it reads all of the sites in the locator object and then goes to each of those sites to see if you have the necessary rights to manage those objects. Needless to say, at remote sites with slow links, this can take a while. Remote administrators should take advantage of the "-s" command line option of the Management Console in order to limit the scope of the search. For instance, an administrator in Sydney can use a "-s asia-pac.novell" command line option to limit the search to only those objects in the "asia-pac.novell" container.


Nothing in this beigepaper represents original thought on my part. I couldn't have written a word without the generous help and input from everyone in Novell's IS&T Global Technical Architecture group. (I'd name them all individually but they'd probably get spammed.)

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates