Charles M. Kozierok The TCP-IP Guide

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

TCP/IP Domain Name System (DNS)

The creation of host tables to map computer names to addresses greatly improved the

usability of the early Internet and the TCP/IP protocol suite that implemented it. Unfortu-

nately, while the host table name system worked well when the internetwork was small, it

did not scale particularly well as the Internet started to grow in size and complexity. The

name system had to stay but the use of host tables had to be dispensed with in favor of a

newer, more capable system.

Over the period of several years, many engineers worked to create a system that would

meet not just the needs of TCP/IP internetworks of the time, but also of the future. The new

name system was based on a hierarchical division of the network into groups and

subgroups, with names reflecting this structure. It was designed to store data in a

distributed fashion to facilitate decentralized control and efficient operation, and included

flexible and extensible mechanisms for name registration and resolution. This new name

system for TCP/IP was called the Domain Name System (DNS).

In this section I describe the concepts behind TCP's Domain Name System, as well as its

operation. The section is divided into four subsections. The first provides and overview of

DNS, including a description of its characteristics and components. The next three subsec-

tions describe how DNS implements each of the three primary name system functions: the

DNS name space and architecture; the DNS name registration process, including hierar-

chical authorities and administration; and the DNS name resolution process, focusing on

how name servers and resolvers work. Finally, I have a topic that briefly highlights the

changes made to DNS to support the new version 6 of the Internet Protocol, and its much

longer addresses.

Background Information: I assume in this section that you are already familiar

with the basics of name systems, and make reference to appropriate topics in the

name system overview as needed. You should also be familiar with how TCP/IP

host tables work, as described in the topic preceding this section.

Note: Now, for a quick terminology note. First, even though the abbreviation

“DNS” usually stands for “Domain Name System”, you will also sometimes see the

“S” stand for other words, especially “Service” or “Server”. Second, some

documents refer to this name system as “the DNS”. Most people just say “DNS” without the

definite article, and that's the convention I follow here as well.

DNS Overview, Functions and Characteristics

Most of us know that it's a lot easier to be a critic than a creator. It was easy to tell that the

host table name system used on the fledgling TCP/IP Internet was not going to serve it

going into the future, but finding a solution to this problem was much more difficult. The

main reason the host table system was insufficient was that it was too simple, and this

meant that its replacement, the Domain Name System (DNS), had to be considerably more

sophisticated. Naturally, this made DNS more difficult to design, and also means we have to

devote more energy to understanding how it works.

As I like to do with the explanation of most of the complex systems and protocols in this

Guide, I begin in this section with background information and an introduction to TCP/IP

DNS. I start by providing an overview of DNS's development, history and standards,

continuing the history begun in the overall look at TCP/IP name systems. I discuss the

design goals and objectives of the creators of DNS, to help you understand better what its

designers were trying to do. I then talk about the main components of DNS and the

functions it performs, relating these to the basic functions explained in the overview section

on name systems.

DNS Overview, History and Standards

The aversion that most people have to trying to remember numeric identifiers led to the very

quick adoption of a name system for devices on the predecessors of what we now call the

Internet. In the 1960s and early 1970s, names were given to machines, and these names

maintained in host tables. The TCP/IP host table name system worked well for a number of

years, with a centrally-maintained master list used by device administrators to ensure a

consistent view of the network.

Unfortunately, such a system only works well when the number of devices is small. As the

budding Internet grew, numerous weaknesses became apparent in the host table method,

as I detailed in the section describing that system. Furthermore, the problems with the

system weren't something that could be easily “patched” with small changes; the problems

were structural, part of the basic idea of host tables as a whole. A completely new approach

was needed for how names would be used on the Internet.

Early DNS Development and the Move to Hierarchical Domains

The most important “paradigm shift” made by the TCP/IP engineers was the decision to

change the name system from one that used a single, centralized list of names to a more

decentralized system. The idea was to create a structured topology where names were

organized into domains. This idea was first introduced in the September 1981 RFC, 799,

entitled Internet Name Domains.

RFC 799 actually describes more the mechanics of delivering electronic mail messages

between domains than the domains themselves. Interestingly, the standard assumes a flat

structure of domains in its discussion, while mentioning the possibility of creating a hierar-

chical structure instead. It was in fact the decision to go to such a hierarchical name space

for domains that led to the creation of the Domain Name System (DNS) in the form in which

we know it today.

Many different RFC documents were published in the early 1980s, describing the devel-

opment of different aspects of DNS. The first real milestone in DNS's history was probably

the publishing, in November 1983, of a “triplet” of initial documents discussing DNS

concepts, shown in Table 163.

Standardization of DNS and Initial Defining Standards

The documents above were discussed frequently over the months that followed, and the

