Charles M. Kozierok The TCP-IP Guide

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

From a strictly theoretical perspective, having one name server for each zone or domain is

“sufficient” to provide name resolution services for the entire DNS name structure. From an

implementation standpoint, however, having only one name server for each part of the

name space is not a wise idea. Instead, each zone usually has associated with it at least

two name servers: one primary or master name server, and one secondary or slave name

servers. Some zones may have more than one secondary name server.

Note: The terms “primary” and “secondary” are used often in the DNS standards

to refer to the roles of the two authoritative servers for a zone. However, “master”

and “slave” are now the preferred terms, because “primary” and “secondary” are

somewhat ambiguous and used in other contexts. You should be prepared to see both

terms used.

Reasons for Using Slave Name Servers

The master name server is obviously the most essential server. It is on this name server

that the master files for the zone's resource records are maintained, so the master name

server is the “final word” for information on the zone. However, there are several reasons

why slave servers are also important:

☯ Redundancy: We've already discussed how important DNS is, especially on the

Internet; with only one name server, if it ever failed nobody would be able to resolve

names such as “www.xyzindustries.com” into IP addresses, which would be a Bad

Thing [tm]. ☺ Slave name servers act as a backup for the masters they support.

☯ Maintenance: With more than one server, we can easily take the primary server down

for maintenance when needed without name resolution service being disrupted.

☯ Load Handling: Busy zones can use multiple servers to spread the load of name

resolution requests to improve performance.

☯ Efficiency: There are many cases where there is an advantage to positioning a name

server in a particular geographical location for the sake of efficiency. For example, a

company may have an office in a distant location connected using a low-speed WAN

link. To reduce name resolution traffic across that link, it makes sense to have that

zone's information available in a name server on both sides of the connection, so one

would require two physical servers.

Redundancy is the most important consideration in setting up master and slave name

servers. Sticking two machines side by side in a server room, plugged into the same

electrical service, both connected to the Internet with the same Internet Service Provider,

and making one your master DNS server and the other your slave is not a smart move.

Ideally, the primary and secondary servers should be as independent as possible; they

should be physically distant and have separate connections to the Internet.

Propagating Information From the Master Server to Slaves

Just as the names “master” and “slave” suggest, the secondary name servers are not the

original source of information about a zone. They normally obtain their resource records not

from human-edited master files, but from updates obtained from the master server. This is

accomplished using a process called a zone transfer. These transfers are performed on a

regular basis to ensure that the slave servers are kept up to date. The slaves can then

respond to name resolution requests with current information. Both the master and the

slave are considered authoritative for the zone.

Name Server Roles

The “master” and “slave” roles for a zone are logical and do not always correspond to

individual physical hardware devices. A single physical name server can play multiple roles

in the following cases:

☯ It can be the master name server for more than one zone. Each zone in this case has

a distinct set of resource records maintained in separate master files.

☯ It can be a slave name server for more than one zone.

☯ It can be a slave name server for certain zones as well as a primary for others.

Note however that a single physical name server cannot be a primary and a secondary

server for the same zone, since… well, what would be the point?

Key Concept: The master DNS server for a zone is its primary server, which

maintains the master copy of DNS information. Most DNS zones also have at least

one slave or secondary DNS server. These are important because they serve as

backups for the primary server, and they can also help share the load of responding to

requests in busy zones. Secondary name servers get their information from primary servers

on a routine basis. Both master and slave servers are considered authoritative for the

zones whose data they maintain.

Caching-Only Name Servers

We'll see later in this section that for efficiency reasons, all DNS servers perform caching of

DNS information so it can be used again if requested in the near future. This includes both

master and slave name servers. The importance of caching is so significant that there are

some servers that are set up only to cache information from other DNS servers. Unsurpris-

ingly, these are called caching-only name servers.

These name servers are not authoritative for any zone or domain, and don't maintain any

resource records of their own. They can only answer name resolution requests by

contacting other name servers that are authoritative and then relaying the information. They

then store the information for future requests. Why bother? The reason is performance.

Through strategic placement, a caching-only server can increase DNS resolution perfor-

mance substantially in some networks by cutting down on requests to authoritative servers.

Key Concept: There are DNS servers that do not maintain DNS resource records of

