• Tidak ada hasil yang ditemukan

Domain Name System Messages

Dalam dokumen TCP/IP Tutorial and Technical Overview (Halaman 177-181)

IP subnet routing

Chapter 4. Application Protocols

4.2 Domain Name System (DNS)

4.2.10 Domain Name System Messages

All messages in the Domain Name System protocol use a single format. This format is shown in Figure 110. This frame is sent by the resolver to the name server. Only the header and the question section are used to form the query.

Replies and/or forwarding of the query use the same frame, but with more sections filled in (the answer/authority/additional sections).

Identification Parameters

3376\3376FDO5 0 8 16 31

QDcount ANcount

NScount ARcount

/ /

Question Section

/ /

/ /

Answer Section

/ /

/ /

Authority Section

/ /

/ /

Additional Information Section

/ /

Figure 110. DNS - DNS Message Format

4.2.10.1 Header Format

The header section is always present and has a fixed length of 12 bytes. The other sections are of variable length.

ID A 16-bit identifier assigned by the program. This identifier is copied in the corresponding reply from the name server and can be used for differentiation of responses when multiple queries are outstanding at the same time.

Parameters

A 16-bit value in the following format:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Op code AA TC RD RA zero Rcode

QR

3376a\3376FDO4 Figure 111. Header Format: Parameters

QR Flag identifying a query (0) or a response(1) Op code

4-bit field specifying the kind of query:

0 standard query (QUERY)

1 inverse query (IQUERY)

2 server status request (STATUS) Other values are reserved for future use

AA Authoritative answer flag. If set in a response, this flag specifies that the responding name server is an authority for the domain name sent in the query.

TC Truncation flag. Set if message was longer than permitted on the physical channel.

RD Recursion desired flag. This bit signals to the name server that recursive resolution is asked for. The bit is copied to the response.

RA Recursion available flag. Indicates whether the name server supports recursive resolution.

zero

3 bits reserved for future use. Must be zero.

Rcode

4-bit response code. Possible values are:

0 No error.

1 Format error. The server was unable to interpret the message.

2 Server failure. The message was not processed because of a problem with the server.

3 Name error. The domain name in the query does not exist. This is only valid if the AA bit is set in the response.

4 Not implemented. The requested type of query is not implemented by name server.

5 Refused. The server refuses to respond for policy reasons.

Other values are reserved for future use.

QDcount An unsigned 16-bit integer specifying the number of entries in the question section.

ANcount An unsigned 16-bit integer specifying the number of RRs in the answer section.

NScount An unsigned 16-bit integer specifying the number of name server RRs in the authority section.

ARcount An unsigned 16-bit integer specifying the number of RRs in the additional records section.

4.2.10.2 Question Section

The next section contains the queries for the name server. It contains QDcount (usually 1) entries, each in the format shown in Figure 112.

3376\3376FDO6 0 8 16 24 31

length label 1. . .

/ / / /

00 . . .label n

type class

Figure 112. DNS - Question Format. All of the fields are byte-aligned. The alignment of the Type field on a 4-byte boundary is for example purposes and is not required by the format.

length A single byte giving the length of the next label.

label One element of the domain name characters (for example ibm from ral.ibm.com). The domain name referred to by the question is stored as a series of these variable length labels, each preceded by a 1-byte length.

00 X'00' indicates the end of the domain name and represents the null label of the root domain.

Type 2 bytes specifying the type of query. It can have any value from the Type field in a resource record.

Class 2 bytes specifying the class of the query. For Internet queries, this will be IN.

For example, the domain name raleigh.ibm.com would be encoded with the following fields:

X'ð7'

"raleigh"

X'ð3'

"ibm"

X'ð3'

"com"

X'ðð'

Thus the entry in the question section for raleigh.ibm.com would require 21 bytes:

17 to store the domain name and 2 each for the Qtype and Qclass fields.

4.2.10.3 Answer, Authority and Additional Resource Sections

These three sections contain a variable number of resource records. The number is specified in the corresponding field of the header. The resource records are in the format shown in Figure 113.

/ / / /

3376\3376FDO8 0 8 16 24 31

length label . . .

/ / / /

00 . . .label

type class

TTL RDlength

Rdata

Figure 113. DNS - Answer Record Entry Format. All of the fields are byte-aligned. The alignment of the Type field on a 4-byte boundary is for example purposes and is not required by the format.

Where the fields before the TTL field have the same meanings as for a question entry and:

TTL A 32-bit time-to-live value in seconds for the record. This defines how long it can be regarded as valid.

RDlength A 16-bit length for the Rdata field.

Rdata A variable length string whose interpretation depends on the Type field.

4.2.10.4 Message Compression

In order to reduce the message size, a compression scheme is used to eliminate the repetition of domain names in the various RRs. Any duplicate domain name or list of labels is replaced with a pointer to the previous occurrence. The pointer has the form of a 2-byte field:

1 1 offset

Ÿ The first 2 bits distinguish the pointer from a normal label, which is restricted to a 63-byte length plus the length byte ahead of it (which has a value of <64).

Ÿ The offset field specifies an offset from the start of the message. A zero offset specifies the first byte of the ID field in the header.

Ÿ If compression is used in an Rdata field of an answer, authority or additional section of the message, the preceding RDlength field contains the real length after compression is done.

Please refer to 7.3, “Dynamic Domain Name System” on page 414 for additional message formats.

Dalam dokumen TCP/IP Tutorial and Technical Overview (Halaman 177-181)