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).
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
] typeRDATA
[class
] [TTL
] typeRDATA
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.
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.
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.
(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.
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.
(From RFC 1035, page 20)
(From RFC 1035, page 14)
owner ttl class
CNAMEcanonical-dname
wh.movie.edu. IN CNAME wormhole.movie.edu.
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.
(From RFC 1035, page 14)
owner ttl class
HINFOcpu os
grizzly.movie.edu. IN HINFO VAX-11/780 UNIX
HINFO type code: 13 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CPU Acharacter-string
which specifies the CPU type. OS Acharacter-string
which specifies the operating system type.
(From RFC 1035, page 17)
owner ttl class
MXpreference exchange-dname
ora.com. IN MX 0 ora.ora.com. IN MX 10 ruby.ora.com. IN MX 10 opal.ora.com.
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.
(From RFC 1035, page 18)
owner ttl class
NSname-server-dname
movie.edu. IN NS terminator.movie.edu.
NS type code: 2
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME Adomain-name
which specifies a host which
should be authoritative for the specified
class and domain.
(From RFC 1035, page 18)
owner ttl class
PTRdname
1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
PTR type code: 12
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PTRDNAME Adomain-name
which points to some location in
the domain name space.
(From RFC 1035, pages 19–20)
owner ttl class
SOAsource-dname mbox
(serial refresh retry expire minimum
)
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
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 Adomain-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.
(From RFC 1035, page 20)
owner ttl class
TXTtxt-strings
cujo.movie.edu. IN TXT "Location: machine room dog house"
TXT type code: 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / TXT-DATA / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: TXT-DATA One or more character-strings.
(From RFC 1035, page 21)
owner ttl class
WKSaddress protocol service-list
terminator.movie.edu. IN WKS 192.249.249.3 TCP ( telnet smtp ftp shell domain )
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.
owner ttl class
AFSDBsubtype hostname
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.
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.
owner ttl class
ISDNISDN-address sa
delay.hp.com. IN ISDN 141555514539488 hep.hp.com. IN ISDN 141555514539488 004
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 optionalcharacter-string
specifying the subaddress.
owner ttl class
RPmbox-dname txt-dname
; 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"
RP type code: 17 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MAILBOX / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / TXTDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MAILBOX Adomain-name
that specifies the mailbox for the responsible person. TXTDNAME Adomain-name
for which TXT RR's exist. A subsequent query can be performed to retrieve the associated TXT resource records at txt-dname.
owner ttl class
RTpreference intermediate-host
sh.prime.com. IN RT 2 Relay.Prime.COM. IN RT 10 NET.Prime.COM.
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.
owner ttl class
X25PSDN-address
relay.pink.com. IN X25 31105060845
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.
owner ttl class
PXpreference RFC822 address X.400 address
ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it.
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 containingrfc822-domain
, the RFC 822 part of the RFC 1327 mapping information. MAPX400 Adomain-name
element containing the value ofx400-in-domain-syntax
derived from the X.400 part of the RFC 1327 mapping information.
owner ttl class
SRVPriority Weight Port Target
_http._tcp.www.movie.edu. IN SRV 0 2 80 www.movie.edu.
SRV type code: 33 The RFC does not contain a diagram of the binary representation. Thepriority,
weight
, andport
are unsigned 16 bit integers. Thetarget
is a domain name.
owner ttl class
NAPTROrder Preference Flags Service RegExp Replacement
gatech.edu IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
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.
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.
(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.
(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.
(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.
(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
(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:
252 A request for a transfer of an entire zone
253 A request for mailbox-related records (MB, MG, or MR)
254 A request for mail agent RRs (obsolete—see MX)
255 A request for all records
(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.
(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.
In addition to two- and four-octet integer values, resource record data can contain domain names or character strings.
(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).
(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.
(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.