basic DNS mechanism revised many times. Several subsequent RFCs were published,

updating the DNS cut-over plan and schedule. Finally, in November 1987, agreement on

the operation of the system was finalized and a “quartet” of new RFCs were published that

formalized the DNS system for the first time. These standards are RFCs 1032 through

1035, shown in Table 164.

Table 163: Documents Discussing TCP/IP Domain Name System (DNS) Concepts

RFC

Number

Name Description

881

Domain Names Plan and

Schedule

Discusses the issues involved in implementing the new

DNS name system and how to migrate from the older host

table system.

882

Domain Names: Concepts and

Facilities

Describes the concepts and functional elements of DNS in

fairly extensive detail. Includes a discussion of the name

space, resource records, and how name servers and

resolvers work.

883

Domain names: Implemen-

tation Specification

Provides the “nitty gritty” details on DNS messaging and

operation.

Table 164: Initial Standards Defining The TCP/IP Domain Name System (DNS)

RFC

Number

Name Description

1032 Domain Administrators Guide

Specifies administrative procedures and policies for those

running a domain.

1033

Domain Administrators Opera-

tions Guide

Provides technical details on how to operate a DNS

server, including how to maintain portions of the DNS

distributed database of names.

1034

Domain Names - Concepts

and Facilities

Replaces RFC 882, providing an introduction and

conceptual description of DNS.

1035

Domain Names - Implemen-

tation and Specification

An update to RFC 883, specifying how DNS works in

detail, including resource record definitions, message

types, master file format, and resolver and name server

implementation details.

These last two documents, RFCs 1034 and 1035, are considered the definitive original

specification for the operation of the Domain Name System. While they are now many

years old, they still provide the essential description of how DNS works.

DNS has quickly become a very important part of how both the Internet and TCP/IP work.

As the Internet has grown to include thousands and then millions of sites, the importance of

DNS has grown as well. Today, most people use DNS almost every time they use TCP/IP to

access the Internet. It has gone from an alternative form of addressing for applications to

one that is preferred by most users. It is an important building block of the more complete

“application layer addressing” scheme developed for TCP/IP: Uniform Resource Identifiers

(URIs).

The hierarchical nature of the DNS name space is the only thing that has allowed the

Internet to grow while making the assignment and mapping of names manageable. The

authority structure is also hierarchical, giving local administrators control over the names of

devices they manage while ensuring name consistency across the hierarchy as a whole.

The distribution of data using many name servers and a standardized resolution technique

following a standard message protocol provides efficiency and reliability. These concepts

will become more clear as we explore DNS more completely in later topics.

DNS Evolution and Important Additional Standards

TCP/IP and the Internet have both changed a lot since 1987, of course, and DNS has also

had to change to suit. Many RFCs have been written since the base documents were

published in the late 1980s, most of which further clarify the operation of DNS, expand on

its capabilities, or define new features for it. You can find all of these by searching for

“domain” or “DNS” in a list of RFCs. There are dozens of these, and I see no point in simply

listing them all here, but I have highlighted a few of the more interesting ones in Tab le 165 .

Table 165: Additional DNS Standards (Page 1 of 2)

RFC

Number

Name Description

1183 New DNS RR Definitions

Defines several new “experimental” resource record types.

Other subsequent RFCs have also defined new RRs.

1794

DNS Support For Load

Balancing

Discusses load balancing for greater performance in DNS

servers.

1995

Incremental Zone Transfer in

DNS

Specifies a new feature that allows only part of a zone to

be transferred to a secondary name server for efficiency.

1996

A Mechanism for Prompt

Notification of Zone Changes

(DNS NOTIFY)

Adds a new message type to DNS to allow primary

(authoritative) DNS servers to tell secondary servers that

information has changed in the main database.

2136

Dynamic Updates in the

Domain Name System (DNS

UPDATE)

Describes a technique for dynamically making resource

record changes in the DNS database (also called Dynamic

DNS).

Adapting DNS For IPv6

IP version 6 was developed starting in the mid-1990s, and brought with it the need to make

changes and enhancements to the operation of DNS. (Even though DNS operates at the

higher layers, it deals intimately with addresses, and addresses have changed in IPv6.) The

modifications required to DNS to support IPv6 were first defined in RFC 1886, IPv6 DNS

Extensions, which was part of a group of RFCs that laid out the fundamentals of IPv6.

Several subsequent standards have been published since that time; these are discussed in

the topic on IPv6 DNS.

The three topics following in this section provide a more complete overview of DNS and its

development, by discussing the design goals of its creators, and the protocol's key

characteristics.

DNS Design Goals, Objectives and Assumptions

As we just saw in the preceding topic, the elapsed time from the first RFC discussing TCP/

