The OSI and TCP/IP Models

The seven layers of the OSI model

The OSI reference model was published by the International Organization for Standardization (ISO) in the 1980s alongside a protocol suite that never displaced TCP/IP. The model outlived the protocols because its layer numbers turned out to be useful shorthand. From top to bottom:

Layers 1 and 2 deal with getting bits and frames across one link. Layer 3 handles addressing and routing across many links. Layer 4 provides end-to-end delivery between programs, identified by port numbers. Layers 5 to 7 cover everything the application needs. In practice, layers 5 and 6 rarely map cleanly to separate protocols, which is one reason the TCP/IP model folds them into the application layer.

The TCP/IP model and how the two map

The Internet's own architecture documents, notably RFC 1122, Requirements for Internet Hosts: Communication Layers, describe four layers: link, internet, transport, and application. The model is pragmatic. It describes protocols that exist rather than an ideal design.

DNS is the bridge between the top row and the rows below it: it turns the names applications use into the IP addresses the internet layer needs. Some textbooks show a five-layer hybrid that splits the link layer into physical and data link. That is the same idea with a different cut.

Encapsulation: following one DNS query down the stack

Each layer wraps the data from the layer above with its own header, a process called encapsulation. The receiving host unwraps them in reverse order. Here is a plain DNS query for an A record, sent over UDP and IPv4 on Ethernet:

The DNS message itself has a fixed 12-byte header followed by the question, as defined in RFC 1035, Domain Names: Implementation and Specification. UDP adds source and destination ports. IPv4 adds source and destination addresses and a TTL field that routers decrement, which is what traceroute relies on. Ethernet adds the MAC addresses of the next hop only, and that header is replaced at every router along the way, while the IP header travels end to end.

Encapsulation explains several DNS behaviors. Every header uses part of the link's maximum transmission unit (MTU), so a large DNSSEC answer may not fit in one packet, as described in MTU, Fragmentation and Big DNS Answers. When a resolver switches to TCP, the transport layer changes and the DNS message stays the same. With DNS over HTTPS, the DNS message is wrapped in HTTP, then TLS, then TCP or QUIC, adding layers above transport without changing DNS itself. It also means the ping and port 53 tests below say nothing about DoH, which travels on port 443 like web traffic, and that some resolvers never answer ping even when DNS works.

Using the layers to troubleshoot

The most reliable way to troubleshoot is to test from the bottom up and stop at the first layer that fails. Higher layers cannot work if a lower one is broken, so a failing dig tells you little until you know the layers beneath it are healthy.

Link: is the interface up?

$ ip -br link show eth0
eth0             UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Network: is there a route, and does the resolver answer pings?

$ ip route get 192.0.2.53
192.0.2.53 via 198.51.100.1 dev eth0 src 198.51.100.20 uid 1000
$ ping -c 2 192.0.2.53
64 bytes from 192.0.2.53: icmp_seq=1 ttl=58 time=11.8 ms
64 bytes from 192.0.2.53: icmp_seq=2 ttl=58 time=11.6 ms

Transport: is TCP port 53 reachable?

$ nc -vz 192.0.2.53 53
Connection to 192.0.2.53 53 port [tcp/domain] succeeded!

Application: does the resolver answer the question?

$ dig @192.0.2.53 example.com A +short
203.0.113.10

Remember that ICMP is often filtered, so a failed ping does not prove the host is down. Treat each test as evidence rather than proof, and move up a layer once you have reasonable confidence. How to Read a Traceroute covers the network-layer path in more detail, and TCP vs UDP and Why DNS Uses Both covers the transport layer.

Where the models bend

Real protocols do not always fit in one box. TLS sits between transport and application and is described as layer 4, 5, 6, or 7 depending on who you ask. QUIC is a transport protocol that runs on top of UDP, another transport protocol, and includes its own encryption. MPLS labels are sometimes called layer 2.5. ARP links layer 2 and layer 3 addresses. VXLAN carries layer 2 Ethernet frames inside layer 4 UDP packets.

None of this makes the models wrong. They are tools for communication, not laws of physics. When a colleague says "layer 7", they mean the application protocol is visible to the device. When they say "layer 3 boundary", they mean a router sits there. Use the models to agree on where a problem is, then look at the actual packets.

How DNS Panopticon helps

DNS Panopticon's tools work at the application layer: they look at DNS records and what they reveal. Domain Visualizer checks a domain's public DNS records and delegation. Website Recon goes one step down the stack: it looks up each resolved IP address in RDAP to find the network and autonomous system number (ASN) that announces it, which tells you whose network a name actually lands on. For link, routing, and transport problems on your own network, the command-line checks above remain the right tools.