How DNS Works: Protocol, Lookups and Packets Explained

The quick download:

DNS is the invisible protocol that makes every internet connection possible, and understanding it is the first step to monitoring it effectively.

DNS translates human-readable domain names into IP addresses using a layered chain of servers, from stub resolvers to authoritative name servers, with caching at every level to keep lookups fast.
Every DNS message follows the same packet structure (header, question, answer, authority, and additional sections), making the protocol predictable and inspectable with tools like Wireshark.
UDP handles most DNS queries for speed, but the protocol falls back to TCP when responses are too large or firewalls block UDP traffic.
Start by mapping your own DNS path from the client to the authoritative name server, then use tools that let you see how delegation, TTL, caching, and packet structure affect real-world performance and troubleshooting.

DNS (Domain Name System) is the protocol that translates human-readable domain names like www.google.com into IP addresses that computers use to route traffic. Every time you type a URL into a browser, DNS runs in the background to make that connection possible.

In this guide, we cover the fundamentals: the protocol, the lookup process, and how a DNS packet is structured, so you can follow along with our DNS monitoring deep dive, where we cover delegation, TTL and caching, performance, security, and health testing in more depth.

What Is the DNS Protocol?

DNS is an application layer protocol in the TCP/IP suite. It runs over UDP by default, since UDP needs no handshake and completes in fewer round trips.

DNS falls back to TCP when a firewall blocks UDP or when a response is too large to fit in a single UDP packet.

	UDP	TCP
Handshake required	No	Yes (three-step)
Delivery confirmation	No	Yes
Speed	Faster; fewer round trips	Slower; more round trips
Used when	Standard DNS queries	Firewall blocks UDP or response exceeds 512 bytes

How a DNS Lookup Works

A DNS query moves through a chain of servers until it reaches an answer:

Stub resolver (your device)
Recursive resolver
Root server
TLD server
Authoritative name server

In practice, most of that chain is skipped thanks to caching at every layer, which is exactly why a query for a popular domain typically resolves in milliseconds rather than requiring a full walk from the root every time.

Each server in the chain can either answer directly or point the resolver toward the server that can. That handoff process is called delegation, and it’s worth understanding in more depth than we have room for here.

See our DNS delegation guide for how that hierarchy works and what happens when it degrades.

Read the guide

To follow along at the packet level yourself, a tool like Wireshark makes DNS packets human-readable. Open Wireshark, start a capture, and filter ondns; every packet you see will have the structure described below.

Reading a DNS Packet

Every DNS message, query or response, is built from the same sections.

Here’s what each one tells you.

Header

The header is a fixed 12-byte block at the start of every message.

It carries a transaction ID (used to match a response to its query) and a set of flags that tell you what kind of message you’re looking at: whether it’s a query or a response (QR), whether the answer came from an authoritative server (AA), whether the query wants a full recursive lookup (RD) or just a referral, and a return code (Rcode) that’s 0 for success or 3 if the domain doesn’t exist.

The remaining header fields simply count how many questions and records follow.

Question

Question is what’s actually being asked, like a hostname, a record type (A, AAAA, MX, NS, and others), and a class (almost always “IN” for Internet).

There’s typically one question per packet.

Answer Resource Records

Answer is the record(s) that respond to the question, usually an A, AAAA, or CNAME record for a web lookup. Each answer record carries its own TTL, which controls how long that answer can be cached before it needs to be looked up again.

Read our DNS TTL and caching guide to learn how TTL is chosen, how it counts down across resolvers, and where it becomes a performance-versus-security trade-off

Read the guide

Authority Resource Records

Authority records appear when a server doesn’t have the answer itself and instead returns the NS records for the servers that do, part of the same delegation chain mentioned above.

Additional Records

Additional records, also called glue records, are the IP addresses for the name servers listed in the Authority section. They’re included so the resolver doesn’t need a separate lookup just to find them.

Dig Deeper

This guide covers the basics. For the topics that matter most once DNS is running in production, our DNS Monitoring Deep Dive series covers each in detail:

DNS delegation and recursion: how resolvers walk from root to authoritative servers, and what breaks when delegation is misconfigured.
DNS TTL and caching: how TTL values shape performance and consistency, and the caching pitfalls to watch for.
Slow DNS: the most common causes of DNS latency and how to fix them.
DNSSEC: how cryptographic validation protects DNS records from tampering.
DNS attacks and prevention: cache poisoning, tunneling, floods, and hijacking, plus how to defend against each.
DNS health testing and monitoring: how to continuously verify DNS performance, availability, and configuration across your environment.

Monitor your DNS infrastructure end-to-end with LogicMonitor Synthetics and Internet Performance Monitoring

DNS failures cascade fast. Combine LogicMonitor’s infrastructure observability with Internet performance onitoring to detect resolution issues before they reach your users.

Request a Demo

FAQs

What transport protocol does DNS use by default?

DNS uses UDP (User Datagram Protocol) by default because it requires no handshake and completes lookups in fewer round trips. When a response is too large to fit in a single UDP packet or a firewall blocks UDP, DNS falls back to TCP, which adds reliability at the cost of additional round trips.

Why do most DNS queries resolve in milliseconds?

Caching at every layer of the DNS hierarchy means most queries never need to walk the full chain from root server to authoritative name server. Recursive resolvers, operating systems, and even browsers store previous answers for the duration of each record’s TTL, so repeat lookups for popular domains return almost instantly.

How can I inspect DNS packets myself?

You can use a packet analysis tool like Wireshark to capture and read DNS traffic in real time. Start a capture, apply a “dns” filter, and each packet will show the standard DNS message structure: a 12-byte header with transaction ID and flags, a question section with the queried hostname and record type, and answer, authority, and additional sections containing the returned records.

14-day access to the full LogicMonitor platform

Culture