Charles M. Kozierok The TCP-IP Guide

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

Note: The special Notify and Update messages use a different format than the

regular DNS query/response messages. These special messages (whose use is

described in the topic on DNS server enhancements) are based on the regular

format but with the meanings of certain fields changed. You can find these field formats in

RFC 1996 and RFC 2136 respectively.

DNS Message Header and Question Section Format

The client/server information exchange in DNS is facilitated using query/response

messaging. Both queries and responses have the same general format, containing up to

five individual sections carrying information. Of these, two are usually found in both queries

and responses: the Header section and the Question section. I will start exploring the

detailed format of DNS messages by looking at these two sections; the next topic will cover

the resource record formats used by servers for the other three message sections.

DNS Message Header Format

The header is the most important part of any message, since it is where critical control fields

are carried. In DNS messages, the Header section carries several key control flags, and is

also where we find out which of the other sections are even being used in the message.

Examining the Header can help us understand several of the nuances of how messaging

works in DNS.

The format of the Header section used in all DNS messages is described in detail in Tabl e

170 and shown in Figure 248. Where fields are used differently by the client and server in

an exchange, I have mentioned in the table how the use is differentiated between the two.

Table 170: DNS Message Header Format (Page 1 of 4)

Field Name

Size

(bytes)

Description

ID 2

Identifier: A 16-bit identification field generated by the device that creates

the DNS query. It is copied by the server into the response, so it can be

used by that device to match that query to the corresponding reply

received from a DNS server. This is used in a manner similar to how the

Identifier field is used in many of the ICMP message types.

1/8

(1 bit)

Query/Response Flag: Differentiates between queries and responses.

Set to 0 when the query is generated; changed to 1 when that query is

changed to a response by a replying server.

Opcode

1/2

(4 bits)

1/8

(1 bit)

Authoritative Answer Flag: This bit is set to 1 in a response to indicate

that the server that created the response is authoritative for the zone in

which the domain name specified in the Question section is located. If it is

0, the response is non-authoritative.

1/8

(1 bit)

Truncation Flag: When set to 1, indicates that the message was truncated

due to its length being longer than the maximum permitted for the type of

transport mechanism used. TCP doesn't have a length limit for messages,

while UDP messages are limited to 512 bytes, so this bit being sent usually

is an indication that the message was sent using UDP and was too long to

fit. The client may need to establish a TCP session to get the full message.

On the other hand, if the portion truncated was part of the Additional

section, it may choose not to bother.

1/8

(1 bit)

Recursion Desired: When set in a query, requests that the server

receiving the query attempt to answer the query recursively, if the server

supports recursive resolution. The value of this bit is not changed in the

response.

Table 170: DNS Message Header Format (Page 2 of 4)

Field Name

Size

(bytes)

Description

pera

pec

ifi

ype o

query

e message

s carry

ng.

Thi

field is set by the creator of the query and copied unchanged into the

response:

Opcode

Value

Query

Name

Description

0 QUERY A standard query.

1 IQUERY

An inverse query; now obsolete. RFC 1035 defines

the inverse query as an optional method for

performing inverse DNS lookups, that is, finding a

name from an IP address. Due to implementation

difficulties, the method was never widely deployed,

however, in favor of reverse mapping using the IN-

ADDR.ARPA domain. Use of this Opcode value was

formally obsoleted in RFC 3425, November 2002.

2 STATUS A server status request.

3 (reserved) Reserved, not used.

4 NOTIFY

A special message type added by RFC 1996. It is

used by a primary (master, authoritative) server to

tell secondary servers that data for a zone has

changed and prompt them to request a zone

transfer. See the discussion of DNS server enhance-

ments for more details.

5 UPDATE

A special message type added by RFC 2136 to

implement “dynamic DNS”. It allows resource

records to be added, deleted or updated selectively.

See the discussion of DNS server enhancements for

more details.

1/8

(1 bit)

Recursion Available: Set to 1 or cleared to 0 in a response to indicate

whether the server creating the response supports recursive queries. This

can then be noted by the device that sent the query for future use.

3/8

(3 bits)

Zero: Three reserved bits set to zero.

RCode

1/2

(4 bits)

QDCount 2

Question Count: Specifies the number of questions in the Question

section of the message.

ANCount 2

Answer Record Count: Specifies the number of resource records in the

Answer section of the message.

Table 170: DNS Message Header Format (Page 3 of 4)

Field Name

Size

(bytes)

Description

esponse

o zero

n quer

es,

en c

ange

e rep

server in a response to convey the results of processing the query. This

field is used to indicate if the query was answered successfully, or if some

sort of error occurred:

RCode

Value

Response

Code

Description

0 No Error No error occurred.

1 Format Error

The server was unable to respond to the query due

to a problem with how it was constructed.

2 Server Failure

The server was unable to respond to the query due

