The Domain Name System
Fairly early on, people realized that addresses were fine for machines communicating with machines, but humans preferred names. It is hard to talk using addresses (who would say, "I was connected to 126.96.36.199 yesterday and... "?), and even harder to remember them. Therefore, computers on the Internet were given names for the convenience of their human users, The preceding conversation becomes " was connected to the NIC* yesterday and... ". All of the Internet applications let you use system names, rather than host addresses.
Of course, naming introduces problems of its own. For one thing, you have to make sure that no two computers that are connected to the Internet have the same name. You also have to provide a way to convert names into numeric addresses. After all, names are just fine for people; but the computers really prefer numbers, thank you. You can give a program, a name, but it needs some way to look that name up and convert it into an address. (You do the same thing whenever you look someone up in the phone book.)
In the beginning, when the Internet was a small folksy place, dealing with names was easy. The NIC (Network Information Center) set up a registry. You would send in a form, electronically of course, and they would maintain a file of names and addresses. This file, called the hosts file, was distributed regularly to every machine on the network. The names were simple words, every one chosen to be unique. If you used a name, your computer would look it up in the file and substitute the address. It was good.
Unfortunately, when the Internet went forth and multiplied, so did the size of the file. There were significant delays in getting a name registered, and it became difficult to find names that weren't already used. Also, too much network time was spent distributing this large file to every machine contained in it. It was obvious that a distributed, online system was required to cope with the rate of change. This system is called the Domain Name System or DNS.
The Domain System Structure
The Domain Name System is a method to administer names by giving different groups responsibility for subsets of the names. Each level in this system is called a domain. The domains are separated by periods:
There can be a variable number of domains within the name but practically there are usually five or less. As you proceed left to right through the domains, the number of names contained in the group gets bigger.
In the first line above (ux.cso.uiuc.edu), ux is the name of a host, a real computer with an IP address (Figure 3-4). The name for that computer is created and maintained by the cso group, which happens to be the department where the computer resides. The department cso is a part of the University of Illinois at Urbana Champaign (uiuc). uiuc is a portion of the national group of educational institutions (edu). So the zone edu contains all computers in all U.S. educational institutions; the zone uiuc.edu contains all computers at the University of Illinois; and so on.
*A Network Information Center is a repository for information about A network.
Figure 3-4: Domain autborily
Each group can create or change whatever lies within it. If uiuc decided to create another group called ncsa, it could do so without asking anyone's permission. All it has to do is add the new names to its part of the worldwide database, and sooner or later everyone who needs to know will find out about the new name. Similarly, Cso can buy a new computer, assign it a name, and add it to the network without asking anyone's permission. if every group from edu on down plays by the rules and makes sure that the names it assigns are unique, then no two systems anywhere on the Internet will have the same name. You could have two machines named fred, but only if they are in different domains (for example, fred.cso.uiuc.edu and fred.ora.com).
In practice, being the name administrator for a group requires certain skills, and is not fun. Therefore, at some level around the enterprise level MUC) or one level below it, there is a person who is responsible for maintaining all lower levels. There is some locally defined procedure for requesting that a name get created or changed.
It's easy to see where domains and names come from within an organization like a university or a business. However, where do the "top level" domains like edu come from? They were created by fiat when the domain system was invented. Originally, there were six highest level domains (see Table 3-1).
Table 3-1: Original Higb-level Domains
As the Internet was a worldwide network, there needed to be a way to give foreign countries responsibility for their own names. To this end, there are a set of two letter domains which correspond to the highest level domains for countries. Since ca is the country code for Canada~ a Canadian computer might be named:
There are almost 300 country codes, about 100 of which have some kind of computer networking. There is a list of the country codes in Appendix B, International Network Connectivity, in case you want to see where mail you received came from.
It's worth noting that the U.S. has its own country code, although it isn't used too often; in the U.S., most network sites use the "organizational" domains (like edu), rather than the "geographical" domains (like va.us-Virginia). However, you will see both kinds of names. One computer may even have both kinds of names just for completeness. There's no way to "convert" between organizational names and geographical names. For example, even though uxc.cso.uiuc.edu happens to be in Urbana, Illinois, U.S.A., there is not necessarily a name uxc.urbana.il.us. Even if there is, they aren't necessarily the same computer.
Domain Name Lookup
Now you know how domains relate to each other and how a name gets created. Now you might just wonder how to use this marvelous system. You use it automatically, whenever you use a name on a computer that knows about it. You never need to look a name up "by hand," or give some special command to find out about some name, although you can if you want. All computers on the Internet can use the domain system, and most do.
When you use a name like ux.cso.uiuc.edu, the computer needs to turn it into an address. To do so, it starts asking DNS servers for help, starting at the right end and working left, First, it asks the local DNS servers to look up the address. At this point, there are three possibilities-,
The local server knows the address, because the address is in the local server's part of the worldwide database. For example, if you're in the computer science department of the University of Illinois, your local server probably has information about the computers in your department.
The local server knows the address because someone else has asked for the same address recently. Whenever you ask for an address, the DNS server keeps it on hand for a while, just in case someone else wants the same address later; this makes the system a lot more efficient.
The local server doesn't know the address, but it knows how to find out.
How does the local server find out? Its software knows how to contact a root server. This is the server that knows the addresses of name servers for the highest level (rightmost) zone (edu). It asks the root server for the address of the computer responsible for the edu zone. Having that information, it contacts that server and asks that server for the address of the uiuc server. Your software then contacts that computer and asks for the address of the server for cso. Finally, it contacts that machine and gets the address of ux, the host that was the target of the application.
A few computers are still configured to use the old-style bosts file. If you find yourself on one of these, you may have to ask its administrator to look up the address you need by hand (or look it up yourself); then the administrator will have to add the machine you want to contact to the local bosts file. While you're doing this, you can hint that the administrator really ougbt to install the DNS software so you won't have to do this again.
Domain Name System Hints
There are a few common misconceptions that you may encounter dealing with names. Here are a few we can dispel now:
The pieces of a domain-style name tell you who is responsible for maintaining the name. It may not tell you anything about who maintains the computer corresponding to that IP address, or even (despite the country codes). where that machine is located. It would be perfectly legal for me to have the name oz.cso.uiuc.edu (part of the University of Illinois' name space) point to a machine in Australia. it isn't normally done, but it could be.
The pieces of a domain name don't even necessarily tell you what network a computer is located on. Domain names and networking often overlap, but there's no necessary connection between them; two machines in the same domain may not be on the same network. For example, the systems uxc.cso.uiuc.edu and ux1.csouiuc.edu may be on different networks. Once again, domain names only tell you who is responsible for the domain.
A machine can have multiple names. This is especially true of machines that offer services, where the service may be moved to a different computer in the future. My Sun workstation may be known by ek.cso.uiuc.edu. It also might be the computer where you can go to get publicly available files at the University of Illinois. So it might also have the name ftp.uiuc.edu (ftp being the name of the file moving program). Some time in the future, this service might be moved to some other computer. When this happens, the name ftp.uiuc.edu would move along with the service (my computer gets to keep its old name ek.cso.uiuc.edu). People wanting the particular service use the same name regardless of which computer is providing the service. Names that symbolically refer to a service are called "canonical names" or cnames. You will see them frequently as you wander about the Internet.
Names aren't necessary for communication. Unless the error message you receive is "host unknown," the name worked fine. A message like "host unknown" means your system could not translate the name you gave into an address. Once your system has the address in hand, it never uses the name again.
It is better to remember names than addresses. Some people feel that the name system is "just one more thing to go wrong," The problem is that an address is tied to a network. If the computer providing a service is moved from one building to another, its network and hence its address will likely change. The name needn't change. When the administrator assigns the new address, he only needs to update the name record so that the name points to the new address. Since the name still works, you don't particularly care if the computer or function has changed locations.
The Domain Name System may sound complicated, but it's one of the things that make the Internet a comfortable place to live. If you doWt like the periods wandering around, forget about what they mean: they're just names. However, pretty soon you'll start realizing, "yes, this resource is at the University of Virginia; this person works for IBM in Germany; this is the address for reporting bugs in Nutshell Handbooks (firstname.lastname@example.org)" and so on. The real advantage of the domain system is that it breaks the gigantic worldwide Internet into a bunch of manageable pieces. Although hundreds of thousands of computers are "on the Net," they're all named; and the names are organized in a convenient, perhaps even rational way, making it easier for you to remember the ones you need.