their own but solely hold recently-used information from other zones. These are

called caching-only name servers and are not authoritative for any zone.

DNS Zone Management, Contacts and Zone Transfers

The authority for a particular DNS zone is responsible for performing a variety of tasks to

manage it. Zone management encompasses the entire gamut of jobs related to a zone:

deciding on the name hierarchy within the zone, specifying procedures for name regis-

tration, technical work related to keeping DNS servers running and other “administrative

overhead” of all sorts. This job can be either very small or incredibly large, depending on

the type of organization. A small domain owned by an individual doesn't require much work

to manage, while one for a huge company might require a dedicated staff to maintain.

Domain Contacts

It is important that it be possible for anyone on an internetwork to be able to determine who

the owner of a domain is, so that person can be reached for whatever reason. On the

Internet, each DNS domain has associated with it a set of three contacts that are respon-

sible for different facets of managing a domain. These are the:

☯ Administrative Contact: The “main” contact, responsible for the domain as a whole.

This individual or organization is considered the overall owner of the domain.

☯ Billing Contact: A contact responsible for handling payment for domain services and

other accounting matters.

☯ Technical Contact: A contact who handles the technical details of setting up DNS for

the domain and making sure it works.

For smaller domains, there usually is no separate billing contact; it is the same as the

administrative contact. In contrast, the technical contact is often different from the adminis-

trative contact in both large and small domains. Large organizations will make the technical

contact someone in their information technology department. Small organizations often let

their Internet Service Provider (ISP) provide DNS services, and in that case, the technical

contact would be someone at that ISP.

Key Concept: Each DNS domain has associated with it a set of three contact names

that indicate who is responsible for managing it. The administrative contact is the

person with overall responsibility for the domain. The billing contact is responsible for

payment issues; this may be the same as the administrative contact. The technical contact

is in charge of technical matters for the domain, and is often a different person than the

administrative contact, especially when DNS services are out-sourced.

Zone Transfers

The ultimate purpose of zone management is to ensure that information about the zone is

kept current on the zone's master and slave name servers, so it can be efficiently provided

to name resolvers. Thus, the management of a zone begins with decision-making and

administrative actions that result in changes to the resource records for the zone. These are

reflected in changes made to the DNS master files on the master (primary) DNS server for

the zone.

In contrast, each zone's secondary DNS server(s) act as “slaves” to the “master” primary

server. They carry information about the zone, but do not load it from local master files that

are locally edited. Instead, they obtain their information from the master name server on a

regular basis. The procedure responsible for this is called a zone transfer.

The resource records on the master name server can be updated at any time; as soon as

the master name server's records have been changed, the information at the slave name

servers becomes partially out of date. This is not generally a big deal, because most of the

data will still be accurate, and the secondary server will continue to respond to resolution

requests using the most current information it has. However, it is obviously important that

we update the slave servers on a regular basis; if this is not done, eventually their data will

become “stale” and unreliable.

Controlling When Zone Transfers Occur Using DNS Start of Authority Fields

To this end, it is necessary that zone transfers be performed on a regular basis. This

requires implementation of a communication process between the servers that consists of

two basic parts. First, we need a mechanism to allow slave servers to regularly check for

changes to the data on the master. Second, we must have a mechanism for copying the

resource records for the zone from the primary name server to the secondary when

needed.

Both mechanisms make use of standard DNS query/response facilities, and special fields in

the resource records for the zone. Of particular importance is the Start Of Authority (SOA)

record for the zone, which contains several parameters that control zone status checking

and zone transfers. The formal description of these parameters can be found in the topic on

resource record formats, I'll discuss how they are used here.

When a slave name server starts up, it either has no information about the zone at all, or it

may have a copy of the zone's resource records stored on its local storage, from the last

time it was running. In the former case, it must immediately perform a full zone transfer,

since it has no information. In the latter case, it will read its “last known” copy of the zone

from local storage; it may immediately perform a poll on the master server to see if the data

has changed, depending on configuration. A poll is done by requesting the Start Of

Authority resource record for the zone.

The Serial field in the SOA record contains a serial number (which may be arbitrary or may

be encoded so it has a particular meaning) that acts as the “version number” of the master

