🧱 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#

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 the L2 section below.
• 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 the address section below 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 2 in practice: ARP and VLANs#

DNS does not run at L2, but every query crosses your local segment twice, query out and answer back, and a misconfigured switch port drops the frame with no error anywhere. The application sees a timeout and blames DNS. Two mechanisms cover most of it.

ARP is the step before any query leaves. Your host knows the resolver's IP but a frame needs a destination MAC, so it broadcasts "who has this IP?" (RFC 826) and caches the answer. If the resolver sits on a different subnet, the host ARPs for its default gateway instead, and it is the gateway's MAC that lands in the cache. IPv6 does the same job with NDP (RFC 4861). Check the cache:

ip neigh

Entries in REACHABLE or STALE are healthy (STALE only means "not confirmed recently"). The resolver or gateway stuck in INCOMPLETE or FAILED means the query never made it onto the wire: dig retries with ;; communications error to <resolver>#53: timed out and ends with ;; no servers could be reached. macOS ships arp -a instead of ip neigh.

VLANs decide which wire you are on. An 802.1Q tag (IEEE Std 802.1Q) is 4 bytes in the Ethernet frame that assign it to a broadcast domain; a switch only forwards the frame to ports in the same VLAN. A port on the wrong VLAN, a trunk with a wrong allowed list, or a native-VLAN mismatch between two switches all fail the same way: the frame is silently gone. What that looks like from the DNS side:

To prove whether frames are tagged, capture on the trunk parent interface; tcpdump decodes the 802.1Q header and prints the VLAN ID on every match:

sudo tcpdump -ni eth0 -e -c 2 'vlan and port 53'

ethertype 802.1Q (0x8100) plus vlan 101 in the output means the query crossed the trunk tagged for VLAN 101. A wrong ID, or no tag where you expected one, points at the switch port or sub-interface configuration, not the resolver. On an access port this filter matches nothing, because the switch strips the tag before the frame reaches you. More capture filters live on 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:

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 your head:

• 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; the mechanics are on 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.

When writing anything public, substitute a documentation address. The ranges exist exactly so you never have to make that call under pressure.

Rule of thumb#

Troubleshoot the stack in order. Each layer tells you where to go next: link, then address, then route, then port, then resolver, then zone. Start at the bottom and stop at the first layer that fails.

See also#

• anatomy-of-a-query: once the layers are up, what actually happens inside the DNS protocol
• query-types: recursive, iterative, and forwarding query types
• dot-doh: DNS over TLS and DNS over HTTPS, the L6 story
• dnssec: DNSSEC validation, the L7 security layer
• reverse-dns: where private address space meets the DNS tree
• wireshark-dns-filters: capture filters for every layer, L2 tags included
• nslookup-and-dig: the two CLI tools for testing every layer from L7 down