Charles M. Kozierok The TCP-IP Guide

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

Obviously, they want and need anyone on the Internet to be able to locate this server. Thus,

even though XYZ has private control of the “xyzindustries.com” domain, and thus owns the

name “www.xyzindustries.com”, they must follow proper procedures for ensuring that DNS

resource records are set up for their “www” subdomain so everyone on the Internet can find

it. They may do this themselves, if they run their own DNS servers, or may have an ISP or

other third party do it for them, as described in the previous topic.

Using Private Names For Internal Use

The alternative is to create “purely private” names for use only within the organization. For

example, it is likely that even if XYZ wants a public Web server, it may wish to name many

other machines that are to be accessed only within the company itself. In this case, they

don't need to set these machines up so they are publicly recognizable. They can create

private machine names and manage them internally within their own network.

One common way in which this is done is to make use of the older host table name system.

This system is now archaic for large internetworks, but is often still used in smaller

companies due to its simplicity. A name is “registered” by being added to the host tables on

each of the computers within the organization, and “resolved” when the operating system

on a host checks this file prior to using standard DNS resolution methods. The host table

supplements DNS in this case (it is not really a part of DNS.) The two systems are comple-

ments and can work together, as I explained at the end of the topic describing host tables.

Key Concept: Once an organization registers a particular domain name, it becomes

the owner of that name and can decide whether and how to create a substructure

within that domain. If it wants objects in the domain to be accessible on the public

Internet, it must structure its domain to be consistent with Internet DNS standards. Alter-

nately, it can create a purely private domain using any structure and rules it prefers.

Using Private Names On Networks Not Connected to the Internet

If you are running a “purely private” network not connected to the Internet at all, you can

actually set up your own entirely private name hierarchy and run DNS yourself. In this case,

you become “the boss” in charge of the DNS root and can use any naming system you like.

This is sometimes considered attractive, because one can then use very simple machine

names on small networks, without having to perform any public registration or even use

names that correspond to the global hierarchy. Instead of the accounting computer in XYZ

Industries being named “accounting.xyzindustries.com”, internally it could be named just

“accounting”. You can mix these with real DNS names too when accessing resources, so

Joe's machine could be called just “joe”, while the Web site of UPS would of course still be

“www.ups.com”.

The most common example of this mixing of private and public names is the definition of

the private local name for the loopback address of a computers. Most Windows and UNIX

machines define the name “localhost” to be the address 127.0.0.1, which means “this

computer” on any TCP/IP machine.

DNS Name Servers and Name Resolution

The preceding two sections describe the Domain Name System's hierarchical name space,

and the authorities that manage it and are responsible for name registration. These two

elements, the name space and name registration, are the more “intangible” parts of the

name system, which define how it is created and managed. The “tangible” aspect of the

name system is the set of software and hardware that enables its primary “active function”:

name resolution. This is the specific task that allows a name system to replace

cumbersome numeric addresses with easy-to-use text names.

Name resolution is the part of DNS that generally gets the most attention, because it is the

portion of the system that most people work with on a daily basis. DNS uses a very capable

client/server name resolution method that makes use of a distributed database of name

information. The most commonly used implementation of the DNS name resolution process

is, of course, the one used for the Internet itself, which resolves many billions of name

requests every day.

In this section I explain in detail the concepts and operation of the DNS name resolution

function. The section is broken into three subsections. The first two cover each of the two

key software elements that work together to implement the DNS client/server name

resolution function. The first describes DNS name servers, and how they represent,

manage and provide data when resolution is invoked. The second describes DNS clients,

called resolvers, how they initiate resolution, and the steps involved in the resolution

process. After these I have a third subsection that ties together the information about name

servers and resolvers by providing a look at message exchange between these units, and

describing the formats of messages, resource records and DNS master files.

Background Information: The material in this section assumes that you are

already familiar with the topics in the preceding two sections, and references those

sections where appropriate. If you have not already read the sections on the DNS

name space and name registration, you should at least review the overview of DNS compo-

nents and general functions.

Related Information: A set of related TCP/IP utilities called nslookup, host and

dig can be used by an administrator to query DNS name servers for information.

They are useful for a variety of purposes, including manually determining the IP

address of a host, checking for specific resource records maintained for a DNS name, and

verifying the name resolution function. See the topic discussing these programs in the

section on TCP/IP administration utilities.

DNS Name Server Concepts and Operation

Of all the components and functional elements that combine to form the Domain Name

System, DNS name servers are arguably the most important. These servers, which may be

either dedicated devices or software processes running on machines that also perform

