Charles M. Kozierok The TCP-IP Guide

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

Each zone also has associated with it a default value for the TTL field to be applied to all

records in the zone. This allows an administrator to select a TTL value for all records in a

zone without having to enter TTL numbers for each record individually. At the same time,

the administrator can assign an “override” TTL value to any records that need a number

different from the default. This default TTL was originally found in the special Start Of

Authority resource record for each zone, but is now done using a special directive in the

zone’s master file.

Note: This Time To Live field is not related to the one used in Internet Protocol

datagrams. Obviously IP and DNS are totally different protocols; more than that,

despite having the same name, the TTL fields in IP and DNS don't have the same

meaning at all.

It's worth emphasizing that DNS gives control over caching to the owner of the record, not

whoever is running the DNS server doing the caching. While it is possible for a particular

caching server to “override” the TTL and specify how long data will be held in its own cache,

DNS is not supposed to work that way. The ability to specify a TTL on a record-by-record

basis allows the persistence of cache data to be tailored to the needs of the individual data

elements. Data that changes often can be given a small TTL value, while infrequently-

modified records can be given a higher TTL. Selecting the TTL value must be done

carefully; this is another trade-off between performance (which is optimized with higher TTL

values, reducing the number of queries made for cached data) and “freshness” of the data

(which increases as TTL is lowered).

Key Concept: Cached information can become stale over time, and result in

incorrect responses sent to queries. Each resource record can have associated with

it a time interval, called the Time To Live (TTL), that specifies how long the record

may be held in a cache. The value of this field is controlled by the owner of the resource

record, who can tailor it to the specific needs of each resource record type.

Negative Caching

Classical DNS caching stores only the results of successful name resolutions. It is also

possible for DNS servers to cache the results of unsuccessful name resolution attempts;

this is called negative caching. To extend the example above, suppose you mistakenly

thought the name of the company's web site was “www.xyz-industries.com” and typed that

into your browser. Your local DNS server would be unable to resolve the name, and would

mark that name as “unresolvable” in its cache; a negative cache entry.

Suppose you typed the name in incorrectly because someone mis-typed it on an internal

memo. If a colleague later tried the same name, the DNS server would say “I already know

this is a bogus name” and not try again to resolve it. Since there is no resource record for an

invalid name the server itself must decide how long to cache this negative information.

Negative caching improves performance because resolving a name that doesn't exist takes

resources, just as resolving an existent one does. Note that “regular” caching is sometimes

called “positive caching” to contrast it to “negative caching”.

The value to be used for negative caching in a zone is now specified by the Minimum field

in the Start Of Authority resource record for each zone. As mentioned above, this was

formerly used to specify the default TTL for a zone.

DNS Name Server Load Balancing

The Address (A) resource record is the most fundamental one in DNS, since it records an

actual mapping between a domain name and an IP address. Let's consider for a moment

one of the words in that sentence in more detail. No, not “address” or “resource record” or

“mapping”. The word “an”. ☺ The Address record only mentions a single address for each

domain name. This means that, as we have described DNS so far, each domain name

maps to only a single physical hardware device.

When the number of requests that a particular server or other device needs to handle is

relatively small, this is not a problem—the function can usually be implemented using a

single physical hardware device. If the server gets busier, the usual solution is to throw

more hardware at the problem—get a bigger machine. However, some hosts on a large

internetwork, especially the Internet, feature servers that must handle tremendous amounts

of traffic from many clients. There simply is no single hardware device that can readily

handle the traffic of a site like “www.cnn.com” or “www.microsoft.com” for example, without

becoming unwieldy.

Using Multiple Address Records to Spread Out Requests to a Domain

Sites like CNN’s must use a technique called load balancing to spread requests across

multiple hardware servers. One simple way to do this would be to have multiple machine

names; for example, CNN could create several different Web sites called “www1.cnn.com”,

“www2.cnn.com” and so on, each of which points to a different hardware device. DNS

certainly supports this type of solution. The problem with this solution is that it is

cumbersome; it requires users to remember multiple server names.

It would be better if we could balance the load automatically. DNS supports this by providing

a simple way to implement load balancing. Instead of specifying a single Address resource

record for a name, we can create several such records, thereby associating more than one

IP address with a particular DNS name. When we do this, each time the authoritative name

server for the zone in which that name exists resolves that name, it sends all the addresses