IP domain names to the publishing of the official standards describing the operation of DNS

was over six years. This is a very long time for the development of a system, but it doesn't

surprise me. A lot of thought had to go into the creation of DNS, to be certain that it would

meet all of the many demands that would be placed upon it.

The first problem was that the creators of DNS had to worry about both how to define the

new system and how to migrate from the old one. Considerable time was spent figuring out

how all the existing hosts would be moved over to the new DNS name space and how the

new protocols for exchanging DNS information would be implemented on them.

The creators of DNS knew they were making the new system because the old one didn't

scale very well; they also knew that if migration was a difficult problem with the small

number of hosts in existence at that time, it would be much more difficult if they had to go to

another new system in the future. This made the key challenge in DNS to create a system

that would meet the needs of the Internet not just the day it was introduced, or the following

year, but even ten years or more down the road.

2181

Clarifications to the DNS

Specification

Discusses several issues with the main DNS standards as

defined in RFCs 1034 and 1035 and how to address them.

2308

Negative Caching of DNS

Queries (DNS NCACHE)

Specifies the operation of negative caching, a feature that

allows a server to maintain information about names that

do not exist more efficiently.

Table 165: Additional DNS Standards (Page 2 of 2)

RFC

Number

Name Description

DNS Design Goals and Objectives

Back in the 1980s, nobody had any idea how the Internet would grow as it has in the last

decade. That DNS still works as well as it does is a testament to the skill of its designers.

Much of this success is due to the early groundwork put into the design of the system. DNS

engineers documented some of what they considered to be the main design goals in

creating it, which can help us understand not just what DNS does but why:

☯ Creation Of A Global, Scalable, Consistent Name Space: The name space had to

be capable of spanning a large, global internetwork containing millions of machines. It

was necessary that it provide a consistent and predictable method for naming devices

and resources so they could be easily found. It was also, obviously, essential that

name duplication be avoided, even when conflicts could potentially be between

devices on different continents.

☯ Local Control Over Local Resources: Administrators of networks and small internet-

works on the Internet as a whole needed to be able to have control over the naming of

their own devices. It would not be acceptable to have to go through a central authority

for naming every single object, nor would it be acceptable for every administrator to

need to know the names of everyone else's networks and machines.

☯ Distributed Design To Avoid Bottlenecks: The designers of DNS knew that they

would have to abandon the idea of a centralized database in favor of a distributed

approach to data storage, to avoid the bottlenecks that would result in using DNS with

many devices.

☯ Application Universality: The system had to be general enough that it would support

a wide variety of applications. For example, it needed to support host identification,

mail delivery and other functions.

☯ Multiple Underlying Protocol Support: DNS needed to be inherently able to support

different underlying protocols. (Many people don't realize, for example, that DNS can

support not just IP addresses but other types of addresses, simply because IP is so

dominant in networking today.)

☯ Hardware Universality: Both large and small computers needed to be able to use the

system.

Keep these objectives in mind as you learn more about DNS, and it will help you under-

stand better why certain design attributes were chosen. For example, if we consider the first

two objectives listed above, they seem almost contradictory: how can we have a global

name space with unique names if individual administrators were able to assign local

names? The answer, as we will see, is that this is where the power of the DNS hierarchical

name space shines through.

DNS Design Assumptions

The goals above tell us what DNS's creators wanted to make sure the new system

addressed. In addition, the engineers that worked on the protocol's implementation details

had to make decisions based on certain assumptions of how it would be used. Some of the

more significant of these assumptions:

☯ Rapidly Growing Database Size: By the mid-1980s it was obvious that the DNS

database of names would start out rather small but would grow quickly. The system

needed to be capable of handling this rapid growth.

☯ Variable Data Modification Rate: Most of the data in the name database would

change only infrequently, but some would change more often than that. This meant

flexibility would be required in how data changes are handled, and how information

about those changes was communicated.

☯ Delegatable Organizational Responsibility: Responsibility for portions of the name

database would be delegated primarily on the basis of organizational boundaries.

Many organizations would also run their own hardware and software to implement

portions of the overall system.

☯ Relative Importance of Name Information Access: It was assumed that the most

important thing about DNS was providing reliable name resolution, so the system was

created so that it was always possible for a user to access a name and determine its

address. A key decision in creating the system was deciding that even if the infor-

mation is slightly out-of-date it is better than no information at all. If a name server

were unable to provide the latest data to fill a request, it would return the best infor-

mation it had available.

☯ Handling of Requests For Missing Information: Since the name data was to be

distributed, a particular name server might not have the information requested by a

user. In this case, the name server should not just say “I don't know”. It should provide

a referral to a more likely source of the information, or take care of finding the data by

