Appendix A. DNS Message Format and Resource Records

This appendix outlines the format of DNS messages and enumerates all the resource record types. The resource records are shown in their textual format, as you would specify them in a zone datafile, and in their binary format, as they appear in DNS messages. You’ll find a few resource records here that weren’t covered earlier because they are experimental or obsolete.

We’ve included the portions of RFC 1035, written by Paul Mockapetris, that deal with the textual format of master files (what we called zone data files in the book) or with the DNS message format (for those of you who need to parse DNS packets).

Master File Format

(From RFC 1035, pages 33–35)

The format of these files is a sequence of entries. Entries are predominantly line-oriented, though parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text. Any combination of tabs and spaces acts as a delimiter between the separate items that make up an entry. The end of any line in the master file can end with a comment. The comment starts with a semicolon (;).

The following entries are defined:

blank[comment]

$ORIGIN domain-name [comment]

$INCLUDEfile-name [domain-name] [comment]

domain-namerr [comment]

blankrr [comment]

Blank lines, with or without comments, are allowed anywhere in the file.

Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is followed by a domain name and resets the current origin for relative domain names to the stated name. $INCLUDE inserts the named file into the current file and may optionally specify a domain name that sets the relative domain name origin for the included file. $INCLUDE may also have a comment. Note that an $INCLUDE entry never changes the relative origin of the parent file, regardless of changes to the relative origin made within the included file.

The last two forms represent RRs. If an entry for an RR begins with a blank, the RR is assumed to be owned by the last stated owner. If an RR entry begins with a domain-name, the owner name is reset.

rr contents take one of the following forms:

[TTL] [class] type RDATA
[class] [TTL] type RDATA

The RR begins with optional TTL and class fields, followed by a type and RDATA field appropriate to the type and class. Class and type use the standard mnemonics; TTL is a decimal integer. Omitted class and TTL values default to the last explicitly stated values. Since type and class mnemonics are disjoint, the parse is unique.

domain-names make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names. Domain names that end in a dot are called absolute, and are taken as complete. Domain names that do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in an $ORIGIN, $INCLUDE, or argument to the master file-loading routine. A relative name is an error when no origin is available.

character-string is expressed in one of two ways: as a contiguous set of characters without interior spaces, or as a string beginning with " and ending with “. Inside a “-delimited string any character can occur, except for " itself, which must be quoted using a backslash ().

Because these files are text files, several special encodings are necessary to allow arbitrary data to be loaded. In particular:

.

Of the root.

@

A free-standing @ denotes the current origin.

X

Where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, . can place a dot character in a label.

DDD

Where each D is a digit in the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning.

( )

Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses.

;

A semicolon is used to start a comment; the remainder of the line is ignored.

Character Case

(From RFC 1035, page 9)

For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in seven-bit ASCII or use of special bytes to terminate labels, etc., should be avoided.

Types

Here is a complete list of resource record types. The textual representation is used in master files. The binary representation is used in DNS queries and responses. These resource records are described on pages 13–21 of RFC 1035.

A address

(From RFC 1035, page 20)

Textual Representation
owner ttl class A address
Example
localhost.movie.edu.   IN A 127.0.0.1
Binary Representation
Address type code: 1
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS         A 32 bit Internet address.

CNAME canonical name

(From RFC 1035, page 14)

Textual Representation
owner ttl class CNAME canonical-dname
Example
wh.movie.edu.  IN  CNAME  wormhole.movie.edu.
Binary Representation
CNAME type code: 5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     CNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME           Adomain-name which specifies the canonical
                or primary name for the owner.  The owner name is
                an alias.

HINFO host information

(From RFC 1035, page 14)

Textual Representation
owner ttl class HINFO cpu os
Example
grizzly.movie.edu.  IN  HINFO  VAX-11/780 UNIX
Binary Representation
HINFO type code: 13
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                      CPU                      /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                       OS                      /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CPU             Acharacter-string which specifies the CPU type.
OS              A character-string which specifies the
                operating system type.