other tasks, are the workhorses of DNS. They store and manage information about

domains, and respond to resolution requests for clients—in some cases millions of times

each day. Understanding how they perform both this most basic task and the many support

jobs for which they are also responsible is crucial to understanding DNS as a whole.

In this section I describe the concepts related to DNS name servers, and explain how they

operate. I begin with an overview of DNS name server functions and general operation. I

describe the way that DNS name server data is stored in resource records and the role of

classes. I discuss the different roles of name servers in DNS, and explain the all-important

root name servers. I discuss how DNS zones are managed, the notions of domain contacts

and zone transfers, and how caching and load balancing are used to improve efficiency in

DNS. I conclude with a brief outline of two enhancements to basic DNS server operation,

using the new Notify and Update message types, as well as incremental zone transfers.

Related Information: The information in this section should be considered

complementary to that in the following section on DNS resolvers.

DNS Name Server Functions, Name Server Architecture and General Operation

The three major functions of a name system are creating a name space, performing name

registration and providing name resolution services. We've seen earlier in this larger section

on the Domain Name System that DNS uses a hierarchical tree structure for its name

space, and also a hierarchical tree for name authorities and registration. I'm sure that, given

this, you will have to struggle to contain your surprise when I tell you that name resolution is

also oriented around the notion of a hierarchical structure.

The devices that are primarily charged with performing the functions required to enable

name resolution are name servers. They are arranged in a hierarchy that is closely related

to the authority structure of the name system. Just as the authority structure complements

the name structure but is not exactly the same as it, the name server architecture comple-

ments both the authority structure and the name structure, but may be different in its actual

composition from both.

DNS Name Server Architecture and the Storage of the Distributed Name Database

In a large DNS implementation, information about domains is not centralized in a single

database run by one authority. Instead, it is distributed across many different authorities that

manage particular top-level domains (TLDs), second-level domains or lower-level subdo-

mains. In the case of the global Internet, literally millions of different “authorities”, many of

them responsible only for their own local domain space, participate cooperatively in running

the DNS system.

With authority for registration distributed in this manner, this means that the information

about domains is similarly spread amongst many entities, resulting in a distributed

database. A key concept in DNS name resolution is that each entity that maintains respon-

sibility for a part of the name space must also arrange to have that information stored on a

DNS server. This is required so that the server can provide the information about that part

of the name space when resolution is performed. As you can see, then, the existence of a

structured hierarchy of authorities directly implies the need for a hierarchy of servers that

store that hierarchical name information.

Each DNS zone of authority is required to have one or more DNS servers that are “in

charge” of managing information about that zone. These servers are said to be authoritative

for the zone. Storing information about the domains, subdomains and objects in the zone is

done by recording the data in special resource records that are read from DNS master lists

maintained by administrators. Servers then respond to requests for this information.

Since information in DNS is stored in a distributed form, there is no single server that has

information about every domain in the system. As we'll see in the section on name

resolvers, the process of resolution instead relies on the hierarchy of name servers

described just above. At the top of the DNS hierarchy is the root domain, and so we also

see there the root name servers. These are the most important servers, because they

maintain information about the top-level domains within the root. They also have knowledge

of the servers that can be used to resolve domains one level below them. Those servers in

turn are responsible for the TLDs and can reference servers that are responsible for

second-level domains. Thus, a DNS resolution may require that requests be sent to more

than one server.

Key Concept: DNS public name information is stored in a distributed database of

DNS name servers that are structured in a hierarchy comparable to the hierarchy of

authorities. Each zone has one or more DNS name servers in charge of the zone’s

information, called authoritative name servers.

DNS Server Support Functions

The storing and serving of name data (through responses to requests from DNS resolvers)

is the main function of a DNS server. However, other support jobs are also typically required

of a DNS server, including the following:

☯ Interacting With Other Servers: As mentioned above, the DNS resolution process

often requires that multiple servers be involved. Servers must thus maintain not just

name information, but information about the existence of other servers. Depending on

the type of DNS request, servers may themselves become clients and generate

requests to other servers.

☯ Zone Management and Transfers: The server must provide a way for DNS infor-

mation within the zone to be managed. A facility also exists to allow a zone transfer to

be performed between the master (primary) server for a zone and slave (secondary)

servers.

☯ Performance Enhancement Functions: Due to the large number of requests servers

handle, they employ numerous techniques to reduce the time required to respond to

queries. The most important of these is caching of name information. A variation of

regular caching called negative caching may also be used to improve performance,

and load balancing is a feature that can be used to improve efficiency of busy devices

registered within the DNS system.

☯ Administration: Various other administrative details are required of name servers,

