Charles M. Kozierok The TCP-IP Guide

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

Figure 246: The DNS IN-ADDR.ARPA Reverse Name Resolution Hierarchy

The special “IN-ADDR.ARPA” hierarchy was created to allow easy reverse lookups of DNS names. “IN-

ADDR.ARPA” contains 256 subdomains numbered 0 to 255, each of which has 256 subdomains numbered 0

to 255, and so forth, down four levels. Thus, each IP address is represented in the hierarchy. In this diagram I

have shown as an example the DNS domain name “www.xyzindustries.com”. It would have a conventional

resource record pointing to its IP address, 191.27.203.8, as well as a reverse resolution record at

8.203.27.191.IN-ADDR.ARPA, pointing to the domain name “www.xyzindustries.com”.

Inverse Address Pointer for

www.xyzindustries.com

(191.27.203.8)

(root)

arpa

in-addr

0 1 255191

0 1 27 255

1 1 203 255

0 1 8 255

...

... ...

com

xyzindustries

www

Resource Record Setup for Reverse Resolution

With the IN-ADDR.ARPA structure in place, we can now associate one entry in this name

space with each entry in the “real” DNS name space. We do this using the “PTR” (pointer)

resource record type. For example, if “www.xyzindustries.com” has the IP address

191.27.203.8, then the DNS server for its zone will have an address resource record

indicating this. In master file text format, it will say something like this:

www.xyzindustries.com. A 191.27.203.8

However, there will also be the following entry for it within the IN-ADDR.ARPA domain:

8.203.27.191.IN-ADDR.ARPA PTR www.xyzindustries.com

(Remember that DNS names are case-insensitive, so the “IN-ADDR.ARPA” could also be

given as “in-addr.arpa”).

Once this is done, reverse name resolution can be easily performed by doing a name

resolution on “8.203.27.191.in-addr.arpa”. If we do this, a server for the “IN-ADDR.ARPA”

domain will return to us the name “www.xyzindustries.com”. This is also shown in Figure

246.

Why The IN-ADDR.ARPA Structure Is the Opposite of Normal IP Addresses

I'm sure you've noticed that the numbers are “backwards” in the IN-ADDR.ARPA domain.

We've already seen the reason for this: name resolution proceeds from the least-specific to

the most-specific element, going from right to left. In contrast, IP addresses have the least

specific octet on the left, and the most specific on the right. Thus, we reverse them to

maintain consistency with the DNS name space.

This immediately yields us one extra benefit. Just as we can delegate authority for portions

of the regular name space, for example, letting “XYZ Industries” be in charge of everything

in “xyzindustries.com”, we can also delegate authority for parts of the IN-ADDR.ARPA

name space. For example, since MIT owns all IP addresses with a first octet of 18—at least

I think they still do—it is possible that if MIT wanted to, they could control the “18.IN-

ADDR.ARPA” domain as well for reverse queries. This would not be possible without

reversing the octets as we have done.

Note that for this system to work reliably, it is essential that the data in the “regular” name

space and the reverse name space remain consistent. Whenever a new DNS name is

registered, an appropriate entry must be made within IN-ADDR.ARPA as well. Special

procedures have been put into place to allow these pointer entries to be created

automatically.

Related Information: A similar scheme using a different reverse domain is used

for DNS under IPv6.

Key Concept: Most name resolutions require that we transform a DNS domain

name into an IP address. However, there are cases where we want to perform a

reverse name resolution, by starting with an IP address and finding out what domain

name matches it. This is difficult to do using the conventional DNS distributed name

hierarchy, because there is no easy way to find the DNS server containing the entries for a

particular IP address using the regular DNS name hierarchy. To this end, a special

hierarchy called IN-ADDR.ARPA was set up for reverse name lookups. This hierarchy

contains four levels of numerical subdomains structured so that each IP address has its

own node. The node for an IP address contains an entry that points to the DNS domain

name associated with that address.

DNS Electronic Mail Support and Mail Exchange (MX) Resource Records

Most savvy users of the Internet know that the Domain Name System exists, and usually

associate it with the most common Internet applications. Of these applications, the “big

kahuna” is of course the World Wide Web. It's probably the case that the majority of DNS

name resolution requests are spawned as a result of Web server domain names being

typed into browsers billions of times a day, as well as requests for named pages generated

by both user mouse clicks and Web-based applications.

Of course, DNS is not tied specifically to any one application. We can specify names in any

place where an IP address would go. For example, you can use a DNS name instead of an

address for an FTP client, or even for a troubleshooting utility like traceroute or ping. The

resolver will in each case take care of translating the name for you.

There's one application that has always used DNS, but it's one that doesn't usually spring to

