A.2 DNS Messages

Team-Fly    

 
DNS on Windows 2000, 2nd Edition
By Matt Larson, Cricket Liu
Table of Contents
Appendix A.  DNS Message Format and Resource Records

A.2 DNS Messages

To write programs that parse DNS messages, you need to understand the message format. DNS queries and responses are most often contained within UDP datagrams. Each message is fully contained within a UDP datagram. If the query and response are sent over TCP, they are prefixed with a 2-byte value indicating the length of the query or response, excluding the 2-byte length. The format and content of the DNS message are as follows .

A.2.1 Message Format

(From RFC 1035, page 25)

All communications inside of the domain protocol are carried in a single format called a message. The top level format of the message is divided into 5 sections (some of which are empty in certain cases), shown below:

 +---------------------+             Header            +---------------------+            Question       the question for the name server     +---------------------+             Answer        RRs answering the question     +---------------------+           Authority       RRs pointing toward an authority     +---------------------+           Additional      RRs holding additional information     +---------------------+ 

The Header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query or a response, a standard query or some other opcode, etc.

The names of the sections after the header are derived from their use in standard queries. The Question section contains fields that describe a question to a name server. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The Answer section contains RRs that answer the question; the Authority section contains RRs that point toward an authoritative name server; and the Additional records section contains RRs which relate to the query, but are not strictly answers for the question.

A.2.2 Header Section Format

(From RFC 1035, pages 26-28)

The header contains the following fields:

 1  1  1  1  1  1       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                           ID                            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+     QR   Opcode  AATCRDRA   Z       RCODE        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                         QDCOUNT                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                         ANCOUNT                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                         NSCOUNT                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                         ARCOUNT                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

where:

ID

A 16 bit identifier assigned by the program which generates any kind of query. This identifier is copied into the corresponding reply and can be used by the requester to match up replies to outstanding queries.

QR

A one bit field which specifies whether this message is a query (0), or a response (1).

OPCODE

A four bit field which specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. The values are:

A standard query (QUERY)

1

An inverse query (IQUERY)

2

A server status request (STATUS)

3-15

Reserved for future use

AA (Authoritative Answer)

This bit is valid in responses, and specifies that the responding name server is an authority for the domain name in the Question section. Note that the contents of the Answer section may have multiple owner names because of aliases. The AA bit corresponds to the name which matches the query name, or the first owner name in the Answer section.

TC (TrunCation)

This bit specifies that this message was truncated due to length greater than that permitted on the transmission channel.

RD (Recursion Desired)

This bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional.

RA (Recursion Available)

This bit is set or cleared in a response, and denotes whether recursive query support is available in the name server.

Z

Reserved for future use. Must be zero in all queries and responses.

RCODE (Response Code)

This 4 bit field is set as part of responses. The values have the following interpretation:

No error condition

1

Format ErrorThe name server was unable to interpret the query.

2

Server FailureThe name server was unable to process this query due to a problem with the name server.

3

Name ErrorMeaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.

4

Not ImplementedThe name server does not support the requested kind of query.

5

RefusedThe name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data.

6-15

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 resource records in the Answer section.

NSCOUNT

An unsigned 16 bit integer specifying the number of name server resource records in the Authority records section.

ARCOUNT

An unsigned 16 bit integer specifying the number of resource records in the Additional records section.

A.2.3 Question Section Format

(From RFC 1035, pages 28-29)

The Question section is used to carry the "question" in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format:

 1  1  1  1  1  1       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                                                         /                     QNAME                     /     /                                               /     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                          QTYPE                          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                          QCLASS                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

where:

QNAME

A domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root. Note that this field may be an odd number of octets; no padding is used.

QTYPE

A two octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field, together with some more general codes which can match more than one type of RR.

QCLASS

A two octet code that specifies the class of the query. For example, the QCLASS field is IN for the Internet.

QCLASS values (From RFC 1035, page 13)

QCLASS fields appear in the Question section of a query. QCLASS values are a superset of CLASS values; every CLASS is a valid QCLASS. In addition to CLASS values, the following QCLASS is defined:

*

255 Any class

QTYPE values (From RFC 1035, pages 12-13)

QTYPE fields appear in the Question part of a query. QTYPES are a superset of TYPEs, hence all TYPEs are valid QTYPEs. Also, the following QTYPEs are defined:

AXFR

252 A request for a transfer of an entire zone

MAILB

253 A request for mailbox- related records (MB, MG, or MR)

MAILA

254 A request for mail agent RRs (obsoletesee MX)

*

255 A request for all records

A.2.4 Answer, Authority, and Additional Section Format

(From RFC 1035, pages 29-30)

The Answer, Authority, and Additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format:

 1  1  1  1  1  1       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                                                         /                                               /     /                      NAME                     /                                                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                           TYPE                          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                          CLASS                          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                           TTL                                                                               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+                        RDLENGTH                         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--     /                     RDATA                     /     /                                               /     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

where:

NAME

A domain name to which this resource record pertains.

TYPE

Two octets containing one of the RR type codes. This field specifies the meaning of the data in the RDATA field.

CLASS

Two octets which specify the class of the data in the RDATA field.

TTL

A 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached.

RDLENGTH

An unsigned 16 bit integer that specifies the length in octets of the RDATA field.

RDATA

A variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. For example, if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address.

A.2.5 Data Transmission Order

(From RFC 1035, pages 8-9)

The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.

 0                   1      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            1              2            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            3              4            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            5              6            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Whenever an octet represents a numeric quantity, the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled zero is the most significant bit. For example, the following diagram represents the value 170 (decimal).

 0 1 2 3 4 5 6 7     +-+-+-+-+-+-+-+-+     1 0 1 0 1 0 1 0     +-+-+-+-+-+-+-+-+ 

Similarly, whenever a multi-octet field represents a numeric quantity, the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.


Team-Fly    
Top


DNS on Windows 2000
DNS on Windows 2000
ISBN: 0596002300
EAN: 2147483647
Year: 2001
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net