such as storing information about the different types of “contacts” (humans) who are

responsible for certain tasks related to management of a domain or zone.

As we'll see later in this section, not all name servers perform all of the tasks described

above in this topic; some perform only a subset.

The DNS Name Server Hierarchy is Logical, Not Physical

Like the other hierarchies, the name server hierarchy is logical in nature. I already

mentioned that it often is not exactly the same as the authority hierarchy. For one thing, it is

common for a single DNS name server to be the authoritative server for a number of

domains. Even if a particular group has authority for a subdomain of a particular domain, it's

possible they will “share” the DNS servers with the authority of their parent domain for

efficiency reasons. For example, a university might delegate control over parts of its domain

space to different groups (as in our example in the topic on DNS zones) but still manage all

subdomains on the same server. In practice, the lower the level the subdomain in the DNS

name hierarchy, the less likely that subdomain has its own DNS server.

Another important aspect of the logical nature of the name server hierarchy is that there is

no necessary relationship between the structure of the name servers and their location. In

fact, in many cases name servers are specifically put in different places for reliability

reasons. The best example of this is the set of root name servers—despite all being at the

“top” of the DNS server architecture, they are spread around the globe to prevent a single

problem from taking all of them out. Also remember not to be fooled by the structure of a

name in the geopolitical DNS name hierarchy—a name server called “ns1.blahblah.ca”

might be in Canada, but it very well might not.

Key Concept: The DNS name server hierarchy is logical in nature and not exactly

the same as the DNS name server tree. One server may be responsible for many

domains and subdomains. Also, the structure of the DNS name server hierarchy

doesn’t necessarily indicate the physical locations of name servers.

DNS Name Server Data Storage: Resource Records and Classes

One of the most important jobs performed by name servers is the storage of name data.

Since the authority for registering names is distributed across the internetwork using DNS,

the database of name information is likewise distributed. An authoritative server is respon-

sible for storing and managing all the information for the zones of authority it is assigned.

Each DNS server is, in essence, a type of database server. The database contains many

kinds of information about the subdomains and individual devices within the domain or zone

for which the server is responsible. In DNS, the database entries that contain this name

information are called resource records (RRs). A specific set of RRs is associated with each

node within the zone.

Binary and Text Representations of Resource Records

The entire point of DNS is to allow humans to work with names and computers to work with

numbers, and we see this principle further reflected in the two very different representations

that exist for the DNS resource records themselves:

☯ Resource Record Field Format (Binary) Representation: Name servers are

required to respond to queries for name information by sending resource records

within DNS messages. Obviously, we want to do this in as efficient a way as possible,

so each resource record is internally stored using a special field format that is similar

to the many field formats we have seen used for messages in other protocols. All

resource records use a general field format for some of their fields, and then have a

unique portion that is specific to the resource record type.

☯ Master File (Text) Representation: Computers are happy to exchange binary-

encoded field formats and have no problem remembering that, for example, resource

record type 15 corresponds to a mail exchange (MX) record. However, human admin-

istrators want to be able to quickly and easily maintain DNS information without having

to remember cryptic codes or work with binary values. For this reason, DNS uses a

master file format for its user-machine interface, which allows resource records to be

specified in text form for easier maintenance.

Use of Resource Records and Master Files

Each node may have a variable number of records, depending on the node type and what

information is being kept for it. The resource records are added, changed or deleted when

DNS information changes, by administrators who make modifications to the text master

files on the server computer. These files are then read into memory by the DNS server

software, parsed (interpreted) and converted into binary form. They are then ready for use

in resolving DNS name requests and other queries. This is illustrated in Figure 241.

I describe both the binary RR field formats and master file format in the section on DNS

messaging and formats.

Key Concept: DNS name servers store DNS information in the form of resource

records (RRs). Each RR contains a particular type of information about a node in the

DNS tree. There are two representations for resource records: conventional binary

field formats are used for communication between DNS name servers and resolvers, while

text master files are edited by administrators to manage DNS zones.

Common Resource Records Types

The main DNS standards, RFC 1034 and 1035, defined a number of resource record types.

Over time, the list has changed, with new RR types being created in subsequent standards

and the use of others changed. Like other Internet parameters, the list of DNS RR types is

maintained in a file at IANA.Also like other Internet parameters, there are in fact several

dozen defined RRs in DNS, but only a few are commonly used; others are now obsolete,

used for special purposes or “experimental” in nature.

On The Web: The current list of DNS resource records is maintained in a file that

can be found at: http://www.iana.org/assignments/dns-parameters