mind when you think about DNS: electronic mail. Electronic mail is in fact more reliant on

DNS than just about any other TCP/IP application. Consider that while you may sometimes

type in an IP address for a command like traceroute, or even type it into a browser, you

probably have never sent anyone mail by entering “joe@14.194.29.60” into your e-mail

client. At least I never have in over a dozen years being online. You instead type

“joe@xyzindustries.com”, and DNS takes care of figuring out where electronic mail for XYZ

Industries is to go.

Special Requirements for Electronic Mail Name Resolution

Name resolution for electronic mail addresses is different from other applications in DNS,

for three reasons that I describe in the overview topic on TCP/IP e-mail addressing and

address resolution. To summarize: first, we may not want electronic mail to go to the exact

machine specified by the address; second, we need to be able to change server names

without changing everyone's e-mail address; and third, we need to be able to support

multiple servers for handling mail.

For example, XYZ Industries might want to use a dedicated mail server called “mail.xyzin-

dustries.com” to handle incoming mail, but actually construct all of its e-mail addresses to

use “@xyzindustries.com”. This makes addresses shorter, and allows the server's name to

be changed without affecting user addresses. If the company wishes, it might decide to use

two servers, “mail1.xyzindustries.com” and “mail2.xyzindustries.com”, for redundancy, and

again have just “@xyzindustries.com” for addresses.

The Mail Exchange (MX) Record and Its Use

To allow the flexibility needed for these situations, a special DNS resource record type is

defined called a mail exchange (MX) record. Each MX record specifies a particular mail

server that is to be used to handle incoming e-mail for a particular domain. Once this record

is established, resolution of electronic mail messages is pretty much similar to how it works

for regular resolution. Suppose we want to send an e-mail to “joe@xyzindustries.com”. The

process, roughly, is as follows:

1. Our e-mail client invokes the resolver on our local machine to perform an e-mail

resolution on “xyzindustries.com”.

2. Our local resolver and local DNS server follow the process described in the topic on

DNS name resolution to find the authoritative server for “xyzindustries.com”, which is

“ns1.xyzindustries.com”.

3. “ns1.xyzindustries.com” finds the MX record for “xyzindustries.com” and replies back

indicating that “mail.xyzindustries.com” should be used for e-mail.

Of course, the e-mail client can't actually send anything to “mail.xyzindustries.com”; it

needs its IP address. So, it would then have to resolve that name. Of course, this resolution

request will likely end up right back at the same DNS name server that just handled the MX

request. To eliminate the inefficiency of two separate resolutions, the DNS name server can

combine the information. In our example above, “ns1.xyzindustries.com” will include the A

(Address) resource record for “mail.xyzindustries.com” in the Additional section of the DNS

message that it sends in step 3 above.

It is also possible to specify multiple MX records for a particular domain, each pointing to a

different mail server's name. This provides redundancy, so if there is a problem with one

mail server, another can pick up the slack. DNS allows each mail server to be specified with

a preference value, so you can clearly indicate which is the main mail server, which is the

first backup, the second backup, and so on. The DNS server will choose the mail server

with the lowest preference value first, then the next highest one, and so on.

Key Concept: Since electronic mail is sent using host names and not IP addresses,

DNS contains special provisions to support the transfer of e-mail between sites.

Special mail exchange (MX) DNS resource records are set up that contain the

names of mail servers that a domain wants to use for handling incoming e-mail. Before

sending e-mail to a site, a device performs a name resolution to get that site’s MX record,

so it knows where to send the message.

Obsolete Electronic Mail Resource Records

Note that RFC 1035 originally defined several other resource record types related to

electronic mail as well: the mailbox (MB), mail group (MG) and mail rename (MR) resource

records. These are called “experimental” in the standard. I think the experiment failed,

whatever it was, because I don't believe these are used today. There are also two even

older mail-related resource records, mail destination (MD) and mail forwarder (MF), which

must have been used at one time but were already obsolete at the time RFC 1035 itself was

written.

DNS Messaging and Message, Resource Record and Master File Formats

Networking is all about the communication of information between connected devices. In

the case of the Domain Name System, information about names and objects on the inter-

network is exchanged during each of the many types of operations DNS performs. This

involves sending messages between devices. Like most protocols, DNS uses its own set of

messages with distinct field formats, and follows a particular set of rules for generating them

and transporting them over the internetwork.

In this section I explain how messages are generated and sent in DNS, and also describe

the formats used for messages and resource records. I begin with an overview discussion

of DNS messages and how they are generated and transported. I provide an overview of

the general DNS message format, and the five sections it contains. I describe the notation

used for names and the special compression method that helps keep DNS messages down