MX mail exchanger

(From RFC 1035, page 17)

Textual Representation
owner ttl class MX preference exchange-dname
Example
ora.com.  IN  MX  0  ora.ora.com.
          IN  MX  10 ruby.ora.com.
          IN  MX  10 opal.ora.com.
Binary Representation
MX type code: 15
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGE                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE      A 16 bit integer which specifies the preference
                given to this RR among others at the same owner.
                Lower values are preferred.
EXCHANGE        Adomain-name which specifies a host willing
                to act as a mail exchange for the owner name.

NS name server

(From RFC 1035, page 18)

Textual Representation
owner ttl class NS name-server-dname
Example
movie.edu.  IN   NS  terminator.movie.edu.
Binary Representation
NS type code: 2
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   NSDNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME         Adomain-name which specifies a host which
                should be authoritative for the specified
                class and domain.

PTR pointer

(From RFC 1035, page 18)

Textual Representation
owner ttl class PTR dname
Example
1.249.249.192.in-addr.arpa.  IN PTR wormhole.movie.edu.
Binary Representation
PTR type code: 12
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   PTRDNAME                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME        Adomain-name which points to some location in
                the domain name space.

SOA start of authority

(From RFC 1035, pages 19–20)

Textual Representation
owner ttl class SOA source-dname mbox (serial refresh retry expire minimum)
Example
movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. (
                      1        ; Serial
                      10800    ; Refresh after 3 hours
                      3600     ; Retry after 1 hour
                      604800   ; Expire after 1 week
                      86400 )  ; Minimum TTL of 1 day
Binary Representation
SOA type code: 6
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     MNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     RNAME                     /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    SERIAL                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    REFRESH                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     RETRY                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    EXPIRE                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    MINIMUM                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MNAME           Thedomain-name of the name server that was the
                original or primary source of data for this zone.
RNAME           A domain-name which specifies the mailbox of the
                person responsible for this zone.
SERIAL          The unsigned 32 bit version number of the original
                copy of the zone.  Zone transfers preserve this
                value.  This value wraps and should be compared
                using sequence space arithmetic.
REFRESH         A 32 bit time interval before the zone should be
                refreshed.
RETRY           A 32 bit time interval that should elapse before
                a failed refresh should be retried.
EXPIRE          A 32 bit time value that specifies the upper limit
                on the time interval that can elapse before the
                zone is no longer authoritative.
MINIMUM         The unsigned 32 bit minimum TTL field that should
                be exported with any RR from this zone.

TXT text

(From RFC 1035, page 20)

Textual Representation
owner ttl class TXT txt-strings
Example
cujo.movie.edu.  IN  TXT  "Location: machine room dog house"
Binary Representation
TXT type code: 16
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   TXT-DATA                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
TXT-DATA        One or more character-strings.

WKS well-known services

(From RFC 1035, page 21)

Textual Representation
owner ttl class WKS address protocol service-list
Example
terminator.movie.edu.  IN  WKS 192.249.249.3  TCP ( telnet smtp
                                              ftp shell domain )
Binary Representation
WKS type code: 11
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |       PROTOCOL        |                       |
    +--+--+--+--+--+--+--+--+                       |
    |                                               |
    /                   BIT MAP                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS         An 32 bit Internet address.
PROTOCOL        An 8 bit IP protocol number.
BIT MAP         A variable length bit map.  The bit map must
                be a multiple of 8 bits long.

New Types from RFC 1183

AFSDB Andrew File System Data Base (experimental)

Textual Representation
owner ttl class AFSDB subtype hostname
Example
fx.movie.edu.  IN  AFSDB  1 bladerunner.fx.movie.edu.
               IN  AFSDB  2 bladerunner.fx.movie.edu.
               IN  AFSDB  1 empire.fx.movie.edu.
               IN  AFSDB  2 aliens.fx.movie.edu.
Binary Representation
AFSDB type code: 18
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   SUBTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   HOSTNAME                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
SUBTYPE         Subtype 1 is an AFS cell database server. Subtype 2
                is a DCE authenticated name server.
