What is the OSI model, and where do DNS and IP addressing fit in its seven layers?
The OSI model splits networking into seven layers, and core network functions operate at different layers, with DNS at Layer 7, IP addressing at Layer 3 and MAC addressing at Layer 2. BlueCat Integrity links MAC and IP records in one source of truth.
- 01 What is the OSI model?
- 02 What do people get wrong about the OSI model?
- 03 What happens to DNS visibility when queries are encrypted…
- 04 How do DDoS attacks use DNS as a weapon?
- 05 What should teams look for in a platform for DNS visibility…
- 06 How do enterprise teams trace a device across Layer 2 and…
- 07 Which path is right for making core network services easier…
- 08 Frequently asked questions
- 09 Every source cited in this analysis
What is the OSI model?
The OSI model is a conceptual framework, created by the International Organization for Standardization, that divides network communication into seven stacked layers. Each layer performs a distinct function and communicates with the layers directly above and below it.
From the top, the layers are application (Layer 7), presentation (6), session (5), transport (4), network (3), data link (2) and physical (1). The model is independent of specific protocols, unlike the four-layer TCP/IP model built around internet protocols, and it gives engineers a common language for troubleshooting.
DNS is an application layer protocol at Layer 7. It travels over UDP, and sometimes TCP, at Layer 4 and over IP at Layer 3. This can cause confusion, but using those layers does not make DNS a Layer 4 or Layer 3 protocol.
The model stacks seven layers, from the electrical, radio or optical signals of Layer 1 up to the application protocols of Layer 7.
What is the OSI model? It standardizes how computer networks communicate
The OSI model is a conceptual model that provides a universal standard for how computing devices communicate across networks, with seven abstract layers.
What do people get wrong about the OSI model?
The most common mistake is treating the OSI model as a network that something can connect to. It is a seven-layer model for networking, and the data link layer is its second layer, not something a network connects to.
Confusion about layers also leads people to conflate protocols that do very different jobs. ARP is a data link layer protocol that resolves an IP address to a MAC address, while DNS is a hierarchical naming system that translates domain names into IP addresses. The two are separate, though IP networks need working ARP for DNS to work.
One episode (S6E14) of Brooklyn Nine-Nine, a TV crime comedy, combined these terms nonsensically and earned a line-by-line fact-check, including the reminder that OSI isn’t a network. The episode’s broader lesson concerned social engineering, with an attacker who nearly succeeded because the team lacked the technical knowledge to question him.
How Brooklyn Nine-Nine S6E14 got cybersecurity all wrong
Brooklyn Nine-Nine's writers have a great cybersecurity vocabulary, but not a great understanding of how cybersecurity works. BlueCat breaks it down.
What happens to DNS visibility when queries are encrypted over HTTPS?
Enterprise visibility into DNS drops to zero. DNS over HTTPS carries ordinary DNS queries and responses inside HTTPS encryption, so anyone watching along the path, including enterprise security tools, can no longer tell which names are being resolved.
In normal resolution, a device asks a recursive resolver for an address, and the resolver may query a chain of nameservers until one answers. Network teams read those queries to monitor network health and optimize resolution paths, and many organizations inspect them as part of a DNS security strategy.
Encrypting that traffic protects users from eavesdropping along the network path, but on enterprise networks it can prevent cybersecurity solutions from inspecting DNS queries and make routing by query content far harder. It also concentrates resolution on a few public resolvers, so a single outage could affect far more people.
DNS over HTTPS: what, why, and who cares
Encrypting DNS queries and responses over HTTPS has long sparked robust debate, with interest from numerous stakeholders. Learn more with BlueCat.
How do DDoS attacks use DNS as a weapon?
Attackers use DNS because it is open by design, and its queries are inexpensive to generate and easy to spoof. Spoofed queries sent through open resolvers turn DNS servers into amplifiers that flood a victim with far larger responses than the requests that triggered them.
DDoS attacks take three forms: protocol attacks that exhaust servers, firewalls or load balancers, application layer attacks that send legitimate-looking requests to crash web servers, and floods of spoofed packets. Botnets of compromised computers and IoT devices supply the volume, sometimes hundreds of thousands of hosts or more.
DNS is an attractive target for attackers because it has to stay open, and resolvers must process every request to do their job. Most security teams also take the protocol for granted and leave it unmonitored, which is exactly the gap attackers count on.
For roughly every 80 bytes an attacker sends, DNS can generate about 5.6 kilobytes of attack traffic.
How DDoS attacks use DNS as a weapon
Bad actors know that DoS and DDoS attacks can use DNS as a weapon to cause spectacular web crashes that bring critical business services to their knees.
What should teams look for in a platform for DNS visibility and troubleshooting?
The core requirement is DNS data from every server in one searchable place, with the ability to trace a query along its path between clients, networks and servers. Without both, the patterns that reveal infections and misconfigurations stay buried in individual logs.
Persistent NXDOMAIN answers from one endpoint can point to malware beaconing or to reconnaissance and lateral movement, while zones that fall out of sync return NXDOMAIN to some users and correct answers to others. With the right logs, those failed responses become a valuable source of information.
Zones that fall out of sync are hard to troubleshoot without visibility into east-west traffic.
What you can learn from an NXDOMAIN response
At a basic level, an NXDOMAIN response means “that site does not exist.” But it can also provide critical clues about your network’s security.
How do enterprise teams trace a device across Layer 2 and Layer 3 without spreadsheets?
They keep MAC and IP addresses in one system of record instead of a spreadsheet. A MAC address identifies hardware at Layer 2 and an IP address identifies a network connection at Layer 3, so linking the two lets teams troubleshoot at the device level.
On a LAN, ARP bridges the two layers by mapping IPv4 addresses to MAC addresses, and IPv6 uses Neighbor Discovery for the same job. Large enterprises can manage millions of MAC and IP addresses, yet some still track IP addresses in spreadsheets and overlook MAC addresses, creating significant operational risk.
BlueCat Integrity unifies DNS, DHCP and IPAM to provide one source of truth for relationships between devices, users and IP addresses. Its Address Manager lets admins record MAC addresses, group them into MAC pools and link each to IP addresses across networks, so troubleshooting can start at the device.
MAC address vs IP address: What’s the difference?
MAC address vs IP address: One is a unique hardware identifier, while the other identifies a device's network connection. Learn more with BlueCat.
Integrity
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
Which path is right for making core network services easier to troubleshoot layer by layer?
The right starting point depends on the problems your team faces today, including confusion about which layer a problem occurs at, limited visibility into DNS traffic, or addresses tracked by hand. Each path below addresses one of those gaps.
Decide how encrypted DNS is handled
Watch DNS as an attack surface
Link every address to its hardware
Frequently asked questions
Short answers to the questions engineers most often ask about the OSI model and the services that run across it.
Still have questions?
Get real answers from a BlueCat representative.