in size. I then show the fields in the DNS message header and question section. I illustrate

the common field format used for all resource records, and the specific fields in the most

important record types. I conclude with a description of the format used for DNS text master

files.

DNS Message Generation and Transport

In the preceding sections we have explored the many different tasks that DNS servers and

resolvers perform: regular name resolution, reverse name resolution, e-mail resolution,

zone transfers, and more. Each of these operations requires that information be exchanged

between a pair of DNS devices. Like so many other TCP/IP protocols, DNS is designed to

accomplish this information transfer using a client/server model. All DNS exchanges begin

with a client sending a request, and a server responding back with an answer.

DNS Client/Server Messaging Overview

In the overview topic on TCP/IP's client/server nature, I explained a potential source of

confusion regarding these terms: the fact that they refer to hardware roles, software roles

and transactional roles. This issue definitely applies when it comes to DNS. We've already

seen that DNS implementation consists of two sets of software elements: resolvers that act

as clients and name servers that are of course the servers. Resolver software usually runs

on client machines like PCs, while name server software often runs on dedicated server

hardware.

However, these designations are based on the overall role of the hardware and software.

From a messaging viewpoint, the “client” is the initiator of the communication, regardless of

what type of machine does this initiating, and the “server” is the device that responds to the

client. A resolver usually acts as a client and a name server as a server. However, in a

particular exchange a DNS name server can in fact act as a client, in at least two cases.

First, in recursive name resolution, a server generates requests to others servers and

therefore acts as a client. Second, in administrative functions like zone transfers, one server

acts like a client and sends a request to another server. (There are no cases in DNS that I

know of where a resolver acts as a server, incidentally.)

Most transactions in DNS consist of the exchange of a single query message and a single

response message. The device acting as client for the transaction creates the query and

sends it to the server; the server then sends back a reply. This is done through the process

described in the next topic. In certain cases where a great deal of data needs to be sent,

such as zone transfers, the server may send back multiple messages. Multiple such trans-

actions may be required to perform a complete name resolution, as my example of the DNS

resolution process demonstrated.

DNS Message Transport Using UDP and TCP

TCP/IP of course has two different protocols for data transfer: the User Datagram Protocol

(UDP) and Transmission Control Protocol (TCP). UDP and TCP “share” level 4 in TCP/IP

because they are so different in terms of capabilities and operation. Some application

protocols need the services of TCP and can use it to take advantage of them, while others

are better off with the simpler UDP. DNS is itself a perfect example of the valid reasons for

having both UDP and TCP in the protocol suite, because it uses both.

UDP Message Transport

UDP is a simple connectionless protocol that provides no real features but is very fast. It is

ideally suited for small, quick exchanges of information, and can be faster than TCP

because there is no need to establish a connection. This makes it a good choice for most of

the conventional queries used in DNS, because they are normally very short, and fast data

exchange is important. For this reason, the DNS standards recommend use of UDP for

queries and replies as part of regular and reverse name resolution. UDP DNS messages

are limited to 512 bytes; longer messages are truncated and a special bit in the header is

set to indicate that this has occurred. If a message being truncated causes a problem for its

recipient, the query must be repeated using TCP, as described below.

Note: The 512 byte limit on DNS UDP messages can be surpassed if the optional

Extension Mechanisms for DNS (EDNS0) are implemented. These are described

in RFC 2671.

TCP Message Transport

Since UDP does not provide reliable delivery of messages, DNS clients must keep track of

requests they have sent. If no response is received after a particular amount of time, the

request must be retransmitted. The need to take care of these details is considered an

acceptable trade-off for the lower setup costs involved with UDP, such as not requiring a

connection. The rate at which retransmissions is sent is usually set at a minimum of 2 to 5

seconds to prevent excessive DNS traffic on the internetwork.

For certain special DNS transactions, UDP is simply inappropriate. The most common

example of such a transaction is a zone transfer. While the query for a zone transfer is small

in size, the amount of data sent in response can be quite large. The limit of 512 bytes for

UDP is not even close to enough. Furthermore, we really do need to make sure that a zone

transfer is accomplished reliably and with flow control and other data transfer management

features, or we risk having corrupted zone information in our secondary DNS server

databases.

The solution is to use TCP for these types of exchanges. TCP allows messages to be of

arbitrary length, and as a connection-oriented, acknowledged, reliable protocol, automati-

cally provides the mechanisms we need to ensure that zone transfers and other lengthy

operations complete successfully. The cost is the small amount of overhead needed to

establish the connection, but since zone transfers are infrequent (compared to the sheer

volume of regular name resolutions) this is not a problem.

