All DNS-related communication happens through the same basic format, described in RFC 1035, using the same DNS ports. Knowing how this format works can convenient to be able to diagnose and solve DNS problems, and it’s nessecary if you want to write your own programs using DNS (e.g. with Poslib).

This document describes the general format for DNS messages, and its applications in a number of query types, inluding normal queries, zone tranfers, and DNS update messages.

This document only described what is stored in DNS messages: it won’t go into the details of how data is actually stored in a DNS Message (for that, see the references).

A DNS message consists of five sections:

• Header - Contains basic information about the query
• Question - Contains the question from the client
• Answer - Contains the answer from the server
• Authority - Contains information about authoritative DNS servers
• Additional - Contains additional information that does not directly answer the query, but which may be useful for the client

The Header section consists of a few fields. Let’s look at an example header, as output by the DNS query tool:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false RD: true
; RA: true  RCODE: NOERROR  qc 1  an 1  au 0  ad 0

The fields have the following meaning:

• Answer ID - The client sets this to a random value, and the server sets it to the same ID to the query to indicate what query an answer is about
• QR (Query/Response) - false in queries, true in responses
• OPCODE (Operation Code) - Type of query. QUERY indicates a normal query. See below.
• AA (Authoritative Answer) - Indicates whether the server is an authoritative DNS server for the data queried
• TC (Truncated) - Set to true if the answer didn’t fit in the DNS message. Normally you will not see this because clients will automatically retry using TCP, which allows for much larger packets than the normally used UDP protocol
• RD (Recursion Desired) - True if the client wants the server to do recursion (i.e., set to true in queries to caching DNS servers, and set to false in queries to authoritative DNS servers)
• RA (Recursion Available) - True if the server wants to do recursion for the client1)
• RCODE - (Response Code) - Type of response. Common types are NOERROR (no eror), SRVFAIL (server failure), NOTIMP (feature not implemented by server), NXDOMAIN (domain doesn’t exist; see below) and REFUSED (server refuses to answer query)
• qc, an, au, ad - The number of items in the question, answer, authority and additional sections, respectively

The Question section consists of combinations of a query domain name, class, and record type. There are special record types; the most important one being ANY, for records of any type. An example item in the question section:

;posadis.org. IN A

For any type of DNS message described here, there is only one query in the question section.

The Answer, Authority and Additional sections are basically all lists of Resource records. An example entry in one of the sections could be:

posadis.org. 1d IN A  

A normal query is a query asking for all records of a specific type at a specific domain name. The queries you send to your DNS server, and the queries caching DNS servers send to authoritative DNS servers, as described in the DNS overview, are all normal queries.

As an answer to a normal query, a number of things can happen. Each answer type has different characteristics, the differences between which are often subtle. This table summarizes the different response types and their characteristics:

The “Answer” column indicates whether a direct answer to the query is present in the answer section of the message. The “RCODE” column indicates the value of the RCODE header field. The “NS?” column indicates whether NS records are available in the authority section of the message; the “SOA?” colum indicates the presence of the SOA record of the zone in the authority section.

There’s nothing special about a normal query. It has exactly one item in the question section, the three RR sections are empty.

; Answer ID: 18467  QR: false  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: false  RCODE: NOERROR  qc 1  an 0  au 0  ad 0
; Question section:
;posadis.org. IN A

The one thing to note is the value of the RD flag, which in this case is true, which indicates that this is a query to a caching DNS server which we expect to do recursion. A query by a caching DNS server to an authoritative DNS server would not have the RD flag set to false.

In the ideal situation, if we send a query, we get an answer to it. A normal answer is uniquely recognizable by the fact that the answer section contains an answer (i.e., a record in the answer section that matches the domain name, query class and query type mentioned in teh question section). Usually, the question is repeated in the question section. For example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: true  RCODE: NOERROR  qc 1  an 1  au 0  ad 0
; Question section:
;posadis.org. IN A
; Answer section:
posadis.org. 21h39m25 IN A 

A remark about queries of type ANY is in place here. The ANY type can be used to find out about records of any type attached to a given domain name. But if you do an ANY query to a caching DNS server, and it has records of at least one type of RR for the doman name in its cache, it will not try to find out about records of other types. For example, if a domain name has A and MX records, and a cache has only the A record in its cache, it will return just that record instead of both record types.

When querying an authoritative DNS server, it will usually add a list of nameservers authoritative for the requested domain name to the authority section; some caching DNS servers do this as well.

Also, if the RR data of a record in the answer and additional sections contain a domain name, and the DNS server happens to know addresses for that domain name, it will add these to the additional section of the message, saving the client (which presumably needed these addresses anyway) a query. For example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: true  RCODE: NOERROR  qc 1  an 3  au 4  ad 4
; Question section:
;google.nl. IN MX
; Answer section:
google.nl. 30m IN MX 20 smtp2.google.com. 
google.nl. 30m IN MX 30 smtp3.google.com. 
google.nl. 30m IN MX 10 smtp1.google.com. 
; Authority section:
google.nl. 4d IN NS ns1.google.com. 
google.nl. 4d IN NS ns2.google.com. 
google.nl. 4d IN NS ns3.google.com. 
google.nl. 4d IN NS ns4.google.com. 
; Additional section:
ns1.google.com. 2d IN A  
ns2.google.com. 2d IN A  
ns3.google.com. 2d IN A  
ns4.google.com. 2d IN A  

In this case, the DNS server happened to have the nsX.google.com. addresses mentioned in the NS records in its cache, so it added them to the additional section. Though the smtpX.google.com. domain names appear in the answer section, the server apparently didn’t have information on them in its cache, which is why we don’t find those addresses in the additional section.