on the list back to the requester. The server changes the order of the addresses supplied in

the response, choosing the order randomly or in a sequential “round robin” fashion. The

client will usually use the first address in the list returned by the server, so by changing the

list, the server ensures that requests for that device's name are resolved to multiple

hardware units.

As Internet traffic increases, load balancing is becoming more popular. In early 2003 I saw a

survey that indicated approximately 10% of Internet names at that time used load

balancing—a fairly significant number. Most employed either two or three addresses, but

some used as many as 60! Incidentally, at last check, “www.cnn.com” was associated with

eight different IP addresses. (Incidentally, you can check the number of addresses

associated with a name using the “host” command.)

Key Concept: Rather than creating a single Address resource record for a DNS

domain name, it is possible to create multiple. This associates several IP addresses

with one name, which can be used to spread a large number of access to one

domain name over many physical IP devices. This allows DNS to implement load balancing

for busy Internet servers.

Using Multiple DNS Servers to Spread Out DNS Requests

“DNS load balancing” also has a completely different meaning from what I described above.

In my discussion of DNS server roles, I talked about how each zone should have at least

one secondary DNS server in addition to the primary. The usually-stated main reason for

this is redundancy, in case something happens to cause the master server to fail. However,

having a slave server can also allow the load of DNS resolution requests to be balanced

between multiple servers. In fact, some busy domains have more than two servers specifi-

cally for this reason.

Thus, “DNS load balancing” can refer to either using DNS to spread the load of requests

(such as Web page requests) to a device that is named using DNS, or to spreading the load

of DNS requests themselves.

DNS Name Server Enhancements: DNS Notify, Incremental Zone Transfers, and DNS

Update (Dynamic DNS)

The fundamentals of operation of Domain Name System servers, as explained in the

preceding topics in this section, are specified in the main DNS standards, RFC 1034 and

1035. These documents are pretty old by computer industry standards; they were published

in 1987. To the credit of the designers of DNS, most of what they originally put into the DNS

protocol is still valid and in use today. The creators of DNS knew that it had to be able to

“scale” to a large size, and the system has in fact successfully handled the expansion of the

Internet to a degree far beyond what anyone could have imagined 15 or so years ago.

As originally defined, the Domain Name System requires that DNS information be updated

manually by editing master files on the primary server for a zone. The zone is then copied in

its entirety to slave servers using a polling/zone-transfer mechanism. This method is satis-

factory when the internetwork is relatively small, and changes to a zone are made

infrequently.

However, in the modern Internet, large zones may require nearly-constant changes to their

resource records. Hand-editing and constantly copying master files can be impractical,

especially when they grow large, and having slave servers get out of date between zone

transfers may lead to reliability and performance concerns. For these reasons, several

enhancements to the operation of DNS servers have been proposed over the years. I'm

going to take a closer look at three of them here.

Automating Zone Transfers: DNS Notify

The first problem that many DNS administrators wanted to tackle was the reliance on

polling for updating slave name servers. Imagine that you placed an order for a new music

CD at your favorite online music store, but it was out of stock—backordered. Which makes

more sense: having you call them every 6 hours to ask if it has arrived yet until it gets there,

or having the store simply call you when it shows up?

The answer is so obvious that the question seems ridiculous. Yet DNS uses the first model:

slave name servers must constantly “call up” their zone masters and ask them “has

anything changed yet?” This both generates unnecessary traffic, and results in the slave

name server being out of date from the time the master does change until the next poll is

performed. Tweaking the Refresh time for the zone only allows one to choose between

more polls or more staleness when changes happen; neither is really “good”.

To improve upon this situation, a new technique was developed; it was formalized in RFC

1996, published in 1996 (weird coincidence!) This standard, A Mechanism for Prompt

Notification of Zone Changes (DNS NOTIFY), defines a new DNS message type called

Notify, and describes a protocol for its use. The Notify message is a variation on the

standard DNS message type, with some of the fields redefined to support this new feature.

When both the master and slave name servers support this feature, when a modification is

made to a resource record, the master server will automatically send a Notify message to

its slave server(s), saying “your CD has arrived!” er… “the database has changed”. ☺ The

slave then acts as if its Refresh timer has just expired. Enabling this feature allows the

Refresh interval to be dramatically increased, since slave servers don't need to constantly

poll the master for changes.