You can see how DNS nicely illustrates the roles of both TCP and UDP in TCP/IP. Since

both transport protocols can be used, name servers listen for both UDP and TCP requests

on the same well-known port number, 53. The device acting as the client uses an

ephemeral port number for the transaction. All DNS messages are sent unicast from one

device directly to another.

Key Concept: DNS uses both UDP and TCP to send messages. Conventional

message exchanges are “short and sweet” and thus well-suited to the use of the very

fast UDP; DNS itself handles the detection and retransmission of lost requests. For

larger or more important exchanges of information, especially zone transfers, TCP is

used—both for its reliability and its ability to handle messages of any size.

DNS Message Processing and General Message Format

The previous topic discussed DNS message exchanges and the fact that they are all based

on the principle of client/server computing. In a particular exchange, one device acts as a

client, initiating the communication by sending a query; the other acts as the server by

responding to the query with an answer. This “query/response” behavior is an integral part

of DNS, and is reflected in the format used for DNS messages.

A common message format is used for DNS queries and responses. This message format

contains five sections that provide a place for the query asked by the client; the answer(s)

provided by the server; and header information that controls the entire process. Table 169

describes the DNS general message format, providing a brief summary of each of its

sections and how they are used. You can also see a simplified illustration of the message

format in Figure 247.

Table 169: DNS General Message Format (Page 1 of 2)

Section Name Description

Header

Contains fields that describe the type of message and provide important infor-

mation about it. Also contains fields that indicate the number of entries in the other

sections of the message.

Question

Carries one or more “questions”, that is, queries for information being sent to a

DNS name server.

Header and Question Section

The Header is always present in all messages and is fixed in length. In addition to

containing important DNS control information, it has a flag (QR) that indicates whether a

message is a query or a response. It also has four “count” fields that tell the recipient the

number of entries in the other four sections.

Answer

Carries one or more resource records that answer the question(s) indicated in the

Question section above.

Authority

Contains one or more resource records that point to authoritative name servers that

can be used to continue the resolution process.

Additional

Conveys one or more resource records that contain additional information related

to the query that is not strictly necessary to answer the queries (questions) in the

message.

Figure 247: DNS General Message Format

Table 169: DNS General Message Format (Page 2 of 2)

Section Name Description

Header

(12 bytes)

Question

(variable)

Answer

(variable)

Authority

(variable)

Additional

(variable)

When a client initiates a query, it creates a message with the fields in the Header filled in,

and one or more queries (requests for information) in the Question section. It sets the QR

flag to 0 to indicate that this is a query, and places a number in the QDCount field of the

header that indicates the number of questions in the Question section. The number of

entries in the others sections are usually zero, so their “count” fields (ANCount, NSCount

and ARCount) are set to 0 in the header. (While more than one question can be put into a

query, usually only one is included.)

When the server receives the query it processes it and performs the information retrieval

operation requested (if it can). It then uses the query as the basis for its response message.

The Header and Question sections are copied to the response message, and the QR flag is

set to 1 to indicate that the message is a reply. Certain fields are also changed in the header

to provide information back to the client. For example, the server sets the RCode

(Response Code) field to indicate whether the query was successful or if an error occurred,

and if one did occur, to indicate what the problem was. The next topic shows all the Header

fields and indicates how each is used by both client and server.

Resource Record Sections: Answer, Authority and Additional

The server is also responsible for filling in the other three sections of the message: Answer,

Authority and Additional. These sections share the same basic format, each carrying one or

more resource records that use a common record format. The number of records in each

section is indicated using the “count” fields in the message header. The sections differ only

in terms of the types of records they carry. Answer records are directly related to the

question asked, while Authority records carry resource records that identify other name

servers. Authority records are thus the means by which name servers are hierarchically

“linked” when the server doesn't have the information the client requested.

The Additional section exists for the specific purpose of improving DNS efficiency. There

are cases where a server supplies an answer to a query that it has reason to believe will

lead to a subsequent question that the server can also answer. For example, suppose a

server provides the name of another name server in the Authority section (an NS resource

record). The client may not have the address for that server, which would mean it has to

perform an extra name resolution to contact the referenced server. If the server providing

the NS record already knows the IP address for this name server, it can include it in the

Additional section. The same goes for a server providing an MX record as I explained in the

topic on DNS mail support.

Key Concept: DNS uses a general message format for all messages. It consists of a

fixed 12-byte Header, a Question section that contains a query, and then three

additional sections that can carry resource records of different types. The Answer

section usually contains records that directly answer the Question of the message; the

Authority section holds the names of name servers being sent back to the client, and the

Additional section holds extra information that may be of value to the client, such as the IP

address of a name server mentioned in the Authority section.