mail this page
products | company | support | training | contact us
This section details the format of messages that pass between a Resolver and a DNS system. The really smart thing to do is install wireshark and let it to all the analysis for you. However if you are in de-bug mode then you may need this stuff. This where the Rocket Scientists wannabees hang out. Welcome.
Message formats are defined in RFC 1035.
The good news is that each message has the same generic format with 5 sections. This is the last good news.
|Section 1||Message Header|
|Section 2||The DNS question being asked (aka Question Section)|
|Section 3||The Resource Record(s) which answer the question (aka Answer Section)|
|Section 4||The Resource Record(s) which point to the domain authority (aka Authority Section)|
|Section 5||The Resource Record(s) which may hold additional information (aka Additional Section)|
Present in all messages. Never empty. Contains various flags and values which control the transaction. If you are not comfortable with bits, bytes and hex values take up origami or read this quick memory jogger. And while you are in this receptive mode you may want remind yourself that bit numbering standards are a real mess.
|QDCOUNT (No. of items in Question Section)|
|ANCOUNT (No. of items in Answer Section)|
|NSCOUNT (No. of items in Authority Section)|
|ARCOUNT (No. of items in Additional Section)|
The following table defines the field values above:
|Message ID||16 bit message ID supplied by the requestion (the questioner) and reflected back unchanged by the responder (answerer). Identifies the transaction.|
|QR||Query - Response bit. Set to 0 by the questioner (query) and to 1 in the response (answer).|
|OPCODE||Identifies the request/operation type. Currently assigned values are:
|AA||Authoritative Answer. Valid in responses only. Because of aliases multiple owners may exists so 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. Set on all truncated messages except the last one.|
|RD||Recursion Desired - this bit may be set in a query and is copied into the response if recursion supported if rejected the response (answer) does not have this bit set. Recursive query support is optional.|
|RA||Recursion Available - this bit is valid in a response (answer) and denotes whether recursive query support is available (1) or not (0) in the name server.|
|RCODE||Identifies the response type to the query. Ignored on a request (question). Currently assigned values:
|QDCOUNT||Unsigned 16 bit integer specifying the number of entries in the Question Section.|
|ANCOUNT||Unsigned 16 bit integer specifying the number of resource records in the Answer Section. May be 0 in which case no answer record is present in the message.|
|NSCOUNT||Unsigned 16 bit integer specifying the number of name server resource records in the Authority Section. May be 0 in which case no authority record(s) is(are) present in the message.|
|ARCOUNT||Unsigned 16 bit integer specifying the number of resource records in the Additional Section. May be 0 in which case no addtional record(s) is(are) present in the message.|
While it is normal to have only one question per message, it is permissible to have any number defined by QDCOUNT each question has the same format as defined below:
|QNAME||The domain name being queried|
|QTYPE||The resource records being requested|
|QCLASS||The Resource Record(s) class being requested e.g. internet, chaos etc.|
Each field has the following format:
|QNAME||The name being queried will depend upon the QTYPE (below) e.g. a request for an A record will require a host part i.e. www.mydomain.com an MX query will obviously only use a domain name i.e. mydomain.com The name being queried is split into labels by removing the separating dots. Each label is represented as a length/data pair as follows:
// assume an MX query with a name of mydomain.com // the hex representation is 08 6D 79 64 6F 6D 61 69 6E 03 63 6F 6D 00 // printable ! m y d o m a i n ! c o m ! // note ! = unprintable // assume an A query with a name of www.mydomain.com // the hex representation is 03 77 77 77 08 6D 79 64 6F 6D 61 69 6E 03 63 6F 6D 00 // printable ! w w w ! m y d o m a i n ! c o m ! // note ! = unprintable
|QTYPE||Unsigned 16 bit value. The resource records being requested. These values are assigned by IANA and a complete list of values may be obtained from them. The following are the most commonly used values:
|QCLASS||Unsigned 16 bit value. The CLASS of resource records being requested e.g. Internet, CHAOS etc. These values are assigned by IANA and a complete list of values may be obtained from them. The following are the most commonly used values:
The Answer, Authority and Additional Section all comprise RRs and hence share the same format. The section the record appears in determines its type e.g. an A RR can appear in the Answer or Additional section. So far this stuff has been relatively straightforward if messy - take a deep breath before reading on. The format of these records is:
|NAME||The name being returned e.g. www or ns1.example.net If the name is in the same domain as the question then typically only the host part (label) is returned, if not then a FQDN is returned.|
|TYPE||The RR type, for example, SOA or AAAA|
|CLASS||The RR class, for instance, Internet, Chaos etc.|
|TTL||The TTL in seconds of the RR, say, 2800|
|RLENGTH||The length of RR specific data in octets, for example, 27|
|RDATA||The RR specific data (see Binary RR Formats below) whose length is defined by RDLENGTH, for instance, 192.168.254.2|
The various fields have the following meanings:
|NAME||This name reflects the QNAME of the question i.e. any may take one of TWO formats. The first format is the label format defined for QNAME above. The second format is a pointer (in the interests of data compression which to fair to the original authors was far more important then than now). A pointer is an unsigned 16-bit value with the following format (the top two bits of 11 indicate the pointer format):
Note: Pointers, if used, terminate names. The name field may consist of a label (or sequence of labels) terminated with a zero length record OR a single pointer OR a label (or label sequence) terminated with a pointer.
|TYPE||Unsigned 16 bit value. The resource record types - determines the content of the RDATA field. These values are assigned by IANA and a complete list of values may be obtained from them. The following are the most commonly used values:
|CLASS||Unsigned 16 bit value. The CLASS of resource records being requested, for example, Internet, CHAOS etc. These values are assigned by IANA and a complete list of values may be obtained from them. The following are the most commonly used values:
|TTL||Unsigned 32 bit value. The time in seconds that the record may be cached. A value of 0 indicates the record should not be cached.|
|RDLENGTH||Unsigned 16-bit value that defines the length in bytes (octets) of the RDATA record.|
|RDATA||Each (or rather most) resource record types have a specific RDATA format which reflect their resource record format as defined below:
You will be delighted to know that authority records have exactly the same format as Answer records it is simply their position in an authority section that determines they are authority records (and that they will be of TYPE NS).
You will be delighted to know that additional records have exactly the same format as Answer records it is simply their position in an additional section that determines they are additional records.
The contents of an 8 bit byte (an octet) may be expressed in decimal (base 10), binary (base 2) or hexadecimal (base 16 - 0-9, A-F) as follows:
To convert a dotted decimal IP e.g. 192.168.0.5 to hexadecimal, take each dotted decimal value and convert it using a hex calculator (standard windows calculator in scientific mode will do the job). This will yield C0.A8.00.05 for our example above.
Bit numbering can be very confusing with various standard bodies adopting different conventions. The following are all valid, and used, bit numbering conventions for describing an 8 bit byte (an octet).
|Bit numbering conventions|
|Left to right base 0 (IETF)||0||1||2||3||4||5||6||7|
|Left to right base 1||1||2||3||4||5||6||7||8|
|Right to left base 1 (ITU)||8||7||6||5||4||3||2||1|
|Power of 2||7||6||5||4||3||2||1||0|
Always check what convention is used on any specification. The convention used by the IETF is a LEFT to RIGHT number starting from (base) ZERO. Many (but not all) C compliers allocate bits in a field using this convention.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
3 reverse map
4 dns types
5 install bind
8 dns records
12 bind api's
13 dns security
bits & bytes
notes & tips
This work is licensed under a Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox