Technical Article · DNS Protocol

The DNS protocol: message format and where it fits in browsing

Every web page begins with a DNS lookup. This article walks through the DNS protocol — the message types, the header and record layout, and the exact point in a browsing session where a name is turned into an IP address.

Where DNS happens when you open a page

The Domain Name System (DNS) translates a human-readable name such as www.example.com into the IP address a computer actually connects to. It is the very first network step of loading a page: nothing else can happen until the name resolves. The diagram below shows the order of operations when a browser opens an HTTPS site.

DNS resolution Your browser DNS resolver Web server 1. DNS query — A? www.example.com 2. DNS response — 93.184.216.34 3. TCP connect to 93.184.216.34 : 443 4. TLS handshake (HTTPS) 5. HTTP GET www.example.com 6. HTTP 200 + HTML, CSS, JS 7. Browser parses and renders the page
DNS resolution (steps 1–2) comes first. Only once the name resolves to an IP does the browser open a TCP connection (3), complete the TLS handshake (4) and exchange HTTP (5–6). A host-based DNS firewall inspects steps 1–2 and can allow, block or redirect a name before any connection is attempted.

Before a query even leaves the machine, the resolver checks local sources in order — the browser’s own cache, the operating system’s DNS cache, and the hosts file. Only on a miss does the stub resolver send a DNS query to the configured recursive resolver, which may in turn walk the DNS hierarchy (root → top-level domain → authoritative server) to find the answer.

The DNS message structure

Queries and responses use the same message format, defined in RFC 1035. A message has a fixed 12-byte header followed by four variable-length sections. The header’s count fields say how many entries each section holds.

Header — 12 bytes ID, flags, and the four section counts Question section QDCOUNT entries — the name and type being asked about Answer section ANCOUNT resource records — the records that answer the query Authority section NSCOUNT resource records — the authoritative name servers Additional section ARCOUNT resource records — extra helpful records
The five parts of every DNS message. A simple query usually fills only the header and the Question section.

The 12-byte header is six 16-bit words. The second word holds the flag bits that distinguish a query from a response and report the outcome; the last four words are the section counts.

bit 0123 4567 891011 12131415 ID (16 bits) — identifier copied from the query into the reply QR Opcode (4) AA TC RD RA Z (3) RCODE (4) QDCOUNT (16) — number of entries in the Question section ANCOUNT (16) — number of records in the Answer section NSCOUNT (16) — number of records in the Authority section ARCOUNT (16) — number of records in the Additional section
The 12-byte DNS header. The highlighted fields — QR and RCODE — are what change between a question and its answer.
  • QR — 0 = query, 1 = response
  • Opcode — kind of request (QUERY, NOTIFY, UPDATE…)
  • AA — authoritative answer
  • TC — truncated (retry over TCP)
  • RD — recursion desired
  • RA — recursion available
  • Z — reserved (DNSSEC later defined AD and CD here)
  • RCODE — result code (NOERROR, NXDOMAIN…)

Message types: query vs response

There is one wire format, but the header tells you what a message is. The QR bit says whether it is a query or a response, the Opcode says what kind of operation it is, and on a response the RCODE reports the outcome.

Header fieldCommon valuesMeaning
QR0 / 1Query (a question) or response (an answer)
OpcodeQUERY (0), STATUS (2), NOTIFY (4), UPDATE (5)What kind of request this is — an ordinary lookup, a server status check, a zone-change notification, or a dynamic update
RCODENOERROR (0), FORMERR (1), SERVFAIL (2), NXDOMAIN (3), NOTIMP (4), REFUSED (5)Result reported in a response — success, a malformed query, server failure, a non-existent name, an unsupported operation, or a refusal

Resource records

The Answer, Authority and Additional sections are all built from resource records (RRs). Every RR has the same shape: a name, a type and class, a time-to-live, and a length-prefixed blob of record data.

NAME — the domain name (variable length; may be compressed) TYPE (2 bytes) — record type: A, AAAA, CNAME, MX… CLASS (2 bytes) — almost always IN (the Internet) TTL (4 bytes) — how many seconds the record may be cached RDLENGTH (2 bytes) — length, in bytes, of RDATA RDATA — the record data, e.g. 93.184.216.34 (RDLENGTH bytes)
Every resource record shares this structure. For an A record, RDATA is the four bytes of an IPv4 address.

Common record types

The TYPE field decides how to read RDATA. These are the record types you meet most often:

TypeValueWhat it returns
A1An IPv4 address
AAAA28An IPv6 address
CNAME5A canonical (alias) name pointing to another name
NS2An authoritative name server for the zone
MX15A mail server name plus a priority
TXT16Arbitrary text (SPF, domain-ownership verification, etc.)
PTR12A name for a reverse (IP-to-name) lookup
SOA6The start-of-authority record describing a zone
SRV33The host and port of a named service
CAA257Which certificate authorities may issue certs for the domain

How DNS travels the network

DNS usually rides on UDP port 53, because a single small datagram each way is fast and cheap. If a reply is too large for a UDP datagram, the server sets the TC (truncated) flag and the client retries the same query over TCP port 53. TCP is also used for zone transfers between servers. Encrypted variants wrap DNS to keep lookups private in transit: DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443).

A worked example

Putting it together, here is a query for the A record of www.example.com and the response that comes back, with the header fields shown alongside the sections they describe:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 0x2f1a ;; flags: qr rd ra; QDCOUNT: 1, ANCOUNT: 1, NSCOUNT: 0, ARCOUNT: 0 ;; QUESTION SECTION: www.example.com. IN A ;; ANSWER SECTION: www.example.com. 86400 IN A 93.184.216.34

The header’s id ties the answer to the question; qr marks it as a response; status: NOERROR is RCODE 0; and the counts say there is one question and one answer. In the answer record you can read the TTL (86400 seconds), the class (IN), the type (A) and the RDATA (the IPv4 address).

Where DNS Proxywall fits

A host-based DNS firewall works by reading these exact fields as messages pass through the machine. DNS Proxywall sits at steps 1–2 of the browsing sequence and acts on the protocol directly:

  • it matches the Question name against name-pattern rules to allow or block a lookup;
  • it reads the IP addresses in the Answer RDATA to apply Geo DNS policy and to block non-DNS direct-IP traffic;
  • it can adjust the TTL on records it serves to other computers as a proxy;
  • it uses the RCODE to recognize and cache refusals so repeat lookups to dead or blocked names fail fast.
Because all of this happens locally, your queries are never handed to an online DNS filtering provider — the rules, the decisions and the activity log stay on your own machine.

See the DNS protocol put to work

DNS Proxywall reads, filters, caches and proxies these messages on Windows — as a DNS firewall and a DNS proxy in one.

Get DNS Proxywall DNS firewall vs proxy vs proxywall

Keep reading

DNS firewall for Windows
How a host-based DNS firewall blocks domains at the lookup.
DNS monitoring & logging
See every query and response in a live activity log.
DNS proxy server
Serve, cache and tunnel these messages for a whole network.

Notes:
* Windows® is a registered trademark of the Microsoft Corporation.