Key Concept: The optional DNS Notify feature allows a master name server to

inform slave name servers when changes are made to a zone. This has two advan-

tages: it cuts down on unnecessary polling by the slave servers to find out if changes

have occurred to DNS information, and it also reduces the amount of time that slave name

servers have out-of-date records.

Improving Zone Transfer Efficiency: Incremental Transfers

The second issue with regular DNS is the need to transfer the entire zone whenever a

change to any part of it is made. There are many zones on the Internet that have truly

enormous master files that change constantly. Consider the master files for the “.COM”

zone for example; having to copy the entire thing to slave name servers every time there is

a change to even one record is beyond “inefficient”—it's downright insane!

RFC 1995, Incremental Zone Transfer in DNS, specifies a new type of zone transfer called

an incremental zone transfer. When this feature is implemented on master and slave name

servers in a zone, the master server keeps track of the most recent changes made to the

database. Each time a slave server determines that a change has occurred and the

secondary's database needs to be updated, it sends an IXFR (incremental transfer) query

to the master, which contains the Serial number of the slave’s current copy of the database.

The master then looks to see what resource records have changed since that Serial

number was the current one, and sends only the updated resource records to the

secondary server.

To conserve storage, the master server obviously doesn't keep all the changes made to its

database forever. It will generally track the last few modifications to the database, with the

Serial number associated with each. If the slave sends an IXFR request that contains a

Serial number for which recent change information is still on the primary server, only the

changes are sent in reply. If the request has a Serial number so old that the master server

no longer has information about some of the changes since that version of the database, a

complete zone transfer is performed instead of an incremental one.

Key Concept: The DNS incremental zone transfer enhancement uses a special

message type that allows a slave name server to determine what changes have

occurred since it last synchronized with the master server. By transferring only the

changes, the amount of time and bandwidth used for zone transfers can be significantly

reduced.

Dealing With Dynamic IP Addresses: DNS Update / Dynamic DNS

The third problem with “classical” DNS is that it assumes changes are made infrequently to

zones, so they can be handled by hand-editing master files. Some zones are so large that

hand-editing of the master files would be nearly continuous. However, the problem goes

beyond just inconvenience. Regular DNS assumes that the IP address for a host is

relatively static. Modern networks, however, make use of host technologies such as the

Dynamic Host Configuration Protocol (DHCP) to assign IP addresses dynamically to

devices. When DHCP is used, the IP address of each host in a zone could change on a

weekly, daily or even hourly basis! Clearly, there would be no hope of keeping up with this

rate of change using a human being and a text editor.

In April 1997, RFC 2136 was published, entitled Dynamic Updates in the Domain Name

System (DNS UPDATE). This standard describes an enhancement to basic DNS operation

that allows DNS information to be dynamically updated. When this feature is implemented,

the resulting system is sometimes called Dynamic DNS (DDNS).

RFC 2136 defines a new DNS message type: the Update message. Like the Notify

message, the Update message is designed around the structure of regular DNS messages,

but with changes to the meanings of several of the fields. As its name implies, Update

messages allow resource records to be selectively changed within the master name server

for a zone. Using a special message syntax, it is possible to add, delete or modify resource

records.

Obviously, care must be taken in how this feature is used; we don't want just anyone to be

making changes “willy-nilly” to our master records. The standard specifies a detailed

process for verifying Update messages, and security procedures that must be put into place

so the server only accepts such messages from certain individuals or systems.

Dynamic DNS allows changes to be made much more easily for an administrator, but its

true power only becomes evident when it is used to integrate DNS with other address-

related protocols and services. Dynamic DNS solves a major weakness with traditional

DNS: the inability to easily associated a host name with an address assigned using a

protocol like DHCP.

With DNS servers supporting this feature, DNS and DHCP can be integrated, allowing

automatic address and name assignment, and automatic update of DNS records when a

host's IP address changes. One common application of dynamic DNS is to allow the use of

DNS names by those who access the Internet using a service provider that dynamically

assigns IP addresses. Dynamic DNS is similarly used by certain directory services, notably

Microsoft's Active Directory, to associate addresses with device names.

Key Concept: An enhancement to DNS, commonly called dynamic DNS, allows

DNS information in a server’s database to be updated automatically, rather than

always requiring hand-editing of master files. This can not only save time and energy

