Skip to main content
When resolving a domain name, a DNS query is initiated. The response is provided either from a cache or, if required, by querying an authoritative nameserver. The query traverses the DNS tree starting at the Root Zone. The DNS resolution involves two-way communication:
  • A request from the client that carries the query.
  • A response from a DNS component that carries the answer.
Both the request and response utilize a standard format defined in RFC 1035 section 4.1.
The image explains the DNS protocol, detailing the structure of a DNS message divided into five sections: Header, Question, Answer, Authority, and Additional. It includes a link to RFC1035 section 4.1 for further reference.
A DNS message is split into five sections. Both requests and responses share this structure with resource records. For instance, in a DNS request the question section is filled out with details about the domain name. In contrast, the response populates the answer and authority sections, while the header and additional sections can be used by both to indicate operation details. Depending on the query type, DNS messages may be transported via UDP, TCP, or HTTP. Although the transport method might influence how the message is sent (for example, when using the dig command which typically uses UDP or TCP), the resource record structure remains unchanged.
The image illustrates DNS as a protocol, showing how a DNS query can be transported using UDP, TCP, or HTTP, with a note that the protocol affects transport but not the record structure.
For example, a typical query using dig appears as follows:
Note that in most cases the entire DNS message (both the request and response) can be carried in a single UDP packet. If the message exceeds the UDP size limit (often due to a large response), the server will fallback to using TCP. When DNS messages are transmitted over encrypted protocols like HTTPS or TLS, the data is secured in transit. The DoH/DoT resolver decrypts the data, performs the lookup using standard unencrypted servers, and then re-encrypts the response back to the client. Let’s now dive into the DNS message format, starting with the header. By comparing the output of the DIG command with the DNS message structure, you can see how each section of the DNS message corresponds to parts of the output.
The image is a diagram illustrating the DNS protocol message format, detailing sections like Header, Question, Answer, Authority, and Additional, with specific fields listed under each section.

​
DNS Header

The DNS header is 12 bytes long and contains several key fields:
  • ID Field: An integer generated by the client to match responses with queries, since UDP does not inherently track packets. The server copies this ID into its response.
  • Flags Row:
The image illustrates the structure of a DNS protocol message, highlighting the header section with flags that modify the query, and sections for question, answer, authority, and additional information.
The flags include:
  • QR: Indicates if the message is a query (0) or a response (1). DIG outputs will show 1 for responses.
  • Opcode: Specifies the query type; standard queries use 0.
  • AA: Authoritative Answer – set if the responding nameserver is authoritative.
  • TC: Truncation – if a DNS response is too large for UDP, the server sets TC to 1 to prompt a TCP retry.
  • RD and RA:
    • RD (Recursion Desired): Set by the client to request full DNS resolution.
    • RA (Recursion Available): Indicates in the response whether recursive queries are supported.
For example, querying an authoritative nameserver directly with the @ symbol might yield the following output:
  • Z Flag: Reserved for future use.
  • Rcode: Indicates the outcome of the query. An Rcode of 0 means success, while 3 indicates that the domain does not exist.
The image explains DNS as a protocol, showing different RCODE responses for DNS queries, including no error, format error, server failure, name error, and not implemented.

​
Header Count Fields

  • QDCOUNT (Question Count): Number of questions in the question section (typically 1).
  • ANCOUNT (Answer Count): Number of resource records in the answer section. Multiple A records for a domain increase this count.
  • NSCOUNT (Authority Count): Number of nameserver records in the authority section. Although DIG shows the authorities, the raw NS count is visible through packet capture tools like TCPDump or Wireshark.
  • ARCOUNT (Additional Count): Number of records in the additional section, often used for supplementary data like glue records.
The image illustrates the structure of a DNS protocol message, highlighting sections such as Header, Question, Answer, Authority, and Additional, with a focus on the "NSCOUNT" field indicating the number of name server records in the authority section.
The image illustrates the structure of a DNS protocol message, showing its components such as Header, Question, Answer, Authority, and Additional sections. It includes fields like ID, QR, Opcode, and others, with a focus on the number of records in the additional section.

​
Question Section

The question section carries information about the query and consists of:
  • QName: The domain name being queried.
  • QType: The type of DNS record requested (e.g., A, AAAA, CNAME, MX). If omitted, an A record is assumed.
  • QClass: The query class, which is typically 1 (IN for the Internet).
Ensure that top-level domain queries use a fully qualified domain name (ending with a dot).
The image illustrates the structure of a DNS protocol, showing components like Header, Question, Answer, Authority, and Additional, with a focus on the domain name being queried for resolution.

​
Answer Section

The answer section is populated by the DNS component that responds to the query. It contains resource records with the following fields:
  • NAME: The queried domain name.
  • TYPE: The type of record (e.g., A, AAAA).
  • CLASS: Typically IN.
  • TTL: Time-to-live value in seconds, which dictates caching duration.
  • RDLength: Length (in bytes) of the record data (e.g., 4 bytes for an A record, 16 bytes for an AAAA record).
  • RDATA: The actual data, such as an IP address.
The image illustrates the structure of a DNS protocol response, highlighting sections such as Header, Question, Answer, Authority, and Additional, with a focus on the Answer section containing fields like NAME, TYPE, CLASS, TTL, RDLENGTH, and RDATA.

​
Authority Section

The authority section also contains resource records that are similar in structure to those in the answer section. It is typically filled when the nameserver responds authoritatively—for example, when a root nameserver is queried for a TLD. For instance, running the following command against a .gtld nameserver might produce this output:

​
Additional Section

The additional section follows the same resource record structure and is used to provide supplementary information. As the DNS protocol evolved, this section was repurposed to store new functionality while maintaining backward compatibility. It is particularly useful for displaying glue records or supplementing NS records. For example, using the +additional flag:
The additional section repeats the same fields—NAME, TYPE, CLASS, TTL, RDLength, and RDATA—for supplementary records like glue.
Think of the additional section as a versatile drawer in your DNS toolkit. Originally designed for a single purpose, it has been repurposed to store extra information without changing the overall format.
In the next lesson, we will examine the extended DNS capabilities provided by the OPT records contained within the additional section.
In this lesson, we explored the structure of DNS messages by breaking down the header, question, answer, authority, and additional sections. This detailed examination helps in understanding how DNS queries and responses are constructed and interpreted while emphasizing the consistency in resource record structure regardless of the transport protocol.

Watch Video