server's zone database. Each time the master file for the zone is modified (either manually

by editing or automatically through another means) this serial number is increased.

Therefore, a slave server can detect when changes have been made on the master by

seeing if the Serial field in the most recent SOA record is greater than the one the slave

stored the last time it polled the master. If the serial number has changed, the slave begins

a zone transfer.

Three other fields in the SOA record control the timing that slave name servers use for

polling and updating their information:

☯ Refresh: This field specifies how many seconds a slave server waits between

attempts to check for an update on the master. Assuming the slave can make contact,

this is the longest period of time that data on a slave will become “stale” when the

master changes.

☯ Retry: This field controls how long the slave must wait before trying again to check in

with the master if its last attempt failed. This is used to prevent “rapid fire” attempts to

contact a master that may clog the network.

☯ Expire: If, for whatever reason, the slave name server is not able to make contact with

the master for a number of seconds given by this field value, it must assume that the

information it has is stale and stop using it. This means that it will stop acting as an

authoritative name server for the zone until it receives an update.

The fact that these parameters are part of the SOA record for the zone gives the adminis-

trator of the zone complete control over how often master name servers are updated. In a

small zone where changes are rare, the interval between checks made by the slave servers

can be increased; for larger zones or ones that are changed often, the Refresh interval can

be decreased.

Zone Transfer Mechanism

When a zone transfer is required, it is accomplished using a DNS query sent to the master

server using the regular DNS query/response messaging method used for name resolution

(discussed in the next section). A special DNS question type, called AXFR (address

transfer) is used to initiate the zone transfer. The server will then transfer the resource

records for the zone using a series of DNS response messages (assuming that the server

that requested the transfer is authorized to do so). Since it's important that zone transfers

be received reliably, and since the amount of data to be sent is large and needs to be

managed, a TCP session must first be established and used for zone transfers. This is in

contrast to the simpler UDP transport used for regular DNS messages. This is discussed in

the topic discussing the use of UDP and TCP for DNS.

Once the zone transfer is complete, the slave name server will update its database and

return to regular operation. It will continue to perform regular polls of the master server

every Refresh seconds. If it has a problem with a regular poll, it will try again after Retry

seconds. Finally, if an amount of time equal to Expires seconds elapses, the master name

server will stop serving data from the zone until it re-establishes contact with the primary

name server.

Key Concept: Slave name servers do not have their DNS information managed

directly by an administrator. Instead, they obtain information from their master name

server on a periodic basis through a process called a zone transfer. Several fields in

the Start Of Authority DNS resource record control the zone transfer process, including

specifying how often transfers are done and how slave name servers handle problem

conditions such as an inability to contact the master server.

Note that the DNS Notify feature is an enhancement to the basic zone status check / zone

transfer model. It allows the master server to notify a slave server when the master’s

database has changed. Another new feature allows only part of a zone to be transferred

instead of the entire zone. See the topic on DNS name server enhancements for more.

DNS Root Name Servers

The domain name system is strongly oriented around the notion of hierarchical structure:

the name space, registration authorities and name servers are all arranged in a tree

structure. Like these structures, the name resolution process is also hierarchical. As

described in gory detail in the section on name resolution, a fully-qualified domain name is

resolved by starting with the least-specific domain name element (label) and working

towards the most-specific one.

Naturally, the least-specific portion of every name is the root node under which the entire

DNS structure exists. This means that, absent caching and other performance enhance-

ments, all name resolution begins with the root of the name tree. We find here a set of name

servers that are responsible for name server functions for the DNS root: the DNS root name

servers.

Like all name servers, they store information about, and provide name resolution services

for, all the nodes within the “root zone”. This includes certain specific top-level domains and

subdomains. Most top-level domains (TLDs), however, are in their own zones. The root

name servers are used as the “go to” spot to obtain the names and addresses of the author-

itative servers for each of these TLDs. For example, if we want to resolve the name

“www.xyzindustries.co.uk”, the root name servers are where a resolver would find the

identity of the name server that is responsible for “uk”.

Ensuring Access to the Root Name Servers

Clearly, the root name servers are extremely important to the functioning of the DNS system

as a whole. If anything were to ever happen to cause the root name servers to stop

