Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

This is the complement of broadcast name registration, of course. It too can only be used in

simple systems where every device can hear a broadcast. The use of broadcasts also

makes it wasteful of network bandwidth.

Client/Server Name Resolution

Servers are programmed with software that allows them to respond to name resolution

requests sent by clients. These servers take the name in the request, look up the

associated numeric identifier in a database, and send it back in a response.

This technique is, of course, generally used in conjunction with database name registration.

It is the most complex of name resolution methods, but is also the most efficient, and the

only one that can really work properly on a large, distributed hierarchical name system.

Client/Server Resolution Functional Elements

The last of these three methods is the one used for most large, modern name systems. The

client/server method of request/reply resolution is similar to how many other protocols

function. One thing that is unique about name resolution, however, is that name resolution

isn't often invoked directly by the client. It's rare, for example, for a human user to say

“please resolve the following name”. We also certainly wouldn't want a user to have to

manually resolve a name to an address each time they wished to contact a device, as this

would be cumbersome.

Instead, the system is automated by having software accept machine names input by

users. The software resolves the name by passing it to a name resolver software

component. The resolver acts as the client in the name resolution process. It contacts a

name server, which responds to the request. The name resolver and name server

constitute the two main functional elements in name resolution.

In a distributed database for a hierarchical name system, multiple requests may be

required, since name servers will contain only information for certain machines and not

others. Resolvers follow a special procedure to “travel” the hierarchy until they find the

server that has the information they want. Again, TCP/IP's Domain Name System (DNS)

name resolution is the best example of this method.

Key Concept: Name resolution is arguably the most important of the main functional

elements of a name system, because it is the part of the system that actually

converts names into addresses. The two main components of name resolution are

name resolvers, which act as clients in the resolution process, and name servers. The three

main name resolution methods—table-based, broadcast and client/server—correspond

closely to the table, broadcast and database methods of name registration.

Efficiency, Reliability and Other Name Resolution Issues and

Features

In the preceding topic I described the primary function of name resolution: allowing humans

to identify devices using names, then converting these names into numbers so that

computers can use the numbers instead. This basic task is conceptually quite simple, but it

can become quite complex in implementation. The reason for this is the key characteristic

that makes name resolution so different from the other tasks performed by a name system:

the frequency with which it is done.

Name registration is seldom done, but name resolution is done very often. If you consider a

large internetwork with thousands of users running various applications, millions of names

must be resolved every day. Now, consider something like the Internet, which must process

billions of client/server requests and replies daily! Ensuring that such systems work requires

that we do more than just implement a resolution process; we must add facilities to ensure

that resolution is done as effectively as possible.

Efficiency Considerations

The first major concern with name resolution is efficiency. Name resolution uses up system

resources, especially with resolution techniques that require requests and replies to be

sent. This means we want to minimize the number of times resolution is performed, if at all

possible. Now, consider that many people will frequently access the same machines over

and over again. For example, if you go to a Web site called “www.thisisasite.com” for the

first time, your system will need to resolve that name. After the home page for that site

loads, if you click a link to another page on that site, the page will also be found at that same

name: “www.thisisasite.com”. It would be wasteful to then have to resolve the name a

second time.

To avoid this, name systems almost always include some sort of caching capability, which

allows devices to remember recent name resolutions and retain the mapping from name to

address for a period of time. Whenever a name needs to be resolved, the cache is first

checked before going through the formal process of resolution. The use of caching elimi-

nates the vast majority of actual name resolution requests that would otherwise be required.

The drawback of caching is that it requires some system resources of its own, and that it

adds complexity to the system. One issue is deciding how long to retain data in the cache; if

we keep it too short a time, we generate extra unnecessary resolution requests; keep it too

long, and we risk having the mapping become “stale” if the name assignment for the

machine changes. These are issues that a sophisticated name system must deal with. A

typical solution is to allow each name registration to specify how long information about that

name-to-address link may be cached.

Reliability Considerations

The main concern with name resolution after efficiency is reliability. As I said earlier in the

section, having a name system isn't strictly necessary for the computers, but it's very

important for the users, especially on a large network like the Internet. While having a single

central place that maintains all information about a name system may make administration

simpler, it creates a dangerous “single point of failure”. If anything happens to the device

storing the information, the entire name system fails.

Modern name systems employ redundancies to prevent having the entire system rely on

