iWorld Web Site Newsstand Trade Shows Advertising Rates and Information Corporate Information Search Page Subscription Information
Internet.com IW Online IW Online toolbar Mecklermedia toolbar



Protecting Your Name

How to become the master of your domain.

By Joel Snyder

A friend called me the other day: His Internet service provider was offline and no one could tell him when it would be up and running again. The problem is that my friend is a Web developer with about 50 clients on the now-disabled ISP. So not only was he dead in the water, but 50 businesses that depended on him for their Internet presence were suddenly shut down as well.

After several hours of searching, he managed to find another ISP with a compatible server and subsequently loaded his clients' pages from a backup copy. Unfortunately, that did little good. The pages were on a new server, but with the existing URLs still pointing to the old ISP's dead servers, no one could access them.

The problem was that when he set up the Web sites for his clients, he had been lazy and let the now-defunct--and equally lazy--ISP handle registering the DNS names of the sites with the InterNIC. And, because of this, nothing worked.

How DNS works

To understand what happened and why, let me give you a little background on DNS, the domain name system. DNS is used to translate names, like http://www.opus1.com, into TCP/IP addresses, such as (Actually, the DNS contains additional information besides TCP/IP addresses, but for the purposes of this discussion, that doesn't matter.)

When you move packets of data from one computer, such as a workstation, to another computer--say, an e-mail server--this is accomplished by using numeric TCP/IP addresses. DNS names are just for the convenience of people who don't want to memorize numbers. These names are used throughout the Internet. They are present in URLs, e-mail addresses, and configuration files everywhere.

When an application such as an e-mail package or Web browser needs to make a connection across the Internet, it asks the DNS to translate the name into a TCP/IP address. Once the application has this address--and not before--it can set up a connection and complete its assigned task, such as download a Web page, retrieve your e-mail, or find out the time of day.

The DNS is a tree-structured hierarchical system. All information in the DNS is stored in systems called name servers, and there are countless thousands of these servers in existence. You probably don't know this, but at the end of every DNS name is an implicit dot, just like the dots that separate parts of the names. Thus, "iw.com" is really "iw.com." inside the DNS. That final dot is called the root, which is at the top of the DNS tree.

There are a small number of name servers that are responsible for the root of the DNS tree called, strangely enough, "root name servers." Translating names means starting at the root and working your way down.

For example, let's suppose you wanted to read the Web pages at http://www.opus1.com . First, your browser would ask a nearby name server for the IP address for www.opus1.com. The name server would then go to one of the root servers and work its way down from the root to a .com name server, then to an opus1.com name server until it found the complete address.

The reliability of name service is crucial to the operation of the Internet. That's why there are over a dozen root servers. In fact, name service is so important that when you register a domain, you are (usually) required to have at least two name servers for that domain. So when my company set up opus1.com with the InterNIC, we had to find two name servers to handle the opus1.com name service (and any names under that, such as www.opus1.com).Two is actually just a minimum; some domains have more than that. The InterNIC is responsible for coordinating DNS for the biggest top-level domains: .com, .org, .net, .edu; other organizations are responsible for the rest.

When you add a new domain name to the Internet, the name service database in your top-level domain (for example, .com or .uk) is updated to add information about the new names. Now, programs can start at the root and work their way down to find out where the name servers for your domain are. This update generally happens once a day, although it can take more than 24 hours for the update to completely propagate across the Internet.

A Tale of Two Servers

This is where my friend's ISP got lazy. When setting up the two name servers for each of his clients, the ISP used two of their own systems. These computers were, figuratively and literally, right next to each other. Why? Because it was convenient. Both systems were owned and operated by the ISP and it was easier to keep them updated as the DNS changed. However, what was good for the ISP turned out to be a disaster for my friend. This configuration ensured that when the ISP crashed, both name servers for the domain went down with it.

Since moving the data to another ISP did not solve the problem, the only solution was to contact the InterNIC directly and get it to change the addresses of the name servers.

Fortunately, the InterNIC is happy to do this. In fact, it even has an automated procedure so that you can have it done via e-mail. However, this method depends on your e-mail working from and to a particular address, called the Administrative Point of Contact (POC), for each domain. And in this case, the Administrative POC for each domain was--you guessed it--on the dead ISP.

To get his clients back online, my friend had to phone the InterNIC and plead with them to change the root servers. The NIC folks were pretty nice about it. Normally, when the Administrative POC for a domain can't send an e-mail message, a request sent via fax on company letterhead is required. In this case, the InterNIC didn't make him do that, and his clients were up and running in a matter of days.

DNS survival tips

To keep your own Internet presence safe and sound, you need to know two things: who your Administrative POC is, and where your name servers are.

If your domain name ends with .com, .org, .net, or .edu, the InterNIC maintains all of this information and makes it available to you through the Whois database (named after the original command used to query the database). If your domain name ends with something else, ask your ISP which registrar is responsible for it.

Start by getting your Whois record with the Whois command (if your workstation has one). If you're Whois-deprived, you can use a form that the InterNIC has put up for this purpose at http://rs.internic.net/cgi-bin/whois.

The InterNIC only registers second-level domain names, so if you are using something like www.opus1.com, you should just ask for opus1.com. The Whois command would be "whois dom opus1.com." If you are using the InterNIC Web page, just type in "opus1.com."

Once you retrieve your record, look for the Administrative POC. This is your most important contact. The Administrative POC is the person who "owns" the domain name. This should be someone in your company--many ISPs simply put themselves in as the Administrative POC, but this puts you in the awkward position of having your own domain name owned by someone else.

Next, make sure the e-mail address for the Administrative POC is correct--one you can use to both send and receive e-mail. If the domain was set up a long time ago by a person who is no longer around, or if any of the address information is outdated or incorrect, take care of these discrepancies immediately.

You will also find Technical and Billing POCs. The Technical POC is usually the person who is in charge of your DNS, which may be your ISP or, if you run your own DNS, someone from your organization. Similarly, the Billing POC is the person who is supposed to pay the InterNIC's bill for your domain name. Generally, an ISP will do this for you and simply add it to your annual service charge.

The next step is to figure out where your DNS servers are located--their names and IP addresses are also in your InterNIC record. The easiest way, of course, is asking your ISP. Have whoever provides your name servers confirm that your DNS servers are housed in different buildings, on separate networks, each with their own independent, high-speed connection to the Internet, and each controlled by a different company. That way, if you wake up one morning to find your ISP completely dead, you've still got a hope of keeping your Internet presence alive.

Verify that you have at least two name servers and ask whoever provides DNS service for you to confirm that both are up and running and providing authoritative answers to name service queries. Two servers should be enough; more than that is unlikely to bring you much benefit if they've been properly placed.

You can check up on your ISP by using Traceroute http://www.opus1.com/www/traceroute.html) to check that the path to the two servers is different.

One thing to keep in mind is that each of the servers for your domain name is a peer in offering name service. That means that each has to have the connectivity and capacity to answer all queries about your domain name.

You may hear the terms "primary" and "secondary" bandied about. These are used to describe the database relationship between your name servers: One is the master (the primary) and the others are slaves (the secondaries) which transfer information about your domain periodically. If you ever hear someone call these "backup" servers, get out of there as soon as possible: You're talking to someone who doesn't understand DNS at all.

As simple as these steps are, many businesses have either incorrect information in the Whois database or poorly situated name servers. Spending a little time in setting up the proper system now can save you a lot of anguish later on.

Joel Snyder is a senior partner at Opus One, an IT services firm in Tucson, Ariz.

Reprinted from Internet World magazine Vol. 8 No. 10, (c) 1997 Mecklermedia Corporation. All rights reserved.