DNS-layer security: what layer is DNS and why protect it?

What layer is DNS?

DNS is an application-layer protocol. In the seven-layer OSI model it sits at layer 7, alongside HTTP and SMTP; in the four-layer TCP/IP model it sits in the application layer. It feels like infrastructure because every other service depends on it, but technically it is an application that other applications rely on before they connect.

Underneath, DNS is carried by transport-layer protocols. Which one depends on the type of DNS:

The ports matter for security. Classic DNS and DoT use dedicated ports, so a firewall can force them through your chosen resolver. DoH shares port 443 with ordinary web traffic, which is why it can slip past network controls; see encrypted DNS and should you block DNS over HTTPS?.

What is DNS-layer security?

DNS-layer security is protection applied at the moment a device looks up a domain. The device's lookups go to a protective resolver, which checks each domain against threat intelligence and your policy before answering. If the domain is malicious or blocked, the resolver does not return its real address, so the connection does not begin.

That makes it a first control: it acts before a TCP session opens, before a TLS handshake, before any content downloads. Cisco uses the term for the DNS protection in Cisco Umbrella and Cisco Secure Access, and the same approach is used by every protective DNS service, including the NCSC's protective DNS service for the public sector. Our what is DNS security? guide covers the lookup process step by step.

Why block threats at the DNS layer

• Before the connection: a blocked lookup means no session, no handshake and no download, so there is nothing to clean up afterwards.
• Every port and protocol: it covers any application that resolves names, not just web browsers on ports 80 and 443.
• Every device on the network: printers, cameras and guest devices that cannot run an agent are still protected when they use your resolver.
• Light to deploy: changing DNS settings or forwarders needs no new hardware, and there are no certificates to install for basic blocking.
• Early warning: repeated lookups for command-and-control domains point you to a device that may already be infected.
• Works off site too: roaming clients keep laptops and mobiles on the protective resolver at home and on public Wi-Fi.

How DNS-layer security complements other controls

DNS-layer security does not replace firewalls, proxies or endpoint protection. Each layer sees something different:

In practice the DNS layer removes a large share of obvious threats cheaply, so the heavier controls behind it deal with less. Our page on DNS filtering vs URL filtering explains when the extra proxy layer is worth adding.

The limits of DNS-layer security

• It sees domains, not pages. A malicious file on a trusted domain resolves like everything else.
• It cannot inspect content. Nothing is downloaded or scanned at the DNS layer.
• Direct-to-IP traffic is invisible. Malware that connects straight to an IP address makes no lookup. Cisco's DNS-only Umbrella packages, for example, cannot see these connections.
• Bypass is possible through browser DoH to another provider, hard-coded DNS servers or personal VPNs, unless firewall rules and device policy close those routes.
• Threat lists are not instant. A brand-new malicious domain may not be categorised yet, which is why optional newly-registered-domain categories exist.

None of these is a reason to skip the DNS layer; they are reasons to pair it with the right controls and to test it properly.

Building up from the DNS layer

Many services let you start at the DNS layer and add depth only where you need it. Cisco's model is a good worked example:

1. DNS layer: Umbrella DNS Security Essentials, or its migration product Secure Access DNS Defense Essentials, blocks threats and content categories at lookup.
2. Selective proxy: Umbrella DNS Security Advantage sends traffic for risky domains to an intelligent proxy that can inspect URLs and files on just those domains. Cisco's DNS Defense data sheet also lists selective proxying and inspection; we confirm which DNS Defense package includes what against Cisco's current package guide when we quote.
3. Full web gateway: the Umbrella SIG packages, whose migration product is Secure Internet Access in Cisco Secure Access, send web traffic through a cloud secure web gateway and firewall.

Our Cisco DNS-layer security page maps every Umbrella and DNS Defense package to this model. Outside Cisco, SASE platforms such as Check Point SASE Internet Access, Todyl and NordLayer combine DNS filtering with web controls, and products such as Webroot DNS Protection and ThreatDown DNS Filtering add the DNS layer to an endpoint agent you may already run. DNS security solutions compares them.

Where DNS-layer security fits best

DNS-layer protection suits almost any organisation, but it is especially useful in a few situations:

• Small teams without a security operations function, who want a control that works in the background and needs relatively little day-to-day attention once tuned.
• Multi-site organisations, where every branch can point at the same protective resolver without new hardware at each site.
• Hybrid and remote workers, whose laptops spend more time on home broadband than on the office network, protected through a roaming client.
• Schools, colleges and trusts, which need content filtering across shared and personal devices as well as security; see web filtering for schools.
• Guest and public Wi-Fi, where you cannot install anything on the devices that connect.
• Devices that cannot run an agent, such as printers, screens, cameras and other connected equipment, which still use your resolver.

It is less suited to being the only web control where you need page-level policy, file scanning or data loss prevention on web traffic. In that case DNS is the first layer, and a secure web gateway or SASE platform does the rest.

Getting DNS-layer security in place

For most organisations the first steps are the same: point every network and internal DNS server at a protective resolver, keep internal names resolving locally, block outbound DNS that does not go through your resolver, control browser DoH, and put a roaming client on devices that leave the office. Our DNS security best practices checklist covers each step.

We can review how DNS flows in your organisation today and recommend the DNS-layer option that fits what you already run. Contact us for advice or a quote.