HOSTNAME        Adomain-name which specifies a host that has a
                server for the cell named by the owner of the RR.

ISDN Integrated Services Digital Network address (experimental)

Textual Representation
owner ttl class ISDN ISDN-address sa
Example
delay.hp.com.    IN  ISDN  141555514539488
hep.hp.com.      IN  ISDN  141555514539488 004
Binary Representation
ISDN type code: 20
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                 ISDN ADDRESS                  /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                  SUBADDRESS                   /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ISDN ADDRESS    Acharacter-string which identifies the ISDN number
                of owner and DDI (Direct Dial In) if any.
SUBADDRESS      An optional character-string specifying the
                subaddress.

RP Responsible Person (experimental)

Textual Representation
owner ttl class RP mbox-dname txt-dname
Example
; The current origin is fx.movie.edu
@            IN  RP   ajs.fx.movie.edu.   ajs.fx.movie.edu.
bladerunner  IN  RP   root.fx.movie.edu.  hotline.fx.movie.edu.
             IN  RP   richard.fx.movie.edu.  rb.fx.movie.edu.
ajs          IN  TXT  "Arty Segue, (415) 555-3610"
hotline      IN  TXT  "Movie U. Network Hotline, (415) 555-4111"
rb           IN  TXT  "Richard Boisclair, (415) 555-9612"
Binary Representation
RP type code: 17
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                    MAILBOX                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                    TXTDNAME                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MAILBOX         Adomain-name that specifies the mailbox for
                the responsible person.
TXTDNAME        A domain-name for which TXT RR's exist.  A
                subsequent query can be performed to retrieve
                the associated TXT resource records at
                txt-dname.

RT Route Through (experimental)

Textual Representation
owner ttl class RT preference intermediate-host
Example
sh.prime.com.  IN  RT  2   Relay.Prime.COM.
               IN  RT  10  NET.Prime.COM.
Binary Representation
RT type code: 21
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                 INTERMEDIATE                  /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE      A 16 bit integer which specifies the preference
                given to this RR among others at the same owner.
                Lower values are preferred.
EXCHANGE        Adomain-name which specifies a host which will
                serve as an intermediate in reaching the host
                specified by owner.

X25 X.25 address (experimental)

Textual Representation
owner ttl class X25 PSDN-address
Example
relay.pink.com.  IN  X25   31105060845
Binary Representation
X25 type code: 19
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                 PSDN ADDRESS                  /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PSDN ADDRESS    Acharacter-string which identifies the PSDN
                (Public Switched Data Network) address in the
                X.121 numbering plan associated with owner.

New Types from RFC 1664

PX pointer to X.400/RFC 822 mapping information

Textual Representation
owner ttl class PX preference RFC822 address X.400 address
Example
ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
Binary Representation
PX type code: 26
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                    MAP822                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                    MAPX400                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE   A 16 bit integer which specifies the preference given to
             this RR among others at the same owner.  Lower values
             are preferred.
MAP822       Adomain-name element containing rfc822-domain, the
             RFC 822 part of the RFC 1327 mapping information.
MAPX400      A domain-name element containing the value of
             x400-in-domain-syntax derived from the X.400 part of
             the RFC 1327 mapping information.

New Types from RFC 3596

AAAA IPv6 Address

Textual Representation
owner ttl class AAAA IPv6-address
Example
ipv6-host    IN    AAAA    4321:0:1:2:3:4:567:89ab
Binary Representation
AAAA type code: 28
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS         A 128 bit Internet address.

New Types from RFC 2782

SRV Locate Services

Textual Representation
owner ttl class SRV Priority Weight Port Target
Example
_http._tcp.www.movie.edu.  IN  SRV  0  2  80   www.movie.edu.
Binary Representation
SRV type code: 33

The RFC does not contain a diagram of the binary representation.  Thepriority,
weight, and port are unsigned 16 bit integers.  The target is a domain name.

New Types from RFC 2915