to a problem with the server itself.

3 Name Error

The name specified in the query does not exist in the

domain. This code can be used by an authoritative

server for a zone (since it knows all the objects and

subdomains in a domain) or by a caching server that

implements negative caching.

Not

Implemented

The type of query received is not supported by the

server.

5 Refused

The server refused to process the query, generally

for policy reasons and not technical ones. For

example, certain types of operations, such as zone

transfers, are restricted. The server will honor a

zone transfer request only from certain devices.

6 YX Domain A name exists when it should not.

7 YX RR Set A resource record set exists that should not.

8 NX RR Set A resource record set that should exist does not.

9 Not Auth

The server receiving the query is not authoritative for

the zone specified.

10 Not Zone

A name specified in the message is not within the

zone specified in the message.

Note that the current lists of valid question types, query operation codes and response

codes are maintained by IANA as one of its many lists of Internet parameters. Response

codes 0 to 5 are part of “regular” DNS and are defined in RFC 1035; codes 6 to 10

implement dynamic DNS and are defined in RFC 2136.

NSCount 2

Authority Record Count: Specifies the number of resource records in the

Authority section of the message. (“NS” stands for “name server”, of

course. ☺)

ARCount 2

Additional Record Count: Specifies the number of resource records in

the Additional section of the message.

Figure 248: DNS Message Header Format

Table 170: DNS Message Header Format (Page 4 of 4)

Field Name

Size

(bytes)

Description

Identifier Flags and Codes

Question Count Answer Record Count

Additional Record Count

4 8 12 16 20 24 28 320

Query/

Res -

ponse

Flag

(QR)

Operation Code

Author-

itative

An-

sw er

(AA)

Trun-

cation

Flag

(TC)

Rec ur -

sion

De-

sired

(RD)

Rec ur -

sion

Avail-

able

(RA)

Zero Response Code

18 20 22

26 28 30 3216

Name Server (Authority Record) Count

DNS Question Section Format

DNS queries always contain at least one entry in the Question section that specifies what

the client in the exchange is trying to find out. These entries are copied to the response

message unchanged, for reference on the part of the client if needed. Table 171 and Figure

249 show the format used for each entry in the Question section of a DNS message.

Figure 249: DNS Message Question Section Format

Table 171: DNS Message Question Section Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

QName Variable

Question Name: Contains the object, domain or zone name that is the

subject of the query, encoded using standard DNS name notation.

Question Name

Question Type Question Class

4 8 12 16 20 24 28 320

DNS Message Resource Record Field Formats

The exchange of information in DNS consists of a series of client/server transactions.

Clients send requests, or queries, to servers, and the servers send back responses. DNS

servers are of course database servers, and store DNS name database information in the

form of resource records (RRs). The questions asked by clients are requests for information

from a DNS's servers database, and they are answered by the DNS server looking up the

requested resource records and putting them into the DNS response message.

The Answer, Authority and Additional sections of the overall DNS message format are the

places where servers put DNS resource records to be sent back to a client. Each section

consists of zero or more records, and in theory, any record can be placed in any section.

The sections only differ in the semantics (meaning) that the client draws from a record

being in one section compared to the other. The topic on DNS general messaging contains

more on these three sections and how they are used.

Resource records have two representations: binary and text. The text format is used for

master files edited by humans, and is the subject of a topic later in this section. The binary

representation consists of regular numeric and text fields just like the other fields in the DNS

message format.

QType 2

QClass 2

Question Class: Specifies the class of the resource record being

requested, normally the value 1 for Internet (“IN”). See the topic on classes

and resource record types for an explanation. In addition, the QClass value

255 is defined to have the special meaning “any class”.

Table 171: DNS Message Question Section Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

ues

ype:

pec

ifi

ype o

ques

ng as

acting as a client. This field may contain a code number corresponding to a

particular type of resource record being requested—Table 167 contains the

numbers for the most common resource records. If so, this means the client

is asking for that type of record to be sent for the domain name listed in

QName. The QType field may also contain one of the following codes that

correspond to “special” types of requests:

QType

Value

Question

Type

Description

251 IXFR

A request for an incremental (partial) zone

transfer, per RFC 1995.

252 AXFR A request for a zone transfer.

253 MAILB

A request for mailbox-related records (resource

record types MB, MG or MR; now obsolete.)

254 MAILA

A request for mail agent resource records (now

obsolete; MX records are used instead).

255

(asterisk)

A request for all records.

DNS Common Resource Record Format

There are certain types of information that are common to all resource records, and others

that are unique to each type of record. To handle this, all resource records are represented

using a common field format, which contains a single RData field that varies by record type.

The common resource record format is described in Table 172 and Figure 250.

Table 172: DNS Common Resource Record Format

Field Name

Size

(bytes)

Description

Name Variable

Name: Contains the object, domain or zone name that is the subject of the