operating, the entire DNS system would essentially shut down. For this reason, there

obviously isn't just one root server, nor are there two or three; there are (at present) thirteen

different root name servers.

In fact, there are actually far more than thirteen physical servers. Most of the thirteen name

servers are implemented as clusters of several independent physical hardware servers.

Some are in fact distributed collections of servers that are in different physical locations.

The best example is the “F” root server, which has been implemented as a set of over a

dozen mirrors in various places around the world, to provide better service.

The principles of redundancy that I mentioned are a good idea for choosing a secondary

name server for a regular domain, obviously apply that much more to the root. This is why

the various physical devices that comprise the thirteen root servers are all located in

different places all around the globe. Many of them are in the United States, but even these

are in many locations throughout the country (albeit concentrated in a couple of “hot spots”

in California and near Washington, DC) and are set up to use different networks to connect

to the Internet.

The root name servers are of course rather powerful; despite there being several dozen

pieces of hardware to spread the load, they must each handle large amounts of data, 24

hours a day. They are run by networking professionals who ensure that they function

efficiently. An Internet standard, RFC 2870 (Root Name Server Operational Requirements),

spells out the basic rules and practices for the operation of these name servers. It specifies

extensive procedures for ensuring the security of the servers, and for avoiding performance

problems due to their pivotal role.

Despite all the efforts taken to ensure that the root servers are widely distributed and

secure, they still collectively represent a point of weakness in the global Internet. Millions

and millions of people depend on these servers. There have been incidents in the past

where rogue elements on the Internet have attempted to disrupt DNS by attacking the root

name servers. One widely-publicized incident was a denial of service (DoS) attack against

the root servers on October 21, 2002. The attack failed, but it significantly raised awareness

of the importance of these servers and how essential DNS security is.

Key Concept: Information about the DNS root and its top-level domains is managed

by a set of root name servers. These servers are essential to the operation of DNS;

they are arranged into thirteen groups and physically distributed around the world.

Current Root Name Servers

Originally, the root name servers were given domain names reflecting the organizations that

ran them. In these historical names we can see a veritable “who's who” of the big players in

the development of the Internet: ISI, NASA, the United States military and others. Several of

the servers are still run by government agencies or the US military, where added security

can be put into place to protect them. For convenience, however, all the root name servers

are now given alphabetical “letter names” in the special domain “root-servers.net”.

Table 168 shows the most current information about the DNS root name servers as of the

date of publishing of this Guide. For your interest and amusement I have also mapped the

locations of these servers in Figure 242.

On The Web: The current list of root name servers can be found in the file ftp://

ftp.rs.internic.net/domain/named.root. You can also find the information in a more

user-friendly format at http://www.root-servers.org.

DNS Name Server Caching, Negative Caching and Data Persistence

Most of the “grunt work” done by name servers is responding to name resolution requests.

Busy servers, like the root name servers, the ones that carry zone information for the top-

level domains, and ones that serve very busy zones, have to handle hundreds or even

Table 168: Internet DNS Root Name Servers

Root Server Name IP Address Historical Name Location(s)

a.root-servers.net 198.41.0.4 ns.internic.net Dulles, VA, USA

b.root-servers.net 128.9.0.107 ns1.isi.edu Marina Del Rey, CA, USA

c.root-servers.net 192.33.4.12 c.psi.net

Herndon, VA and Los Angeles, CA,

USA

d.root-servers.net 128.8.10.90 terp.umd.edu College Park, MD, USA

e.root-servers.net 192.203.230.10 ns.nasa.gov Mountain View, CA, USA

f.root-servers.net 192.5.5.241 ns.isc.org

Auckland, New Zealand; Sao Paulo,

Brazil; Hong Kong, China; Johan-

nesburg, South Africa; Los Angeles,

CA, USA; New York, NY, USA;

Madrid, Spain; Palo Alto, CA, USA;

Rome, Italy; Seoul, Korea; San

Francisco, CA, USA; San Jose, CA,

USA; Ottawa, ON, Canada

g.root-servers.net 192.112.36.4 ns.nic.ddn.mil Vienna, VA, USA

h.root-servers.net 128.63.2.53 aos.arl.army.mil Aberdeen, MD, USA

