DNS
The internet's phone book: names in, addresses out, in one small datagram.
A query
Twenty-nine bytes asking for the A record of example.com. The letters are visible in the ASCII row.
Whole frame
AB CD 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6D 70 6C 65 03 63 6F 6D 00 00 01 00 01: 'what is the IPv4 address of example.com?' in 29 bytes, small enough for one UDP datagram.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| Transaction ID | Byte 0–1 | 0xABCD | A random number chosen by the client and copied into the reply, so it can match answers to questions (and so an attacker has to guess it). |
| Flags | Byte 2–3 | 0x0100 = query, recursion desired | Sixteen bits of control: query or response, opcode, authoritative, truncated, recursion wanted/available, response code. |
| Question count | Byte 4–5 | 1 | How many questions follow. Almost always 1. |
| Answer count | Byte 6–7 | 0 | How many answer records follow. 0 in a query. |
| Authority count | Byte 8–9 | 0 | Name-server records in the authority section (unused here). |
| Additional count | Byte 10–11 | 0 | Extra helpful records (unused here). |
| Label length | Byte 12 | 7 | Names are stored as labels, each prefixed with its length. 'example' has 7 letters. |
| Label "example" | Byte 13–19 | example | The ASCII letters. There are no dots on the wire: the dots of example.com are replaced by length bytes. |
| Label length | Byte 20 | 3 | Next label: 'com' has 3 letters. |
| Label "com" | Byte 21–23 | com | The top-level domain. |
| End of name | Byte 24 | 0 | A zero-length label ends the name (it stands for the root). |
| Query type | Byte 25–26 | 1 = A | What record is wanted: 1 = A (IPv4 address), 28 = AAAA (IPv6), 15 = MX (mail), 5 = CNAME, 16 = TXT, 2 = NS. |
| Query class | Byte 27–28 | 1 = IN | 1 = IN (the Internet). Other classes are historical. |
Overview
DNS translates names people remember (example.com) into addresses machines use. A query and its answer share one binary layout: a 12-byte header, then questions, then answer records. It usually travels in a single UDP datagram on port 53.
Names are stored as length-prefixed labels (7 'example' 3 'com' 0) rather than with dots, and answer records use pointers back into the message to avoid repeating names.
Key facts
- Transport
- UDP/53 (TCP/53 for large replies)
- Header
- 12 bytes
- Label limit
- 63 bytes per label, 253 per name
- Common types
- A, AAAA, CNAME, MX, TXT, NS
- Caching
- By TTL, in resolvers and clients
- Standard
- RFC 1035
The response
The question comes back, followed by an answer record that points at the name instead of repeating it.
Whole frame
The response repeats the question, then adds one answer record: 'example.com is 203.0.113.50, remember it for 300 seconds'.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| Transaction ID | Byte 0–1 | 0xABCD | A random number chosen by the client and copied into the reply, so it can match answers to questions (and so an attacker has to guess it). |
| Flags | Byte 2–3 | 0x8180 = response, recursion available, no error | Sixteen bits of control: query or response, opcode, authoritative, truncated, recursion wanted/available, response code. |
| Question count | Byte 4–5 | 1 | How many questions follow. Almost always 1. |
| Answer count | Byte 6–7 | 1 | How many answer records follow. 0 in a query. |
| Authority count | Byte 8–9 | 0 | Name-server records in the authority section (unused here). |
| Additional count | Byte 10–11 | 0 | Extra helpful records (unused here). |
| Label length | Byte 12 | 7 | Names are stored as labels, each prefixed with its length. 'example' has 7 letters. |
| Label "example" | Byte 13–19 | example | The ASCII letters. There are no dots on the wire: the dots of example.com are replaced by length bytes. |
| Label length | Byte 20 | 3 | Next label: 'com' has 3 letters. |
| Label "com" | Byte 21–23 | com | The top-level domain. |
| End of name | Byte 24 | 0 | A zero-length label ends the name (it stands for the root). |
| Query type | Byte 25–26 | 1 = A | What record is wanted: 1 = A (IPv4 address), 28 = AAAA (IPv6), 15 = MX (mail), 5 = CNAME, 16 = TXT, 2 = NS. |
| Query class | Byte 27–28 | 1 = IN | 1 = IN (the Internet). Other classes are historical. |
| Name (pointer) | Byte 29–30 | 0xC00C → example.com | Name compression: the two top bits 11 mean 'a pointer': the name is found at offset 0x0C (byte 12) of this message, i.e. in the question. This saves repeating example.com in every record. |
| Type | Byte 31–32 | 1 = A | The record type of this answer: A. |
| Class | Byte 33–34 | 1 = IN | IN. |
| TTL | Byte 35–38 | 300 seconds | How many seconds caches may keep this answer. 300 s = 5 minutes. Short TTLs allow quick changes; long TTLs reduce load. |
| Data length | Byte 39–40 | 4 | Bytes of data that follow: an IPv4 address is 4. |
| Address | Byte 41–44 | 203.0.113.50 | The answer itself: the IPv4 address of example.com in this demo (a documentation address). |
A lookup with caching
Who asks whom, and where the answer is remembered.
Whole exchange
One question, one answer, cached for the TTL. Every name lookup on the internet is a short conversation like this, usually over UDP.
1Laptop asks the resolver
The laptop does not search the internet itself. It asks its configured resolver (often the router or the ISP) and sets RD, 'recursion desired'.
2Resolver asks the owner
Cache miss. In reality the resolver walks from a root server to the .com servers to example.com's own name server, three queries in a row; they are drawn here as one step.
3Authoritative answer
The server that owns the zone answers with the record and a TTL. AA = authoritative.
4Resolver answers the laptop
The same answer is relayed with RA set. For the next 300 seconds, anyone asking this resolver gets the cached answer instantly.
Where you meet it
- Every web request starts with a DNS lookup
- Email routing (MX), domain ownership proofs (TXT), service discovery (SRV)
- DNS over HTTPS/TLS wrap the same messages in encryption
Watch out for
- 'It's always DNS': stale caches and TTLs explain most 'I changed it but nothing happened' moments.
- Plain DNS is unencrypted and unauthenticated; the transaction ID and port are all that stop easy spoofing (DNSSEC adds signatures).
- Answers over 512 bytes (or 1232 with EDNS0) do not fit one datagram and fall back to TCP.
Standards
- RFC 1035: Domain Names - Implementation and Specification