Fundamentals

The OSI model: where DNS lives

TL;DR

DNS is application layer, OSI L7 (ISO/IEC 7498-1:1994). It rides on four layers that have to work first:

application   DNS, HTTP
transport     UDP 53, TCP 53, TLS 853, QUIC
network       IP routing, and whether the resolver is reachable at all
link          the cable, the wifi, the VLAN

When DNS misbehaves, check those four before you blame DNS.

Asks for an address over UDP port 53, the layer DNS lives on.

$ dig @1.1.1.1 isitdns.net A

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 isitdns.net A

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2289

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;isitdns.net. IN A

;; ANSWER SECTION:

isitdns.net. 300 IN A 104.21.56.211

isitdns.net. 300 IN A 172.67.155.242

;; Query time: 33 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Mon Sep 14 17:42:30 CDT 2026

;; MSG SIZE rcvd: 72

GO NOERROR and a SERVER line ending (UDP)

NO GO a timeout

run this query in the dig tool →

what each part of this output means →

The 7 layers, in 60 seconds#

#	Layer	What it moves	Example	What it answers
7	Application	Data	DNS, HTTP, SSH, SMTP	"What does the program want?"
6	Presentation	Encoded data	TLS, character encodings	"What does the data mean once decoded?"
5	Session	Conversations	Less relevant on TCP/IP networks	"Are we still talking?"
4	Transport	Segments	TCP, UDP, QUIC	"Did it arrive, and in order?"
3	Network	Packets	IPv4, IPv6, ICMP	"How do I route this across networks?"
2	Data link	Frames	Ethernet, ARP, 802.1Q VLAN tags	"How do I hand this to the next hop on this wire?"
1	Physical	Bits	Copper, fiber, radio	"Is the cable plugged in?"

Real TCP/IP stacks collapse layers 5 to 7 into one application layer (RFC 1122 defines four: application, transport, internet, link). The seven-layer names above are still what people say when they point at where something broke.

What breaks silently at each layer#

A DNS query rides every layer below it to reach a resolver, and any of them can swallow it with no error:

L1 down: no link, no DNS.
L2 wrong VLAN: the frame is dropped at the switch port; the resolver looks unreachable. Detail below.
L3 no route: traceroute to the resolver dies before it arrives.
L4 port 53 blocked: every query times out. The subtler case: UDP/53 open, TCP/53 blocked, so everything works until a truncated answer forces a TCP retry. RFC 7766 requires both transports; a firewall that allows only UDP/53 is misconfigured.
L6 TLS mismatch: DoT/DoH negotiation fails; plain Do53 still works, which confuses the picture.
L7: SERVFAIL, NXDOMAIN, a wrong answer: DNS itself. servfail and dnssec-troubleshooting cover it.

Debug bottom-up: link, then route, then port, then DNS.

Check it yourself, bottom-up#

Using 1.1.1.1 as a stand-in for your resolver:

Layer	Check	Command
L3	reachable at all?	`ping -c 3 1.1.1.1`
L4	is port 53 open?	`dig @1.1.1.1 example.isitdns.net +tries=1 +time=2`
L7	does DNS answer correctly?	`dig @1.1.1.1 isitdns.net A`

If ping fails, look at L3 routing, or L2 below. If ping succeeds but the L4 dig times out, UDP 53 is blocked on the path or the resolver is not answering (RFC 8906 §3.1.3). If the L7 dig returns SERVFAIL, retry with +cd (checking disabled): a NOERROR on that retry means a broken DNSSEC chain, not a network problem (dnssec-troubleshooting has the steps).

nc -u cannot be trusted to report a closed UDP port: UDP has no handshake (RFC 768), so a real DNS round-trip is the only reliable L4 UDP probe.

nslookup cannot probe individual layers or set +cd. Use ping for L3, dig for L4 and L7.

The expected L4 answer above is a single A record, 192.0.2.1: a documentation address (RFC 5737) that resolves on purpose but routes nowhere. Why this wiki's examples work that way.

What lives at each layer (typical DNS-serving environment)#

Layer	What you'll usually find
L7	The DNS server: authoritative, recursive, or both. See query-types for the resolver role breakdown.
L6	TLS for DoT (`:853`) and DoH (`:443`). DoQ folds its TLS 1.3 into the QUIC layer, so there is no separate L6 step.
L4	UDP/53 + TCP/53, both mandatory (RFC 7766); TCP/853 for DoT (RFC 7858); UDP/853 for DoQ (RFC 9250); TCP/443 for DoH (RFC 8484), or UDP/443 over HTTP/3
L3	IPv4 + IPv6 routing to the resolver. The address ranges below.
L2	Ethernet with 802.1Q VLAN tagging if the network is segmented. Detail below.
L1	Whatever copper, fiber, or radio link the resolver actually sits on

Layer 2 in practice: ARP and VLANs#

DNS does not run at L2, but every query crosses the local segment twice as an Ethernet frame, tagged for a VLAN under 802.1Q (IEEE Std 802.1Q) if the network is segmented. A misconfigured switch port drops the frame with no error anywhere; the application sees a timeout.

Check the ARP (or NDP, RFC 4861) cache before blaming the resolver:

ip neigh

REACHABLE or STALE is healthy. The resolver or gateway stuck in INCOMPLETE or FAILED never made it onto the wire: dig reports ;; no servers could be reached. macOS ships arp -a instead of ip neigh.

Symptom	L2 cause to check
`dig` times out and `ip neigh` shows the resolver `INCOMPLETE` or `FAILED`	wrong VLAN at the client's port
One host resolves, another on the same subnet cannot	two ports on two different VLANs, same L3 subnet on paper
Internal names resolve, every external query times out	resolver forwards to a gateway on a different VLAN than the one it answers on
`arp -d` "fixes" it for a minute	stale ARP entry: the IP moved MACs and the cache did not refresh

Capture filters for proving a VLAN tag on the wire: wireshark-dns-filters.

The addresses you'll meet#

Three kinds of IP address show up in DNS work, and knowing which is which keeps you from leaking your own network or breaking an example:

Category	Ranges	Property
Public	ISP-assigned or RIR-allocated	Routable and identifying. Do not publish yours in docs.
Private	`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` (RFC 1918); ULA `fc00::/7`, of which `fd00::/8` is the locally assigned half everyone actually uses (RFC 4193)	Routes only inside your network. Everyone uses the same numbers, so they identify nothing.
Documentation	`192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24` (RFC 5737); `2001:db8::/32` (RFC 3849); reserved names like `example.com` and `.test` (RFC 2606)	Reserved for examples.

This wiki's live examples mix the last row with a real zone: example.isitdns.net publishes an A record of 192.0.2.1 and an AAAA record of 2001:db8::1. Both resolve, so every example is runnable; neither routes, so no packet lands on anyone's real host:

dig @1.1.1.1 example.isitdns.net A +short

192.0.2.1

Two DNS consequences worth keeping in mind:

Reverse lookups for private space never resolve in the public tree. Resolvers serve the RFC 1918 reverse zones out of their own local data (RFC 6303), which means NXDOMAIN for any address inside the block, and queries that escape anyway land on the AS112 blackhole servers (RFC 7534), which answer the same way below the zone name. Reverse DNS for your 192.168.0.0/24 means standing up your own zone: reverse-dns.
Split-horizon DNS serves RFC 1918 answers internally and public ones externally, same name, two record sets, picked by the client's source address.

Use a documentation address in anything public. The ranges exist exactly so you never have to make that call under pressure.