DNS Evasion Techniques and
Beyond
Prepared by:
Judy Novak
Senior SecurityAnalyst
On Behalf of Enterasys Networks
February 22, 2001
.
.
.
.
.
.
.
.
.
Table of Contents
SIDESTEP DNS OVERVIEW .......................................................................................1
THE DNS QUERY .........................................................................................................2
Forming a DNS Query.................................................................................................................................................. 2
A Normal DNS Query .................................................................................................................................................. 2
Sidestep’s Evasive Query ............................................................................................................................................. 4
UDP Worst Case Scenario ........................................................................................................................................... 5
TCP and DNS ................................................................................................................................................................ 6
TCP Worst Case Scenario ........................................................................................................................................... 7
Sidestep’s False Positive Query ................................................................................................................................... 7
The Bottom Line ............................................................................................................................................................ 8
RFC 1035 – DOMAIN NAMES – IMPLEMENATION AND SPECIFICATION ..........9
2
1
Sidestep DNS Overview
This paper begins by examining the techniques used in Robert Graham’s sidestep tool to evade
detection of DNS queries by conventional intrusion detection search methods. Sidestep is a tool that
can send SNMP, RPC, DNS, HTTP, FTP, and Back Orifice traffic that is normal, evasive, and likely to
generate a false positive from some intrusion detection systems. More information about sidestep can
be found at www.robertgraham.com/tmp/sidestep.html. The examination of sidestep provided the
catalyst to consider how detrimental these and other DNS evasive tactics could be. The insight gained
from this study will be discussed in this paper too.
If you’ve ever monitored a mailing list associated with intrusion detection for any length of time, you’ve
no doubt some across the derisive term “network grep” in reference to an IDS string search
mechanism. This derogatory reference suggests that the IDS in question will look for an occurrence of
a string in the packet much as the Unix grep searches for an occurrence of a string in a file or some
text. The implication is that the IDS has no built-in “smarts” for discerning that the string appears in the
proper context to warrant an alert. The result is that the IDS may often generate false positives
alarming on conditions that are not truly noteworthy or more harmfully; the IDS may miss truly malicious
traffic if it is not intelligent enough to understand the string especially when examined in context of the
application layer. This is what sidestep tries to demonstrate.
The key points of this discussion are:

There is no static signature that can be used to detect sidestep’s evasive DNS techniques; some
type of DNS question decode program must be employed to properly interpret DNS questions.

The security threat that is posed by this evasive technique is low. DNS queries, in and of
themselves, usually do not constitute much of a threat. The most invasive of DNS queries is a
zone transfer request. Well-configured DNS servers can prevent against unauthorized zone
transfers and a packet-filtering device can offer further protection by providing a perimeter
impediment against such queries. Another potentially invasive query is for the version of BIND.
This is the query that sidestep uses to attempt to generate an evasive string that may elude some
intrusion detection signatures.

The denial of service threat posed by this evasive technique is low. While an isolated DNS
question can be crafted that may consume additional time for resolution, the size restriction for the
DNS payload of 512 bytes prevents resource exhaustion. In addition, TCP DNS queries will be
examined; but they too seem to have a limited capacity for denial of service attacks.
2
The DNS Query
Forming a DNS Query
In this initial discussion, traffic to UDP port 53 – the domain or DNS server port will be examined. TCP
destination port 53 carries DNS zone transfer records or a subsequent query for previously truncated
UDP queries with a payload of greater than 512 bytes. TCP port 53 will be discussed later.
When a DNS query is generated, some of the pertinent fields for inspection are the DNS flag bytes, the
DNS question and the DNS type and class. See Appendix A for additional information and relevant
excerpts from RFC 1035 entitled “Domain Names – Implementation and Specification”. The flags field
basically tells whether this is a DNS query or response along with other information. The DNS question
is the actual query for which some type of DNS resolution is sought. Finally, the DNS message type
and class further refine what type of resolution is sought such as IP address, mail exchange (MX), to
name a few.
A Normal DNS Query
Let’s use the traffic that is generated using sidestep’s normal option with DNS to formulate a UDP
query for the version of BIND (Berkeley Internet Name Daemon) to demonstrate how a typical DNS
query is formatted. Much as the name implies a query for the version of BIND returns the DNS server’s
version of BIND, if this type of query is permitted. This is a valuable piece of information for an attacker
to have since she/he can then pair the version of BIND with all known exploits and attempt to attack the
server. Another possible way to generate this query besides sidestep is by using the dig (domain
internet groper) command:
dig@dns.server version.bind txt chaos
where dns.server is the name of the DNS server to be queried.
It would be wise to consider disabling the version of BIND so as not to leak this information. BIND
versions 8.x have an options keyword that can do this. One of the ways that this can be done is by
altering the named.conf file as follows:
options {
version "version unavailable";
};
You can put whatever text you feel is appropriate in the message that is displayed. Some sites
even reply with the wrong version of BIND just to see what ensuing attack may look like after an
unauthorized query for the version of BIND.
2
Let’s examine the output that was generated by tcpdump from the sidestep command. This is
displayed in normal tcpdump output followed by hexadecimal to understand the context of the activity.
12:39:30.027400 10.100.100.201.1128 > DNS.SERVER.domain: 10+ TXT CHAOS)? version.bind.
(30)
4500 003a 052c 0000 8011 c056 0a64 64c9
0a64 6402 0468 0035 0026 6325 <000a 0100
0001 0000 0000 0000 0776 6572 7369 6f6e
0462 696e 6400 0010 0003>
E..:.,.....V.dd.
.....h.5.&c%....
.........version
.bind.....
First you see the standard tcpdump display output of host 10.100.100.201 querying
DNS.SERVER on UDP port 53 (domain) with a DNS identification number of 10 and with
recursion desired (+) for a TXT type record and a CHAOS class record of version.bind.
Now, let’s examine the hexadecimal output of the actual DNS record to become familiar with the
way that questions are formed. The DNS portion of this packet has been delimited with the < > to
easily identify the part of the record we will scrutinize. Here is the breakdown of the DNS fields.
Bytes
Value
Explanation
0-1
000a
Identification number to pair queries and
responses
DNS flags field, signals that this is a query and is recursion
desired
Number of queries
Number of answer resource records (RR’s)
Number of authoritative RR’s
Number of additional RR’s
2-3
0100
4-5
6-7
8-9
10-11
0001
0000
0000
0000
12-25
0776 6572 7369 6f6e 0462 696e 6400
26-27
28-29
0010
0003
Query name*
Query type – above type is TXT
Query class – above class is CHAOS
*Query name format:
DNS questions have a prescribed format. A DNS question has a series of nodes that end in a 00
to form the question. We typically see nodes that are separated by periods when we express a
hostname or IP address. For instance, if an IP address resolution were desired for
www.yahoo.com, the DNS question that would be generated would treat the name as a series of
nodes - www, yahoo, and com. Preceding each node is a byte count that tells how many bytes in
the following node.
The version.bind question that was generated using sidestep’s normal option is:
0776 6572 7369 6f6e 0462 696e 6400
The highlighted bolded bytes represent labels. The first label is 07; this means that there should
be 7 bytes in the first node of the query. In this instance, the hex characters that follow represent
the ASCII representation of the node “version”. Next, you see a label of 04 meaning that there
3
are 4 bytes in the following node, which is the hex representation of the ASCII “bind”. A 0 label
ends the query, which is the final label that is seen.
As mentioned earlier, each question requires a DNS type and class; each of these is a 2-byte
field. The various different types and classes can be found in RFC 1035, but for the purposes of
the BIND version query, these must be a type of TXT represented by a 16 (or hex 0010) and a
class of CHAOS represented as a 3 (or hex 0003).
An accessible DNS server that does not prevent version.bind queries will respond to the above
query with the version of BIND that is running.
Sidestep’s Evasive Query
The traffic that is generated using sidestep’s evade option with DNS formulates a UDP query for the
version of BIND, but uses pointers instead of labels in the query. A pointer is a mechanism used in
responses to reduce redundancies in the query response and shorten the response. This will be
discussed in more detail when we examine the packet. This evasion, as with most the sidestep ones,
is able to elude detection by code that doesn’t do any DNS application decode. If the intrusion
detection software simply inspects the packet for a payload content of a normal version of BIND query 0776 6572 7369 6f6e 0462 696e 64; it will not identify the evasive technique used by sidestep.
Let’s examine the output that was generated by tcpdump displayed in hexadecimal to understand the
evasive activity.
12:39:56.674320 10.100.100.201.1129 > DNS.SERVER.domain:
4500 003c 0577 0000
0a64 6402 0469 0035
0001 0000 0000 0000
c01a 0010 0003 0442
|
|
|
|
V
V
Pointer 26
26 Bytes
bytes into DNS
Payload
8011
0028
0756
494e
c009 0a64 64c9
e445 <002a 0000
6572 7369 6f6e
4400>
42 (32)
E..<.w.......dd.
.....i.5.(.E.*..
.........Version
.......BIND.
Let’s look at the query name (in bold) to see the evasion used. The name starts, as before, with
a label of 07 followed by the first node of the query. We see what had previously been all
lowercase letters in “version” now is “Version”. This would successfully elude any string matching
software that does not do uppercase/lowercase conversions.
But, that is not the entirety of the ruse used here. Look at the next byte – c0. A label has a
maximum value of 63 and a hexadecimal c0 is 192 when converted to decimal. Any time that a
label has the two high-order bits of the byte set to 1, it is considered a pointer. A pointer is the
number of bytes into the DNS message where the next label (or pointer) is to be found. In this
case, we see that the pointer is a hexadecimal 1a or a decimal 26. Therefore, we have to count
26 bytes from the beginning of the DNS message to find the next node. The DNS message is
delimited between the < > on the left side of the output.
Moving 26 bytes into the DNS message directs us to the string beginning with 0442 494e 4400.
The 04 is the label 26 bytes into the DNS message and as expected, it is followed by 4 bytes that
represent the string “bind”. The query then ends when a label of 00 is encountered. It appears
that resolution of the query resumes at the next byte after the first pointer in the query name.
4
This brings us back to the string “0010 0003” that represents the query type of TXT and a query
class of CHAOS. This query will elicit the version of BIND running on the queried DNS server if
the DNS server does not prevent queries for the version of BIND.
UDP Worst Case Scenario
It appears that this evasive technique is limited and can be detected and contained using some
simple well-devised code to do partial application decode that looks for and handles pointers in
the queries. These queries are UDP-based and queries and responses are restricted to a
maximum of 512 bytes in the payload.
However, understand that a malicious crafter may try to create some unique pointers that the
DNS decode will have to deal with. DNS itself will respond with a format error to any question
that has a pointer loop. For instance, take a look at the following hexadecimal output of DNS
payload alone:
002a 0000 0001 0000 0000 0000 0756 6572 7369 6f6e c01a 0010 0003 c014
0
2
4
6
8
10
12
14
16
18
20
22
24
26 (byte count)
Specifically, let’s examine the question beginning at the bolded text.
0756 6572 7369 6f6e
c01a
A label of 7 followed by Version
A pointer pointing 26 bytes into the payload
26 bytes into the payload, we find c014, that points 20 bytes into the payload. This brings us
back to the c01a pointer that means we have an endless loop. Fortunately, DNS will respond
with a pointer loop format error message to this attempted query.
Because the maximum DNS payload length is 512 bytes, that means that we can only exhaust a
finite number of resources using pointer to pointer crafting before a loop is detected or an actual
question if formatted. Examine the DNS payload below to see a query that results in successfully
soliciting the version of BIND from a server. You will see that the question begins normally with a
label of 07 and a node of the hexadecimal representation of “Version” in ASCII. Following this,
you see an initial pointer that points 26 bytes into the payload where you find another pointer,
c01c. After this is a series of pointers pointing to pointers until close to the maximum 512 byte
payload, there is label of 04 and a node of the hexadecimal representation of ”bind” in ASCII.
The final label is a 00 that ends that question, but resolution is continued after the first pointer to
discover the DNS type and class, in this case the 0010 and 0003 designate type TXT and class
CHAOS.
5
002a
c020
c03e
c05c
c07a
c098
c0b6
c0d4
c0f2
c110
c12e
c14c
c16a
c188
c1a6
c1c4
c1e2
4400
0000
c022
c040
c05e
c07c
c09a
c0b8
c0d6
c0f4
c112
c130
c14e
c16c
c18a
c1a8
c1c6
c1e4
0001
c024
c042
c060
c07e
c09c
c0ba
c0d8
c0f6
c114
c132
c150
c16e
c18c
c1aa
c1c8
c1e6
0000
c026
c044
c062
c080
c09e
c0bc
c0da
c0f8
c116
c134
c152
c170
c18e
c1ac
c1ca
c1e8
0000
c028
c046
c064
c082
c0a0
c0be
c0dc
c0fa
c118
c136
c154
c172
c190
c1ae
c1cc
c1ea
0000
c02a
c048
c066
c084
c0a2
c0c0
c0de
c0fc
c11a
c138
c156
c174
c192
c1b0
c1ce
c1ec
0756
c02c
c04a
c068
c086
c0a4
c0c2
c0e0
c0fe
c11c
c13a
c158
c176
c194
c1b2
c1d0
c1ee
6572
c02e
c04c
c06a
c088
c0a6
c0c4
c0e2
c100
c11e
c13c
c15a
c178
c196
c1b4
c1d2
c1f0
7369
c030
c04e
c06c
c08a
c0a8
c0c6
c0e4
c102
c120
c13e
c15c
c17a
c198
c1b6
c1d4
c1f2
6f6e
c032
c050
c06e
c08c
c0aa
c0c8
c0e6
c104
c122
c140
c15e
c17c
c19a
c1b8
c1d6
c1f4
c01a
c034
c052
c070
c08e
c0ac
c0ca
c0e8
c106
c124
c142
c160
c17e
c19c
c1ba
c1d8
c1f6
0010
c036
c054
c072
c090
c0ae
c0cc
c0ea
c108
c126
c144
c162
c180
c19e
c1bc
c1da
c1f8
0003
c038
c056
c074
c092
c0b0
c0ce
c0ec
c10a
c128
c146
c164
c182
c1a0
c1be
c1dc
c1fa
c01c
c03a
c058
c076
c094
c0b2
c0d0
c0ee
c10c
c12a
c148
c166
c184
c1a2
c1c0
c1de
0442
c01e
c03c
c05a
c078
c096
c0b4
c0d2
c0f0
c10e
c12c
c14a
c168
c186
c1a4
c1c2
c1e0
494e
TCP and DNS
As mentioned earlier, TCP port 53 is used in two different situations. The first is when a UDP DNS
query has a payload of greater than 512 bytes. In this instance, the original query will have to re-issued
using TCP port 53. The second situation where TCP port 53 is used is for zone transfers. Are the
same evasive techniques available using TCP? It turns out that they are. TCP port 53 with a payload
of embedded pointers can be used for querying the version of BIND, for zone transfers and for other
queries that are typically made using UDP port 53.
The only difference in the format of the payload for a TCP query from a UDP query is that a TCP query
will have an additional two initial bytes in the payload. These bytes represent the number of bytes that
follow in the query.
Let’s look at the payload for a zone transfer using TCP port 53.
001e 245a 0100 0001 0000 0000 0000 0870 7265 7373 636f 6d03 6e65 7400 00fc 0001
Rather than rehashing the breakdown of the payload since it is almost that same as UDP, let’s examine
some of the fields that are different.
Value
Explanation
001e
Length of query to follow (30 bytes)
245a 0100 0001 0000 0000 0000 0870 7265 7373 636f 6d03 6e65 7400
Query for presscom.net
Query type – zone transfer
Query class - Internet
00fc
0001
6
Now, let’s look at this same query using pointers as an evasive tactic.
0020 245a 0100 0001 0000 0000 0000 0870 7265 7373 636f 6dc0 1b00 fc00 0103 6e65 7400
0
2
4
6
8
a
c
d
10
12 14
16
18 1a
1c
1e
(byte count)
We see that the byte count has changed from 0x1e (30) to 0x20 (32) to accommodate two additional
bytes. We have all the same beginning bytes that denote the DNS identification number, flags, query
and responses numbers and then we see the initial node of presscom as represented in hex (0870
7265 7373 636f 6d). The highlighted bytes represent the pointer to displacement 0x1b that points to
the final node of com (03 6e65 74). The resolution returns to the bytes after the first pointer, which are
00fc 0001 for a type of zone transfer and a class of Internet. This returns all the records from the DNS
server associated with presscom.net. One thing to note about the displacement or pointer values is
that the counting starts after the initial 2-byte length value.
Now that we understand that TCP can be used to send evasive traffic, what should we be concerned
about? We need to look for any signature that we would using UDP and we should be able to detect
zone transfers as well. The obvious DNS field to key on for detecting zone transfers would be the
message type of 00fc, but if we try to anchor this with any portion of the DNS query, we must be able to
strip out the pointers before analyzing the traffic.
TCP Worst Case Scenario
The initial suspicion was that by concocting a TCP query using the maximum number of pointers and
iteratively issuing this query, we could wreak havoc on the DNS servers. Fortunately, for you defenders
of networks, this was not the case.
The limitation for the TCP payload size is the pointer size. The pointer is a 2-byte field and the two
high-order bits are reserved to distinguish a pointer from a label. Therefore, the maximum number of
bytes displacement that we can represent is 214 - 1 or 16383. When a packet was crafted to do the
same zone transfer using the maximum number of pointers and directed against a test DNS server
running BIND 8.2.1, the response for the zone transfer was immediate. In other words, this seemed to
have no impact on the ability of the DNS server to respond.
This same query was put into a loop and directed against the DNS server for 100 million queries. The
DNS server was still able to answer the zone transfers and additionally, answer queries directed to it at
this same time with no noticeable degradation in response time. Finally, this same looping process
was replicated on the same sending host four more times and directed to the same DNS server.
Again, there was no observable performance degradation in response time for queries. Similar tests
were performed against BIND 4.9.7 with the same results; there appeared to be no empirical signs of
any type of denial of service against the DNS server.
It should be noted that the DNS servers used were strictly test hosts used in a lab environment. That
said; results might vary with a production DNS under heavy load. While we have deemed that these
tests did not present a denial of service threat, as with any protocol, if enough packets are generated
from enough sources, a denial of service is inevitable.
Sidestep’s False Positive Query
A final option for sidestep traffic is to generate a DNS query that is likely to set off a false positive alert
for a version of BIND query although there really is no such query.
7
12:40:06.669947
10.100.100.201.1130
version.bind.robertgraham.com. (47)
4500
0a64
0001
0462
616d
004b
6402
0000
696e
0363
0578
046a
0000
640c
6f6d
0000
0035
0000
726f
0000
8011
0037
0776
6265
0100
bff9
7ca5
6572
7274
01>
>
0a64 64c9
<000b 0100
7369 6f6e
6772 6168
DNS.SERVER:
11+
E..K.x.......dd.
.....j.5.7|.....
.........version
.bind.robertgrah
am.com.....
The question generated looks for an address association for version.bind.robertgraham.com. If
an intrusion detection system simply does a “network grep” for the string 0776 6572 7369 6f6e
0462 696e 64, it will falsely alert on a query for the version of BIND. Another difference between
this question and the real version of BIND query is the DNS message type and class. Both the
type and class are a hexadecimal 0001 – which is an IP address lookup for the Internet class.
The Bottom Line
So what does the sidstep evasion accomplish in terms of IDS signatures? The use of pointers as
an evasive technique means that we cannot reduce the signature for this activity to a known
predictable string. It is possible to manipulate this activity to have pointers to other pointers and
eventually point to a label, or pointers to labels followed by more pointers. What this means is that
there must be at least some kind of partial decode of DNS query name formulation to discover
this evasive technique. It is no longer enough to have a static string that can discover this
particular evasive query as well as other evasive queries that rely on the use of pointers.
What we can almost assuredly deduce is that if there is a pointer used in a query, it is an evasive
maneuver of some sort. Queries do not use pointers as a rule since it appears that even though
there is a field for the number of queries, only one query at a time is found in a DNS message.
Attempts to generate multiple queries per DNS message failed. Therefore, there is no legitimate
use of a pointer in a question name since there is no prior reference of a node to which the
pointer could point.
Ideally, the DNS decode software should examine:



A DNS query only (other DNS flag bit settings don’t seem to have any effect on the
response outcome)
Pointers
o They must point to a byte within the range of the beginning of the DNS payload
and the end of the DNS payload
o They must not repeat (this is indicative of a pointer loop)
o They can point either backward or forward
o They can point to other pointers or other labels
o There should be a finite number of pointers that will be tolerated after which, the
software will warn of an evasive tactic and exit; the software should not become
consumed in a resource exhausting task.
The message type and class
o Found after the final label (00) for queries that do not have pointers
o Found after the first pointer for queries that do have pointers
Bear in mind that ultimately, there will have to be a properly formatted DNS question; otherwise
the only possible response from the DNS server will be a format error.
8
A?
Appendix
A
RFC 1035 – Domain Names – Implementation and Specification
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 |AA|TC|RD|RA|
Z
|
RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QDCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ANCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
NSCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ARCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID
QR
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.
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
TC
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.
Truncation - specifies that this message was truncated
9
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 be 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
10
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 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.
Message compression
In order to reduce the size of messages, the domain system utilizes a compression
scheme which 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 two 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.
The compression scheme allows a domain name in a
message to be represented as either:
- a sequence of labels ending in a zero octet
11
- a pointer
- a sequence of labels ending with a pointer
Pointers can only be used for occurrences of a domain name where the format is not
class specific. If this were not the case, a name server or resolver would be required
to know the format of all RRs it handled. As yet, there are no such cases, but they
may occur in future RDATA formats.
If a domain name is contained in a part of the message
subject to a length field (such as the RDATA section of
an RR), and compression is
used, the length of the compressed name is used in the
length calculation, rather than the length of the
expanded name.
Programs are free to avoid using pointers in messages they generate, although this
will reduce datagram capacity, and may cause truncation. However all programs are
required to understand arriving messages that contain pointers.
For example, a datagram might need to use the domain names F.ISI.ARPA,
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the message, these
domain names might be represented as:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 |
1
|
F
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 |
3
|
I
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 |
S
|
I
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 |
4
|
A
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 |
R
|
P
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 |
A
|
0
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 |
3
|
F
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 |
O
|
O
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1|
20
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1|
26
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 |
0
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name for F.ISI.ARPA is shown at offset 20. The domain name
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to concatenate a
label for FOO to the previously defined F.ISI.ARPA. The domain name ARPA is
defined at offset 64 using a pointer to the ARPA component of the name F.ISI.ARPA
12
at 20; note that this pointer relies on ARPA being the last label in the string at 20. The
root domain name is
defined by a single octet of zeros at 92; the root domain
name has no labels.
TYPE values
TYPE fields are used in resource records. Note that
these types are a subset of QTYPEs.
TYPE
A
NS
MD
MF
CNAME
SOA
MB
MG
MR
NULL
WKS
PTR
HINFO
MINFO
MX
TXT
value and meaning
1 a host address
2 an authoritative name server
3 a mail destination (Obsolete - use MX)
4 a mail forwarder (Obsolete - use MX)
5 the canonical name for an alias
6 marks the start of a zone of authority
7 a mailbox domain name (EXPERIMENTAL)
8 a mail group member (EXPERIMENTAL)
9 a mail rename domain name (EXPERIMENTAL)
10 a null RR (EXPERIMENTAL)
11 a well known service description
12 a domain name pointer
13 host information
14 mailbox or mail list information
15 mail exchange
16 text strings
QTYPE values
QTYPE fields appear in the question part of a query. QTYPES are a superset of
TYPEs, hence all TYPEs are valid QTYPEs. In addition, 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
CLASS values
CLASS fields appear in resource records. The following
CLASS mnemonics and values are defined:
IN
CS
CH
HS
1 the Internet
2 the CSNET class (Obsolete - used only for
examples in some obsolete RFCs)
3 the CHAOS class
4 Hesiod [Dyer 87]
13