Figure 241: DNS Resource Record Master File and Binary Field Formats

To meet the needs of humans and computers, DNS uses two representations for the data stored in resource

records. Administrators enter and maintain information in textual DNS master files. These are read by DNS

server software and internally stored in binary format for answering DNS requests.

Administrator

Master Files

Resource Record

Database

1 0001

Binary Field Format

DNS Server

Table 167 summarizes the most important resource record types. For each, I have shown

the numeric Type value for the record, which is used to identify the resource record type in

message exchanges, and also the text code used for the RR in master files. I have also

provided a brief description of each.

All of these resource records are used in different ways to define zones and devices within

them, and then permit name resolution and other functions to take place. We'll see how

they are used in more detail in the section on name resolution. You can also find a more

lengthy description of some of them in the topic devoted to resource record field formats.

Table 167: Summary Of Common DNS Resource Records

RR Type

Value

RR Text

Code

RR Type Description

1 AAddress

Contains a 32-bit IP address. This is the “meat and

potatoes” of DNS, since it is where the address of a node

is stored for name resolution purposes.

2 NS Name Server

Specifies the name of a DNS name server that is authori-

tative for the zone. Each zone must have at least one NS

record that points to its primary name server, and that

name must also have a valid A (Address) record.

5 CNAME

Canonical

Name

This resource record is used to allow aliases to be defined

that point to the real name of a node. The CNAME record

provides a mapping between this alias and the “canonical”

(real) name of the node. The CNAME resource record is

commonly used to hide changes in the internal DNS

structure from outside users, by letting them use an

unchanging alias while the internal names are modified

based on the needs of the organization. See the topic on

name resolution for an example.

6 SOA

Start Of

Authority

The SOA resource record is used to mark the start of a

DNS zone and provide important information about it.

Every zone must have exactly one SOA record, which

contains details such as the name of the zone, its primary

(master) authoritative server name, and technical details

such as the e-mail address of its administrator and param-

eters for how often slave (secondary) name servers are

updated.

12 PTR Pointer

Provides a pointer to another location in the name space.

These records are best known for their use in reverse

resolution through the IN-ADDR.ARPA domain.

15 MX

Mail

Exchange

Specifies the location (device name) that is responsible for

handling e-mail sent to the domain.

16 TXT Text String

Allows arbitrary additional text associated with the domain

to be stored.

Related Information: See the topic on IPv6 DNS support for IPv6-specific

resource record types.

Resource Record Classes

Finally, a historical note that needs to be mentioned. When DNS was first created, its

inventors wanted it to be as generic as possible. To that end, they designed it so that a DNS

server could, theoretically, provide name service for more than one type of underlying

protocol. That is, DNS could support TCP/IP as well as other protocols simultaneously.

Of course, protocols have different addressing schemes and also varying needs for name

resolution. Therefore, DNS was defined so that each protocol could have a distinct set of

resource record types. Each set of resource record types was called a class. Technically, a

resource record must be identified using both a class identifier and a resource record type.

Like the resource record types, classes have a numeric code number and a text abbrevi-

ation. The class for TCP/IP uses the number 1, with the text code “IN” (for “Internet”).

In practice, this notion of multiple classes of resource records never took off; DNS is today,

to my knowledge, only used for TCP/IP. (There may be some obscure exceptions.) Several

other classes have been defined by RFC 1035 and are in the IANA DNS parameters list,

but they are for relatively obscure, experimental or obsolete network types, with names

such as CSNET, CHAOS and Hesiod. You'll still see this concept of “class” in the specifi-

cation of DNS message and resource record formats, but there really is only class today:

“IN” for TCP/IP. For this reason, in most cases, the class name can be omitted in DNS-

related commands and data entries, and “IN” will be assumed by default.

Key Concept: The DNS standards were originally created to allow them to work with

multiple protocols, by specifying the class of each resource record. Today the only

class commonly used is that for TCP/IP, which is called “IN” (for “Internet”).

DNS Name Server Types and Roles: Primary/Master, Secondary/Slave and Caching-

Only Servers

In the first two topics in this section, we have looked at the functions of DNS servers, with a

particular eye to the important job of storing name server information. There are many

thousands of DNS servers on the Internet, and not all are used in the same way. Each DNS

server has a particular role in the overall operation of the name system. The different kinds

of servers also interact with each other in a variety of ways that we need to understand.

Every zone needs to have at least one DNS name server that is responsible for it. These

DNS name servers are called authoritative servers for the zone, because they contain the

full set of resource records that describe the zone. When any device on the Internet wants

to know something about a zone, it consults one of its authoritative servers.