🧱 The OSI model: where DNS lives, and what's underneath

Before DNS makes sense, you need a picture of the layers it sits on. When DNS misbehaves, the cause is almost always in a layer below it. This page is the map.

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?"

The OSI model is a teaching abstraction. The real TCP/IP stack collapses 5/6/7 into one "Application" layer in practice (RFC 1122 defines just four layers: application, transport, internet, link). But the seven boxes are still the language people use to point at where something is broken, and that's why you learn it.

Where DNS lives: and what it depends on#

┌───────────────────────────────────────────────┐
│  L7  Application  →  DNS                      │   "dig example.com"
├───────────────────────────────────────────────┤
│  L6  Presentation →  TLS (for DoT / DoH)      │   only when encrypted
├───────────────────────────────────────────────┤
│  L4  Transport    →  UDP/53 (or TCP/53)       │   most queries are UDP
├───────────────────────────────────────────────┤
│  L3  Network      →  IP (v4 or v6) routing    │   resolver must be reachable
├───────────────────────────────────────────────┤
│  L2  Data link    →  Ethernet + VLAN tag      │   right port, right VLAN
├───────────────────────────────────────────────┤
│  L1  Physical     →  cable / Wi-Fi            │   the cable is in
└───────────────────────────────────────────────┘

A DNS query is a tiny application-layer message that has to ride every layer below it to reach a resolver. Any of those layers can swallow it silently:

L1 down: no link, no DNS.
L2 wrong VLAN: frame is dropped at the switch port. Resolver looks unreachable. See foundations-layer2 and foundations-vlans.
L3 no route: traceroute to the resolver dies before it arrives.
L4 firewall blocks port 53: every query times out. The subtler variant: UDP/53 is open but TCP/53 is blocked, so everything works until a response is too big for UDP (truncation forces a retry over TCP) or a zone transfer is needed. RFC 7766 requires DNS implementations to support both transports; firewalls that allow only UDP/53 are misconfigured.
L6 TLS mismatch: DoT/DoH negotiation fails; plain Do53 on port 53 still works, which confuses the picture.
L7 server returns SERVFAIL: the only one that's actually DNS. See dnssec if the failure is DNSSEC-related.

This is why old hands debug bottom-up. Cable → VLAN → IP → port → DNS. Each step takes seconds. Starting at L7 and working down is how you lose an afternoon.

The "is it DNS?" loop, layered#

The three-stage incident (it's not DNS · there's no way it's DNS · it was DNS) is funny precisely because everyone reaches for L7 first. The wiki's whole premise is: once you can prove which layer broke, you stop guessing.

   "DNS is broken"
        │
        ▼
   ┌────────────────────────────────────────────┐
   │ Is L1 up?       ─ ip link, cable, Wi-Fi    │
   │ Is L2 right?    ─ correct VLAN, ARP works  │
   │ Is L3 reachable? ─ ping the resolver       │
   │ Is L4 open?     ─ nc -z resolver 53        │
   │ Does DNS work?  ─ dig @resolver isitdns.net│
   └────────────────────────────────────────────┘
        │
        ▼
   one of those said "no", that's the layer

Here is what each step looks like as an actual command, using 1.1.1.1 as a stand-in for your resolver:

L3: can you reach the resolver at all?

ping -c 3 1.1.1.1

L4: is port 53 open? (TCP probe)

nc -z 1.1.1.1 53

For UDP/53 specifically, nc -u reports success even on a closed port on most systems because UDP is connectionless. Use a real DNS round-trip instead:

dig @1.1.1.1 example.isitdns.net +tries=1 +time=2

If this returns a response, UDP/53 is open and the resolver is answering. The expected answer is a single A record, 192.0.2.1: a documentation address (RFC 5737) that resolves on purpose but routes nowhere, so the lookup is safe to run anywhere. See ip-address-spaces for why this wiki's example records work that way. If the query times out, port 53 UDP is blocked somewhere between you and the resolver.

nslookup cannot probe individual layers. Use nc for TCP L4, dig for UDP L4, ping for L3.

L7: does DNS respond correctly?

dig @1.1.1.1 isitdns.net A

nslookup -type=A isitdns.net 1.1.1.1

If ping and nc both succeed but dig fails, the problem is at L7. If ping fails, look at L3 routing or L2 VLAN config. If dig returns SERVFAIL, retry the same query with +cd (checking disabled): if the +cd retry succeeds, the network path is fine and you are looking at a broken dnssec chain on a validating resolver, not a network problem. (A SERVFAIL never carries the ad flag, so the flag's absence tells you nothing there.)

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

A concrete map you can point at when something breaks:

Layer	What you'll usually find
L7	The DNS server itself: authoritative, recursive, or both. Could be a home router's built-in resolver, an open-source DNS server, or a commercial DNS appliance. See query-types for the resolver role breakdown.
L6	TLS terminations for DoT (`:853`) and DoH (`:443`). DoQ folds its TLS 1.3 into the QUIC layer itself, so no separate L6 TLS step is visible to a troubleshooter.
L4	UDP/53 + TCP/53 for classic DNS (both are mandatory per RFC 7766), TCP/853 for DoT (RFC 7858), UDP/853 for DoQ (RFC 9250), TCP/443 for DoH (RFC 8484), or UDP/443 when DoH rides HTTP/3
L3	IPv4 + IPv6 routing to the resolver, public or private addressing. See ip-address-spaces for the address ranges you'll encounter.
L2	Ethernet with 802.1Q VLAN tagging if the network is segmented. See foundations-layer2 for the full L2 picture.
L1	Whatever copper, fiber, or radio link the resolver actually sits on

Rule of thumb#