on the part of administrators, it allows DNS to better handle dynamic address assignment,

such as the type performed by host configuration protocols such as DHCP.

DNS Resolution Concepts and Resolver Operations

In the preceding three sections, I have described the Domain Name System's name space,

authority and registration mechanism, and name servers. These elements can all be

considered part of the infrastructure of DNS; they are the parts of the system that must be

established first to enable it to be used. Once we have these components in place, we can

actually get down to the business at hand: name resolution. This is accomplished using a

specific set of procedures carried out by DNS clients called resolvers.

In this section I describe DNS name resolvers and the process of name resolution itself. I

begin with an overview of the functions performed by DNS resolvers and how they work in

general terms. I then describe the two fundamental methods of name resolution used in

DNS: iterative and recursive resolution. I discuss the way that resolvers improve efficiency

through local resolution and caching. I describe the steps in the actual name resolution

algorithm. I then cover two special cases of name resolution: reverse name resolution using

the special IN-ADDR.ARPA domain, and the way that DNS provides mail support using Mail

Exchange resource records.

Related Information: The information in this section complements that in the

previous section on DNS name servers. I assume in the topics here that you have

at least basic familiarity with DNS servers.

DNS Resolver Functions and General Operation

The DNS name servers we explored in the preceding section are arguably the most

important part of the system as a whole. After all, they store all the data on the system and

actually provide the addresses we need when names are given to them; without these

servers, there would be no DNS at all. Of course, what use is a server if nobody is asking

for service? The clients in the system, called resolvers, are also important, because they

initiate the process of name resolution; resolvers are where the “rubber meets the road”, so

to speak.

The operation of DNS resolvers is explained in the two main DNS standards. RFC 1034

describes the functions performed by resolvers, and how they work in general terms. This

includes a discussion of the algorithm used to conduct name resolution. RFC 1035 deals

more with the implementation details of resolvers, and the fine points of how they do their

jobs. Several subsequent standards have of course modified these base standards,

changing some of the ways that resolvers work in different ways.

Name Resolution Services

Just as the main job of a DNS server is to store DNS name data and “serve” it when it

receives requests, the main job of a DNS resolver is to, well, resolve. ☺ While most people

only think of name resolution as the process of transforming a DNS name into an IP

address, this is but one of several types of resolution services performed by DNS. A few of

the most typical types of DNS resolution are:

☯ Standard Name Resolution: Taking a DNS name as input and determining its corre-

sponding IP address.

☯ Reverse Name Resolution: Taking an IP address and determining what name is

associated with it.

☯ Electronic Mail Resolution: Determining where to send electronic mail (e-mail)

messages based on the e-mail address used in a message.

There are other types of resolution activities as well, though again, most name resolution

requests are of the “standard” variety, making it the primary focus in our discussion.

Resolution Functions Performed By Name Resolvers

To accomplish its resolution duties, name resolvers perform a number of related functions:

☯ Providing The User Interface: In order for DNS to be of maximum value to TCP/IP

users, it must be possible for names to be used interchangeably with addresses. This

is usually done automatically by the resolver, which provides an interface to the user to

allow names to be entered and used like addresses.

☯ Forming and Sending Queries: Given a name to resolve, the DNS resolver must

create an appropriate query using the DNS messaging system, determine what type of

resolution to perform, and send the query to the appropriate name server.

☯ Processing Responses: The resolver must accept back responses from the DNS

server to which it sent its query, and decide what to do with the information within the

reply. As we'll see, it may be necessary for more than one server to be contacted for a

particular name resolution.

This seems fairly simple, and it is in some ways, but implementation can become rather

complicated. Bear in mind that the resolver may need to “juggle” several outstanding name

resolutions simultaneously. It has to keep track of the different requests, queries and

responses and make sure everything is kept straight.

The user interface is a very important part of a name resolver’s job. We want users to be

able to just use a name and have their software automatically treat it like an address. For

this reason, normal name resolution usually doesn't involve explicitly running a piece of

“resolver software”. Consider again your Web browser. You don't have to say “please find

the IP address for www.xyzindustries.com” and then say “please connect to this IP address

for XYZ Industries”. You just type in “www.xyzindustries.com” and the name resolution

happens “magically”.

There is no magic, of course. The resolver is just called implicitly instead of explicitly. The

Web browser recognizes that a name has been entered instead of an IP address and feeds