issuing its own requests. This led to the creation of the several DNS name resolution

techniques: local, iterative and recursive.

☯ Use Of Caching For Performance: From the start, it was assumed that DNS would

make extensive use of caching to avoid unnecessary queries to servers containing

parts of the distributed name database.

Arguably, a lot more assumptions were made in creating this system, like every system. For

example, DNS had to make assumptions about how exactly data would be stored, the

transport mechanism for sending messages, the role of administrators and so on. We'll

learn more about these as we go through our look at the system.

DNS Components and General Functions

To meet the many objectives set for it by its designers, DNS requires a great deal of

functionality. It is a true name system with the emphasis on system, and as such is consid-

erably more complex than the host table name system used earlier in TCP/IP. In the section

describing name systems in general, I divided the many tasks a fully-featured name system

into three categories. DNS includes functions in all of these categories, and so using these

categories is a good way to take a high-level look at the way DNS works.

The following are the three basic name system functions, and how DNS implements them

(see Figure 234).

Name Space

DNS uses a hierarchical name space consisting of a single, complex, multi-level structure

into which all names in the system fit. The name space is organized starting from a single

root into which “containers” (called domains) are placed. Each can contain either individual

device names or more specific “sub-containers”. The overall structure is somewhat

analogous to how a directory system on a computer organizes files from general to specific,

using an arbitrary structure that can be optimized to various needs.

A specific syntax is used to define valid names, and special terminology used to describe

parts of the structure and identify domain names, from the root down to the device level.

Name Registration (Including Administration and Authorities)

DNS name registration is used to enter individual names into the DNS distributed database.

DNS uses a hierarchical arrangement of authorities that complements the hierarchical

name space. A centralized authority determines the overall shape and structure of the

name space, and handles registration of names at the highest level. Authority is then

delegated to different organizations to manage various parts of the name space. A set of

universal policies controls the registration process and deals with problems and conflicts.

Name Resolution

DNS uses a powerful, distributed, client/server name resolution mechanism. This is

probably the area where the most attention had to be put into the design of DNS, to ensure

that it could scale to handle millions and eventually billions of name resolution requests

each day.

Figure 234: DNS Functions

Domain Name System (DNS)

DNS Name Space

Hierarchical Name

Archite ctur e

DNS Name Structure

and Naming Rules

Domain Name

Specifications

Name Registration

Hierarchical Authority

Structure

Internet Top Level

Domain Hierarchies

Second-Level Domain

Registration Procedures

DNS Zones and

Hierarchy Administration

Name Servers and

Name Resolution

DNS Resource Records

and Master Files

Name Servers, Types,

Roles and Functions

Name Resolvers and

Resolution Procedures

DNS Messages, Formats

and Notation

The name resolution process is implemented using two basic software elements that play

the role of client and server: name servers and name resolvers.

Name Servers

DNS name servers are special programs running on hardware servers that are the heart of

DNS. Servers are maintained by organizations that have administrative control over part of

the DNS name space, and contain resource records that describe names, addresses and

other characteristics of those portions of the name space. As such, the servers themselves

are arranged into a hierarchy analogous to that of the name space, though not identical in

structure.

The main job of name servers is to receive requests for name resolution and either respond

with the data requested from the database, or with the name of another name server that

will lead to the requested information. Name servers are also responsible for data caching

and other administrative tasks to ensure efficient operation of the system as a whole.

Name Resolvers

Name resolvers are the usual clients in the name resolution process. When a user makes

reference to a name in a networking application, the name is passed to the resolver, which

issues a request to a name server. Depending on the configuration, more than one request

may be needed, and several different resolution processes may be combined to find the

needed information. Resolvers too may employ caching or implement other features.

Note: The division between resolvers and servers is based on role. As we'll see

when we look at name resolution, name servers may also function as clients in

certain exchanges of data. See the topic on DNS messaging for an explanation of

this apparent paradox.

If this seems a lot like the “classic” description of a name system that I gave in the name

system concepts section, that's not a coincidence; DNS is considered the name system

against which most others are usually compared. If you understand these high-level

descriptions, then you already know the basics of how DNS works. The next three sections

delve into each of these three functional areas in more detail, and will help you really learn

how DNS does its thing.

Key Concept: As a complete name system, DNS provides numerous capabilities

that implement each of the three basic name system functions. The DNS name

space is hierarchical and is organization using a multi-level structure with particular

naming rules. The DNS name registration system is based on the idea of a hierarchy of

domains and registration authorities responsible for them. DNS name resolution is similarly

hierarchical, and designed around interaction between name resolver and name server

software components that consult databases of DNS resource records and communicate

using a special messaging protocol to answer client queries.