resource record, encoded using standard DNS name notation. All of the

information in the resource record is associated with this object, which I call

the named object for the record.

Type 2

Type: A code value specifying the type of resource record. The type values

for the most common kinds of resource records are shown in Table 167

and also in the list of resource record details in this topic.

Class 2

Class: Specifies the class of the resource record being requested,

normally the value 1 for Internet (“IN”). See the end of the topic on classes

and resource record types for an explanation.

TTL 4

Time To Live: Specifies the number of seconds that the record should be

retained in the cache of the device reading the record. See the topic on

DNS name server caching for a full explanation. A value of zero means

“use this information for the current name resolution only; do not cache it”.

RDLength 2 Resource Data Length: Indicates the size of the RData field, in bytes.

RData Variable Resource Data: The data portion of the resource record.

Figure 250: DNS Common Resource Record Format

Name

Type Class

Time To Live (TTL)

Resource Data Length

Resource Data

4 8 12 16 20 24 28 320

RData Field Formats For Common Resource Records

The RData field consists of one or more subfields that carry the actual “payload” for the

resource record. Below is a list of the most common resource record types. For each I have

indicated the resource record text code, name, and Type value, provided a brief summary of

the resource record’s use, and shown the structure of the RData field in a table:

A / Address Resource Record (Type Value 1)

This is the primary resource record type in DNS; it contains a 32-bit IP address associated

with a domain name, as shown in Table 173.

NS / Name Server Resource Record (Type Value 2)

In this record, the data field carries the domain Carries the domain name of a name server

(Table 174).

CName / Canonical Name Resource Record (Type Value 5)

The data field contains the real name of an a named object that has been referenced using

an alias (Table 175).

Table 173: DNS Address Resource Record Data Format

Subfield Name

Size

(bytes)

Description

Address 4

Address: The 32-bit IP address corresponding to this record's named

object.

Table 174: DNS Name Server Resource Record Data Format

Subfield Name

Size

(bytes)

Description

NSDName Variable

Name Server Domain Name: A variable-length name of a name server

that should be authoritative for this record's named object. Like all names,

this name is encoded using standard DNS name notation.

A request for this resource record type normally results in an A record for

the name server specified also being returned in the Additional section of

the response, if available.

Table 175: DNS Canonical Name Resource Record Data Format

Subfield Name

Size

(bytes)

Description

CName Variable

Canonical Name: The canonical (real) name of the named object. This

name is then resolved using the standard DNS resolution procedure to get

the address for the originally-specified name.

SOA / Start Of Authority Resource Record (Type Value 6)

This record marks the start of DNS zone and contains key information about how it is to be

managed and used. The SOA record is the most complex of the DNS resource record

types; its format can be found in Table 176 and also in Figure 251.

Table 176: DNS Start Of Authority Resource Record Data Format

Subfield Name

Size

(bytes)

Description

MName Variable

Master Name: The domain name of the name server that is the source of

the data for the zone; this is of course normally the primary authoritative

server for the zone. It is encoded using the standard DNS name format.

RName Variable

Responsible Name: The electronic mail address of the person respon-

sible for this zone. E-mail addresses in DNS are encoded using a special

variation of the regular DNS name notation.

Serial 4

Serial Number: The serial number, or version number, of the resource

record database for this zone. Used to determine when changes have

been made to the database to trigger zone transfers. See the topic on zone

transfers for information on how this field is used.

Refresh 4

Refresh Interval: The number of seconds that secondary name servers

for this zone will wait between attempts to check for changes made to the

zone database on the primary name server. See the topic on zone

transfers for information on how this field is used.

Retry 4

Retry Interval: The number of seconds a secondary name server waits

before trying again to check with a primary for changes if its previous

attempt failed. See the topic on zone transfers for details.

Expire 4

Expire Interval: The number of seconds that can elapse between

successful contacts with the primary name server before a secondary

name server must consider the information it holds “stale”.

Minimum 4

Negative Caching TTL: Originally carried the default Time To Live value

for records where no explicit TTL value was specified. Now represents the

zone’s negative cache TTL. See the topic on DNS name server caching.

PTR / Pointer Resource Record (Type Value 12)

This record carries a pointer to a resource record; used for reverse address lookups. It

contains one data field, shown in Table 177.

Figure 251: DNS Start Of Authority Resource Record Data Format

Table 177: DNS Pointer Resource Record Data Format

Subfield Name

Size

(bytes)

Description

PTRDName Variable

Pointer Domain Name: A variable-length domain name. This is a name

“pointed to” by the resource record; see the description of reverse

resolution for the most common way that this record type is used.

Name

Type Class

Time To Live (TTL)

Resource Data Length

Master Name

Responsible Name

Serial Number

Refresh Interval

Retry Interval

Expire Interval

Negative Caching TTL

4 8 12 16 20 24 28 320