any particular device for resolution. A typical approach in a client/server system is to have

multiple servers in different locations (or attached to different networks) that can respond to

name resolution requests.

Key Concept: Since name resolution is the part of a name system that is used most

often, it is here that we must pay careful attention to implementation issues. The two

most important ones are efficiency and reliability. Efficiency is essential due to the

many thousands or millions of resolutions performed every day on a large system; reliability

is a consideration because users of the name system quickly come to rely on it and we

must make sure it is robust.

Other Considerations

An optional feature in some name resolution systems is load balancing. When properly

implemented, load balancing allows a single name to map to more than one underlying

address. This allows requests sent to a particular “virtual” device to actually be directed to a

number of different actual physical devices, spreading the load over multiple machines. A

common use of this feature is for very popular, heavily-trafficked Web sites.

Finally, while name resolution is obviously designed to allow names to be mapped into

addresses, there are cases where we may wish to go in the other direction: given a numeric

address, find the name that goes with it. This process, called reverse resolution, is

analogous to having a phone number and trying to find the name of the person or company

to which it belongs. Just as we can't easily find the name matching a phone number using a

conventional phone book (we'd have to scan every page looking for the number), reverse

resolution requires special support on the part of the name system. This is especially true if

the name system data is distributed over many servers.

TCP/IP Name Systems: Host Tables and Domain Name System

(DNS)

The TCP/IP protocol suite is the most widely used in networking today. TCP/IP has become

sufficiently popular that many people—even non-geeks!—are fairly comfortable working

with its numeric identifiers (IP addresses). Even so, it's a lot easier to work with names than

numbers, and it's certainly easier to remember them. We can consider also that name

systems become more important when used on larger networks than smaller ones, and that

TCP/IP is used to implement the Internet, the world's largest internetwork. Having a good

name system is vital to the operation of the Internet, and thus, has become an important

element of TCP/IP as a whole.

In this section I describe the name systems used in TCP/IP. I begin with an overview of

device naming in TCP/IP, including a discussion of the history of how device naming began.

I then describe the two different name systems that have been used in TCP/IP: the simple

host table name system, and the modern Domain Name System (DNS). Far more detail is

included on the latter than the former, since DNS is both much more complex than host

tables, and also more widely used in today's networks.

Background Information: This section assumes that you are already familiar with

the general concepts and issues of name systems explained in the preceding

section. Reference is made to descriptions of name system components and

methods where appropriate.

Overview and History of TCP/IP Host Names and Name Systems

In the section that introduces name systems and describes the concepts behind them, I

described an interesting paradox. Even though name systems aren't strictly necessary for

the functioning of a networking system, they make using a network so much easier for

people that they are considered an essential part of most networks. I think no better

evidence of this can be found than the history of name system development in TCP/IP.

Early Use of Host Names on the ARPAnet

In fact, the history of name systems in the TCP/IP protocol suite actually goes back well

before TCP and IP were themselves even created! In the late 1960s and early 1970s, when

the predecessor of the Internet (the ARPAnet) was being developed, it used older

networking protocols that served the same function that TCP and IP do today. The ARPAnet

was very small by today's standard, containing at first only a few machines, called hosts just

as TCP/IP machines often are today. The addressing scheme was also very simple: just the

combination of an IMP (computer) number and a port number for each host.

With only a handful of machines names it was easy to memorize addresses, but as the

ARPAnet grew to several dozen machines this became untenable. As early as 1971, it was

apparent to the engineers designing the ARPAnet that symbolic names were much easier

for everyone to work with than numeric addresses. They began to assign simple host

names to each of the devices on the network. Each site managed its own host table that

listed the mappings of names to addresses.

The First ARPAnet Name System: Host Name Lists

Naturally, the ARPAnet engineers immediately recognized the dangers of having each site

maintain a list of possibly inconsistent host names. Since the internetwork was just a small

“club” at this point, they used the RFC process itself to document standard host name to

address mappings. RFC 226, Standardization Of Host Mnemonics, is the first RFC I could

find showing how host names were assigned. It was published on September 20, 1971.

This initial name system was about as manual as a system could be. As additions and

changes were made to the network, the list of host names was updated in a new RFC,

leading to a series of RFCs being published in the 1970s. Each host administrator still

maintained his or her own host table, which was updated when a new RFC was published.

During this time, the structure of host names was still under discussion and changes were

made to just about every aspect of the name system as new ideas were explored and

refined.

This worked fine while the ARPAnet was very small, but had many problems. One was that

it was extremely slow in responding to network modifications; additions or changes would

only be entered into device tables after a new list was published. Even with the centralized

list, there were also still potential consistency issues, if a site manager forgot to update a file

or made a typographical error. These were in addition to the usual limitations of a host-

table-based name system.

Storing Host Names in a Host Table File

The first improvement was to make the list of host name assignments a standard “master”

text file that would be centrally managed and could be downloaded using network protocols

like FTP. The file was maintained at the Network Information Center (NIC) at Stanford

University. The process for defining and using this file was described in RFCs 606 and 608,

both entitled Host Names On-line, published in December 1973 and January 1974 respec-

tively. These documents also formally specified the syntax for the TCP/IP host table name

system.

The use of a centrally-managed host table continued through the 1970s. When TCP/IP was

developed the system was maintained, and mappings made between host names and 32-

bit IP addresses. RFC 810, DoD Internet Host Table Specification

, shows how host tables

were defined for use with IP addresses. It was published in 1982.

Outgrowing the Host Table Name System and the Transition to DNS

It was at around this same time that continued growth of the ARPAnet/Internet made it

apparent that the simple host table name system would eventually become unmanageable.

With at first dozens and then soon hundreds and thousands of new hosts connecting to the

internetwork, a single text file maintained in a central location just wasn't up to the task, for

a variety of reasons.

The idea of moving to a hierarchical name system based on the concept of domains was

first introduced in 1981 in RFC 799, Internet Name Domains

. Considerable discussion and

development of this concept occurred in the early 1980s, and by 1983 a plan was put in

place to migrate from the flat host table name system to the new Domain Name System

(DNS). The detailed history of the development of this name system is continued in the

overview section on DNS.

TCP/IP Host Table Name System

The pioneers of the modern Internet made the first name system for the suite when they

created simple files containing the names and addresses of the machines in the early

ARPAnet. This system was so simple that it originally wasn't even formally specified as a

“name system” per se. Since the files contained names for network hosts, the process for

relating names to addresses was simply called the “host name” mechanism. Later, these

files were called host tables, and for this reason I call this technology the TCP/IP host table

name system.

As a system, it is extremely simple, since it consists of nothing more than a text file

maintained on each machine on the network. This file is normally called “/etc/hosts” on a

UNIX system, or HOSTS on a Windows system (usually residing in the main Windows

directory). The file usually begins with some comment lines and then lists pairs of IP

addresses and host names. A very simplified example (using the modern table structure,

which is slightly different than the original host table format) is shown in Table 162.

Host Table Name Space

The name space and architecture for this system is theoretically flat, with each name being

able to take any form without any real structure. Despite this, certain rules were eventually

put in place regarding how names should be created, for consistency. As we will see later in

this topic, it's also possible to use host tables to support the implementation of a hierarchical

name space, which would obviously mean the names would have to be created using that

name space’s structural rules.

Host Table Name Resolution

Name resolution in this system is very simple. Each device reads the host table into

memory when it starts up. Users of the system can make reference to the names in that

host table in their invocation of various applications, by using a name instead of a numeric

IP address. When the software detects a name has been used in this manner, it refers the

Table 162: Example TCP/IP Host Table

# Host Database

# This file should contain the addresses and aliases

# for local hosts that share this file.

# Each line should take the form:

# <address> <host name>

127.0.0.1 localhost

209.68.14.80 www.pcguide.com

216.92.177.143 www.desktopscenes.com

198.175.98.64 ftp.intel.com

name to the internal resolver routine in the device, which looks up the name in the host

table in memory and returns its address. There is no need for any transmissions or servers

to be contacted; resolution is entirely local.

Host Table Name Registration

Now, here is the part where I am supposed to say that name registration in the host table

name system is simple as well, right? Well, yes and no. From a purely technical standpoint

it certainly is: a name is “registered” on a particular device when the name and corre-

sponding IP address is entered into the device's host table, and that's it.

However, name registration is much more complicated from an administrative standpoint,

and this is in fact where we find the major weakness of using host tables. Each network

device maintains its own host table independent of the others, usually stored as a file on its

local hard disk. This is in contrast to database registration systems where the data is

centrally stored and managed. This leads to two very important concerns:

☯ Consistency: Since every device has its own host table, how do we ensure that infor-

mation is consistent between all the tables on the different devices?

☯ Modifications: How do we ensure that information about new device mappings, or

changes to existing ones, is propagated to all devices?

The original mechanism for this was simply hand-editing, with administrators consulting

updated published lists of device names. This was a very inefficient method that was prone

to error and slow to acknowledge changes to the network. The revised system used a

centrally-managed “master” file that was downloaded by all sites on a regular basis. Name

registration in this method required that the name/address mapping be submitted to the

authority managing the central file, the Network Information Center (NIC).

Weaknesses of the Host Table Name System

The use of a centralized master file for name registration certainly worked better than using

the equivalent of “inter-office memos” to publish host name lists, but was itself only practical

in the early days of TCP/IP. As the internetwork grew larger, the weaknesses of the host

table system grew:

☯ Central Administration Overload: The changes to the central file became more

frequent, increasing the administrative load on the individual managing the “master”

file to the point where changes were being made many times per day. As the Internet

continued to grow, it would eventually have been impossible for a human being to

enter the changes as fast as they were being submitted.

☯ Growth In Size Of the Master File: Every host needed a line in the master file. When

the Internet grew to be thousands and eventually millions of devices, the file size

would have become excessive.

☯ Excessive Bandwidth Use: Since the file was changing so often, this also meant that

all the devices on the network had to keep downloading this master file repeatedly to

stay current. At the same time, the file was also growing in size as just mentioned. The

combination of many downloads of a large file meant large amounts of network

bandwidth were being consumed on something that is, in essence, an overhead

activity.

☯ Flat Namespace Problems: The lack of a hierarchical name space led to conflicts

when users chose identical names for their devices, and this further increased the

workload on the central administrator. These issues were ameliorated in part by using

naming conventions, such as using a prefix with a location before each individual

machine name, but this was not an ideal solution.

All of these are reasons why the designers of the Internet eventually moved away from

using host tables for the entire Internet to the more capable Domain Name System (DNS).

Key Concept: The host table name system was the original mechanism used for

implementing names on the early Internet. It consists simply of a set of tables

containing mappings between names and addresses maintained on each machine in

the internetwork. When a name needs to be resolved the table is consulted to determine the

appropriate address. This system is extremely simple, but not very capable, and not well-

suited to a large global Internet, which is why it was eventually abandoned in favor of DNS.

Use of the Host Table Name System In Modern Networking

That said, the host table name system has not gone away entirely. There are two circum-

stances in which this technique is still of value:

☯ Small “Island” Networks: If you are setting up a small local area network using TCP/

IP, and you don't need the names of your devices to be accessible by those outside

your network, then guess what? You have the equivalent, of sorts, of the early Internet,

and the host table system is as applicable to you as it was to the Internet in the 1970s.

You can simply set up host tables on each device and manage them manually. As long

as the LAN is small enough that editing these files periodically is not a hassle, this is

actually a fast and effective name system, because no exchange of messages is

needed for resolution. You can even maintain a master file on one machine and copy it

to the others when changes are required using a script, to save time.

☯ Providing Local Name Mappings To Supplement DNS: Even though modern

systems use DNS for most name resolution, they also usually still support the use of

host table files. You can manually enter common name mappings into this file, even for

devices that are on the global Internet. Your system can then be set up to consult this

list before making use of its assigned DNS server.

The use of the HOSTS file in conjunction with DNS allows you to manually specify

mappings for commonly-accessed sites, which may provide a slight performance

improvement since there is no need to access a server. Since the HOSTS file doesn't

enforce any particular structure to names, it is naturally quite possible to put DNS-style

hierarchical names into the file, as I showed in Table 162. The file is loaded into memory

and used to override the normal DNS process for names listed in it.

Of course, you then subject yourself to all the potential maintenance headaches of

manually-edited files: you must update these files as host names or addresses are changed

in the DNS system. For this reason, this second use of the HOSTS file for Internet sites

served by DNS is less popular than the use of the file for local machines.

Key Concept: Even though the host table name system is not the primary

mechanism used for TCP/IP naming, it still used in two circumstances. The first is to

implement a basic name system in a small local TCP/IP internetwork.The second is

as an adjunct to DNS, where it allows manual mappings to be created that override the

DNS process when needed.