it to the resolver, saying “I need you to resolve this name, please”. (Hey, it never hurts to be

polite.) The resolver then takes care of resolution and provides the IP address back to the

Web browser, which connects to the site. Thus, the resolver is the interface between the

user (both the human user and the software user, the browser) and the DNS system.

Key Concept: The primary clients in DNS are software modules called DNS name

resolvers. They are responsible for accepting names from client software, generating

resolution requests to DNS servers, and processing and returning responses.

Other Functions Performed By Name Resolvers

Name resolvers don't have to perform nearly as many administrative jobs as name servers

do; clients are usually simpler than servers in this regard. One important support function

that many name resolvers do perform, however, is caching. Like name servers, name

resolvers can cache the results of the name resolutions they perform to save time if the

same resolution is required again (not all resolvers perform caching, however.)

I should point out that even though resolvers are the DNS components that are most

associated with name resolution, name servers can also act as clients in certain types of

name resolution. In fact, it is possible to set up a network so that the resolvers on each of

the client machines do nothing more than hand resolution requests to a local DNS server

and let the server take care of it. In this case, the client resolver becomes little more than a

shell, sometimes called a stub resolver. This has the advantage of centralizing name

resolution for the network, but a potential disadvantage of performance reduction.

DNS Basic Name Resolution Techniques: Iterative and Recursive Resolution

Conventional name resolution transforms a DNS name into an IP address. At the highest

level, this process can be considered to have two phases. In the first phase, we locate a

DNS name server that has the information we need: the address that goes with a particular

name. In the second phase, we send that server a request containing the name we want to

resolve, and it sends back the address required.

The Difficult Part of Name Resolution: Finding The Correct Server

Somewhat ironically, the second phase (the actual mapping of the name into an address) is

fairly simple. It is the first phase—finding the right server—that is potentially difficult, and

comprises most of the work in DNS name resolution. While perhaps surprising, this is a

predictable result of how DNS is structured. Name information in DNS is not centralized, but

rather distributed throughout a hierarchy of servers, each of which is responsible for one

zone in the DNS name space. This means we have to follow a special sequence of steps to

let us find the server that has the information we need.

The formal process of name resolution parallels the tree-like hierarchy of the DNS name

space, authorities and servers. Resolution of a particular DNS name starts with the most

general part of the name, and proceeds from it to the most specific part. Naturally, the most

general part of every name is the root of the DNS tree, represented in a name as a trailing

“dot”, sometimes omitted. The next most-specific part is the top-level domain, then the

second-level domain and so forth. The DNS name servers are “linked” in that the DNS

server at one level knows the name of the servers that are responsible for subdomains in

zones below it at the next level.

Suppose we start with the fully-qualified domain name (FQDN) “C.B.A.”. Formally, every

name resolution begins with the root of the tree—this is why the root name servers are so

important. It's possible that the root name servers are authoritative for this name, but

probably not; that's not what the root name servers are usually used for. What the root

name server does know is the name of the server responsible for the top-level domain, “A.”.

The name server for “A.” in turn may have the information to resolve “C.B.A.” It's still fairly

high-level, though, so “C.B.A” is probably not directly within its zone. In that case, it will not

know the address we seek, but it will know the name of the server responsible for “B.A.”. In

turn, that name server may be authoritative for “C.B.A.”, or it may just know the address of

the server for “C.B.A.”, which will have the information we need. As you can see, it is very

possible that several different servers may be needed in a name resolution.

Key Concept: Since DNS name information is stored as a distributed database

spread across many servers, name resolution cannot usually be performed using a

single request/response communication. It is first necessary to find the correct server

that has the information that the resolver requires. This usually requires a sequence of

message exchanges, starting from a root name server and proceeding down to the specific

server containing the resource records that the client requires.

DNS Name Resolution Techniques

The DNS standards actually define two distinct ways of following this hierarchy of servers to

discover the correct one. They both eventually lead to the right device, but they differ in how

they assign responsibility for resolution when it requires multiple steps.

Iterative Resolution

When a client sends an iterative request to a name server, the server responds back with

either the answer to the request (for a regular resolution, the IP address we want) or the

name of another server that has the information or is closer to it. The original client must

then iterate by sending a new request to this referred server, which again may either

answer it or provide another server name. The process continues until the right server is

found; the method is illustrated in Figure 243.