If the requested domain name does not exist, the answer message has the Return Code set to NXDOMAIN. Also, the authority section of the message contains the SOA record for the zone closest to the requested domain name. This SOA record is useful caching DNS servers because its last field indicates how long the fact that the domain name didn’t exist, may be cached. An example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: true  RCODE: NXDOMAIN  qc 1  an 0  au 1  ad 0
; Question section:
;wwww.posadis.org. IN A
; Authority section:
posadis.org. 42m40 IN SOA a.ns.conuropsis.org.
hostmaster.posadis.org.  16384 2048  2560 

In this case, wwww.posadis.org. doesn’t exist; if it did, it would have been in the posadis.org. zone, and we may remember that information for 2560 seconds.

One word on the existence of domain names: a domain name is said to exist if it has one or more resource records attached to it. This means that if, say, a.b.example.com. exists, it’s still possible that b.example.com. does not exist, even if it has a place in the DNS tree.

If the requested domain name exists, but there are no records of the requested type, an answer is returned with an empty answer section, and the SOA record of the zone the domain name is in in the authority section. As in the “no domain” response, this SOA record is used to determine how long the fact that data of the requested type does not exist, may be remembered. An example answer:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: true  RCODE: NOERROR  qc 1  an 0  au 1  ad 0
; Question section:
;posadis.org. IN MX
; Authority section:
posadis.org. 42m40 IN SOA a.ns.conuropsis.org.
hostmaster.posadis.org.  16384 2048  2560 

In this case, posadis.org. exists, but it doesn’t have record of type MX, and we may store that information for 2560 seconds.

If the DNS server does not have an answer to the given query, it will return a referral message, pointing the client to (other) authoritative DNS servers closer to the requested information. This happens in two cases:

• if a caching DNS server receives a query of which it doesn’t have the answer in its cache, and it doesn’t do recursion for the client (either because the client didn’t request it in the RD flag, or the server didn’t want it as indicated by the RA flag), or
• if an authoritative DNS server receives a query for a domain it is not authoritative for (for example because it has delegated the domain to another DNS server)

A referral, like a “no data” response, has an empty answer section; the difference is that a referral has NS records in the authority section, pointing to a closer location. For example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: false
; RA: true  RCODE: NOERROR  qc 1  an 0  au 13  ad 14
; Question section:
;www.posadis.net. IN MX
; Authority section:
net. 1d23h29m19 IN NS d.gtld-servers.net. 
net. 1d23h29m19 IN NS a.gtld-servers.net. 
(...)
; Additional section:
d.gtld-servers.net. 1d23h29m20 IN A  
a.gtld-servers.net. 1d23h29m20 IN A 192.5.6.30 
a.gtld-servers.net. 1d23h29m20 IN AAAA 2001:503:a83e:0:0:0:2:30 

In this case, we didn’t request recursion, and our caching DNS server didn’t have information on www.posadis.net. yet, so it pointed us to the closest match in the DNS tree it could find: the net. DNS servers, with the addesses of some of them in the additional section.

Note that, even if authoritative DNS servers store the delegation information for a subdomain in their zones itself, a delegation message does not have the AA flag set.

If an error occurs when answering the query, the Response Code is set to something else than NOERROR to indicate what went wrong; see the description of the RCODE field for some possible codes. This could, for example, happen in an authoritative DNS server if there is an error in the zone data (SRVFAIL error), or when you do a request to a server that doesn’t want to answer you at all (REFUSED error). An example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: true  TC: false  RD: true
; RA: true  RCODE: SRVFAIL  qc 1  an 0  au 0  ad 0
; Question section:
;www.test-error-rcode.com. IN A

In this case, as indicated by the AA flag, the server is apparently authoritative for the domain2), but an internal error in the server occured, as indicated by the SRVFAIL code.

Just when you may have gotten a bit of a clear picture on the different types of responses to normal queries, there’s just one thing that makes things a bit more difficult, which is aliases with the CNAME Resource Record. If the requested domain name is an alias to another domain name, the CNAME record is added to the answer section, and the DNS server will restart the query, and add any records that apply to the target domain name, too. For example:

; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: false  TC: false  RD: true
; RA: true  RCODE: NOERROR  qc 1  an 4  au 9  ad 7
; Question section:
;www.google.nl. IN A
; Answer section:
www.google.nl. 4d IN CNAME www.google.com. 
www.google.com. 15m IN CNAME www.google.akadns.net. 
www.google.akadns.net. 5m IN A  
www.google.akadns.net. 5m IN A  
; Authority section:
akadns.net. 2d IN NS asia9.akadns.net. 
(..)
; Additional section:
asia9.akadns.net. 2d IN A  
(..)

Here, www.google.nl. is an alias to www.google.com., so the CNAME record of www.google.nl. is added and the query is restarted for the target domain name www.google.com.. This domain name in turn is an alias to www.google.akadns.net., which, finally, has two A records that answer the query.

If one of the other answer types occurs, the same basic rules still apply, only they apply to the last domain name in the CNAME chain. For example, a “no data” response can be recognized by the SOA record for the zone the last domain name is in; the same goes for the “no domain” response. In that case, the RCODE is still set to NXDOMAIN, even though the originally requested domain name does actually exist. The AA flag of an answer, on the other hand, applies to the originally requested domain, e.g. if a CNAME takes an authoritative DNS server outside of its zone data, it does set the AA flag.

• DNS.net has a list of DNS standards
• RFC 1034 contains a description on the handling of normal queries
• RFC 1035 is the standard defining the DNS message format
• RFC 1995 describes incremental zone transfers (note that there is no proper standard defining normal zone transfers)
• RFC 1996 describes DNS Notify
• RFC 2136 describes DNS update