Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
DNS Message Header and Question Section Format
(Page 1 of 2)
The client/server information exchange
in DNS is facilitated using query/response messaging. Both queries and
responses have the same general format, containing up to five individual
sections carrying information. Of these, two are usually found in both
queries and responses: the Header section and the Question
section. I will start exploring the detailed format of DNS messages
by looking at these two sections; the next topic will cover the resource
record formats used by servers for the other three message sections.
DNS Message Header Format
The header is the most important
part of any message, since it is where critical control fields are carried.
In DNS messages, the Header section carries several key control
flags, and is also where we find out which of the other sections are
even being used in the message. Examining the Header can help
us understand several of the nuances of how messaging works in DNS.
The format of the Header section
used in all DNS messages is described in detail in Table 169
and shown in Figure 248.
Where fields are used differently by the client and server in an exchange,
I have mentioned in the table how the use is differentiated between
the two.
Table 169: DNS Message Header Format
Field
Name
|
Size (bytes)
|
Description
|
ID
|
2
|
Identifier: A 16-bit
identification field generated by the device that creates the DNS query.
It is copied by the server into the response, so it can be used by that
device to match that query to the corresponding reply received from
a DNS server. This is used in a manner similar to how the Identifier
field is used in many of the ICMP
message types.
|
QR
|
1/8
(1 bit)
|
Query/Response
Flag: Differentiates between queries and responses. Set to 0
when the query is generated; changed to 1 when that query is changed
to a response by a replying server.
|
Opcode
|
1/2
(4 bits)
|
|
AA
|
1/8
(1 bit)
|
Authoritative
Answer Flag: This bit is set to 1 in a response to indicate
that the server that created the response is authoritative for the zone
in which the domain name specified in the Question section is located.
If it is 0, the response is non-authoritative.
|
TC
|
1/8
(1 bit)
|
Truncation Flag:
When set to 1, indicates that the message was truncated due to its length
being longer than the maximum permitted for the type of transport mechanism
used. TCP doesn't have a length limit for messages, while UDP messages
are limited to 512 bytes, so this bit being sent usually is an indication
that the message was sent using UDP and was too long to fit. The client
may need to establish a TCP session to get the full message. On the
other hand, if the portion truncated was part of the Additional
section, it may choose not to bother.
|
RD
|
1/8
(1 bit)
|
Recursion
Desired: When set in a query, requests that the server receiving
the query attempt to answer the query recursively, if the server supports
recursive
resolution. The value of this bit is not
changed in the response.
|
RA
|
1/8
(1 bit)
|
Recursion Available:
Set to 1 or cleared to 0 in a response to indicate whether the server
creating the response supports recursive queries. This can then be noted
by the device that sent the query for future use.
|
Z
|
3/8
(3 bits)
|
Zero:
Three reserved bits set to zero.
|
RCode
|
1/2
(4 bits)
|
|
QDCount
|
2
|
Question
Count: Specifies the number of questions in the Question
section of the message.
|
ANCount
|
2
|
Answer Record Count:
Specifies the number of resource records in the Answer section
of the message.
|
NSCount
|
2
|
Authority
Record Count: Specifies the number of resource records in the
Authority section of the message. (NS stands for
name server, of course. J)
|
ARCount
|
2
|
Additional Record Count:
Specifies the number of resource records in the Additional section
of the message.
|
Figure 248: DNS Message Header Format
|
Note that the current lists
of valid question types, query operation codes and response codes are
maintained by IANA as one of its many lists of Internet parameters.
Response codes 0 to 5 are part of regular DNS and are defined
in RFC 1035; codes 6 to 10 implement dynamic DNS and are defined in
RFC 2136.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|