i.root-servers.net 192.36.148.17 nic.nordu.net Stockholm, Sweden; Helsinki, Finland

j.root-servers.net 192.58.128.30 —

Dulles, VA, USA; Mountain View, CA,

USA; Sterling, VA, USA; Seattle, WA,

USA; Atlanta, GA, USA; Los Angeles,

CA, USA; Amsterdam, The

Netherlands

k.root-servers.net 193.0.14.129 —

London, UK; Amsterdam, The

Netherlands

l.root-servers.net 198.32.64.12 — Los Angeles, CA, USA

m.root-servers.net 202.12.27.33 — Tokyo, Japan

thousands of name resolution requests each second. Each of these requests takes time

and resources to resolve; it also takes internetwork bandwidth away from the business of

transferring data. It is essential, therefore, that DNS server implementations employ mecha-

nisms to improve their efficiency and cut down on unnecessary name resolution requests.

One of the most important of these is caching.

Name Server Caching

The word cache refers to a store, or a place where something is kept. In the computer

world, the term usually refers to an area of memory set aside for storing information that

has been recently obtained so it can be used again. In the case of DNS, caching is used by

DNS name servers to store the results of recent name resolution and other requests, so

that if the request occurs again it can be satisfied from the cache without requiring another

complete run of the name resolution process. Due to how most people use computers, a

particular request is often followed by another request for the same name, so caching can

significantly reduce the number of requests that result in complete name resolution

procedures.

An example is the best way to illustrate this. Suppose you are using a host on your

company's local network. This host is probably configured to use your company's DNS

name server to handle resolution requests. You type “www.xyzindustries.com” into your

Web browser, which causes a resolution attempt to be made for that address. Most likely,

Figure 242: Geographic Locations of Internet DNS Root Name Servers

Los Angeles, CA

San Francisco /

Silicon Valley, CA

Washington, DC

Area

your local DNS server doesn't know that name, so it will follow the complete name

resolution process to get its address. After doing this, your local DNS server will cache the

name “www.xyzindustries.com” and the address associated with it.

If you click on a link for a page at that Web site, that new page will also probably be

somewhere at the “www.xyzindustries.com” site. This will result in another DNS resolution

request being sent off to your local DNS server again. However, this time, the local server

will not have to perform a resolution; it remembers that this name is in its cache and returns

the saved address for the name immediately. Voila! You get your answer faster, and unnec-

essary Internet traffic is avoided.

Key Concept: Caching is an essential efficiency feature that reduces DNS message

traffic by eliminating unnecessary requests for recently-resolved names. Whenever a

name is resolved the resulting DNS information is cached so it can be used for

subsequent requests that occur shortly thereafter.

Caching Data Persistence and the Time To Live Interval

Of course, things aren't entirely this simple. One very important issue that comes up with

every caching system, including the one used in DNS, is the matter of the freshness of the

cache. Suppose our local DNS server resolves the name “www.xyzindustries.com” and

then caches its address. In the example above where we click a link a few seconds after the

XYZ Industries home page loads, we aren't likely too concerned about how fresh the DNS

data is. But how about if we shut down our computer to go on vacation for 2 weeks and then

come back to work and type the name again into our browser. If our local server still has the

name in its cache, how do we know the IP address of “www.xyzindustries.com” hasn't

changed during that two-week period?

Two different mechanisms are used to address this issue. The first is that when data is

cached, the caching server also makes a note of the authoritative server from which it

came. When a resolver (client) asks for a name resolution and the address is drawn from

the cache, the server marks the answer as non-authoritative to clearly tell the client that the

name came from the cache. The server also supplies the name of the authoritative server

that originally supplied the data.

The client then has a choice: it can either use the non-authoritative answer, or issue a

request for a fresh name resolution from the authoritative server. This is a trade-off between

performance (using the cached data) and currency (asking for a fresh resolution each time).

Usually, the cached data can be used safely, because DNS information doesn't change very

often.

The second technique for ensuring that caching data doesn't get too old is a procedure for

limiting the persistence of DNS cached data. Each resource record has associated with it a

time interval, called the Time To Live (TTL). Whenever a resource record is read from a

server, the TTL for the record is also read. Any server caching the record is supposed to

discard the record after that time interval expires.