NAPTR Naming Authority Pointer

Textual Representation
owner ttl class NAPTR Order Preference Flags Service RegExp Replacement
Example
gatech.edu IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
Binary Representation
NAPTR type code: 35
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     ORDER                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   PREFERENCE                  |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     FLAGS                     /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   SERVICES                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                    REGEXP                     /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                  REPLACEMENT                  /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ORDER       A 16-bit unsigned integer specifying the order in which
            the NAPTR records MUST be processed to ensure the correct
            ordering of rules.
PREFERENCE  A 16-bit unsigned integer that specifies the order in
            which NAPTR records with equal "order" values SHOULD be processed,
            low numbers being processed before high numbers.
FLAGS       A <character-string> which contains various flags.
SERVICES    A <character-string> which contains protocol and service
            identifiers.
REGEXP      A <character-string> which contains a regular expression.
REPLACEMENT A <domain-name> which specifies the new value in the
            case where the regular expression is a simple replacement
            operation.

Classes

(From RFC 1035, page 13)

CLASS fields appear in resource records. The following CLASS mnemonics and values are defined:

IN

1: the Internet

CS

2: the CSNET class (obsolete—used only for examples in some obsolete RFCs)

CH

3: the CHAOS class

HS

4: the Hesiod class

DNS Messages

In order 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 two-byte value indicating the length of the query or response, excluding the two-byte length. The following sections detail the format and content of the DNS message.

Message Format

(From RFC 1035, page 25)

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

+---------------------+
|        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 remaining sections are present and specifies 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 nameserver. 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 nameserver, and the additional records section contains RRs that relate to the query but are not strictly answers for the question.

Header Section Format

(From RFC 1035, pages 26–28)

                                    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  |AA|TC|RD|RA|   Z    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID             A 16 bit identifier assigned by the program that
               generates any kind of query.  This identifier is copied
               the corresponding reply and can be used by the requester
               to match up replies to outstanding queries.
QR             A one bit field that specifies whether this message is a
               query (0), or a response (1).
OPCODE         A four bit field that specifies kind of query in this
               message.  This value is set by the originator of a query
               and copied into the response.  The values are:
               0               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 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 - 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:
               0               No error condition
               1               Format error - The name server was
                               unable to interpret the query.
               2               Server failure - The name server was
                               unable to process this query due to a
                               problem with the name server.
               3               Name Error - Meaningful only for
                               responses from an authoritative name
                               server, this code signifies that the
                               domain name referenced in the query does
                               not exist.
               4               Not Implemented - The name server does
                               not support the requested kind of query.
               5               Refused - The 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.

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 one) 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 (obsolete—see MX)

*

255 A request for all records

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, in which 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.

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 leftmost bit in the diagram is the high order, or most significant, bit. That is, the bit labeled 0 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 multioctet field represents a numeric quantity, the leftmost bit of the whole field is the most significant bit. When a multioctet quantity is transmitted, the most significant octet is transmitted first.

Resource Record Data

Data Format

In addition to two- and four-octet integer values, resource record data can contain domain names or character strings.

Character string

(From RFC 1035, page 13)

A character string is a single length octet followed by that number of characters. A character string is treated as binary information, and can be up to 256 characters in length (including the length octet).

Domain name

(From RFC 1035, page 10)

Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one-octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of 0. The high order two bits of every length octet must be 0, and the remaining 6 bits of the length field limit the label to 63 octets or less.

Message compression

(From RFC 1035, page 30)

In order to reduce the size of messages, the domain system uses a compression scheme that eliminates the repetition of domain names in a message. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name.

The pointer takes the form of a two-octet sequence:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1  1|                OFFSET                   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones. This allows a pointer to be distinguished from a label, since the label must begin with 2 zero bits because labels are restricted to 63 octets or less. (The 10 and 01 combinations are reserved for future use.) The OFFSET field specifies an offset from the start of the message (i.e., the first octet of the ID field in the domain header). A zero offset specifies the first byte of the ID field, etc.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset