Why DNS-layer security stops attacks your firewall never sees

Your firewall inspects what crosses the perimeter. It never sees a laptop at a kitchen table in Downingtown, on home Wi-Fi, clicking a link in a text message. That laptop still does one thing before it reaches anything on the internet: it asks a DNS server where to go. DNS-layer security puts a checkpoint at that question. Phishing pages, malware downloads, and the callbacks infected machines make to their operators all depend on name resolution, which makes DNS the one place to stop them before a packet reaches the destination.

Almost every attack starts with a lookup

Walk through a typical phishing intrusion. An email or text carries a link to a lookalike domain. The user clicks, the device resolves the name, the page loads, and a password goes into a form that forwards it to the attacker. If the lure carries an attachment instead, it pulls its real payload from a domain the attacker registered, and once that payload runs it has to phone home for instructions.

That last step is where DNS matters most. MITRE ATT&CK catalogs DNS as a command and control channel in its own right (T1071.004, Application Layer Protocol: DNS). Attackers use it because DNS is permitted on nearly every network, is often allowed before a device has authenticated, and blends into normal traffic. A separate technique, Dynamic Resolution (T1568), covers malware that generates fresh domain names on a schedule or rotates addresses behind one name, so that blocking yesterday's indicator does nothing today. Both share a dependency: the infected machine has to resolve a name. Take the answer away and the malware is stranded.

This is why NSA and CISA published "Selecting a Protective DNS Service," and why protective DNS appears among the controls in the October 2023 phishing guidance from CISA, NSA, FBI, and MS-ISAC, next to phishing-resistant MFA and application allowlists.

What protective DNS is, and what it is not

Protective DNS is a resolver that applies policy. Instead of answering every query, it checks the requested name and the returned address against threat intelligence and refuses to answer for domains known or suspected to be malicious. The NSA/CISA sheet describes the two common responses: an NXDOMAIN reply, which tells the device the name does not exist, or a redirect to a block page that explains why. Some providers also sinkhole a domain, answering with an address they control, which buys time to investigate.

The categories it addresses match the attack chain above: credential-harvesting and lookalike phishing domains, malware distribution and command and control infrastructure, and algorithmically generated domains flagged by their patterns. Cisco Umbrella, the service we deploy, states that its DNS-layer protection blocks malware, phishing, and command and control callbacks over any port.

Now the limits, which the NSA/CISA sheet states plainly.

Direct-to-IP traffic bypasses it. If malware is coded with a hard IP address and never asks a question, a resolver never sees it. The sheet says plainly that protective DNS "is bypassed by any traffic using IP addresses directly without doing DNS lookups."

Alternative resolvers bypass it. A program can ignore the resolver DHCP hands out and send queries elsewhere: plain port 53, DNS over TLS on port 853, or DNS over HTTPS inside ordinary web traffic. Browsers can do this on their own. The sheet's answer is to block outbound 53 and 853 from everything except your sanctioned resolvers and to configure browsers so DoH uses only the resolver you designate, or is off.

It is one layer. Protective DNS stops the connection. It does not see what runs on the endpoint, and it cannot catch a payload that arrived on a USB stick or an attacker inside a compromised VPN account. NSA and CISA state that "customers should not rely on it alone to detect and prevent malicious traffic." In practice that means pairing it with managed EDR, which watches process behavior whether or not a lookup happened.

Who this affects and how to check

If staff work from home, client sites, or coffee shops, they are affected, because the office firewall is not in the path. Guest Wi-Fi, printers, and cameras that never get patched resolve names too and can be the ones phoning home.

Three checks tell you where you stand. First, on a company laptop off the office network, run nslookup (or dig on a Mac) against any domain and look at which server answered. If it is the home router or the ISP, nothing is filtering. Second, look in your firewall policy for an outbound rule allowing port 53 from any internal host to any destination. If it exists, any device can route around whatever resolver you pick. Third, ask whether you can produce a DNS query log for one workstation for last Tuesday. CISA's alert on the guidance notes that those logs are what incident response and threat hunting run on.

What it costs when the lookup goes through

A credential phish that resolves and loads costs you a mailbox, and with it a business email compromise investigation, company-wide password resets, and the call to the client whose invoice got redirected. A malware callback that resolves costs you the window between infection and encryption, exactly the window in which a block would have stranded the payload. Either way, incident response starts by asking what the machine resolved and when, and only a logged resolver can answer.

What to do this month

1. Pick a protective DNS service and point the office at it. Change DHCP option 6 so clients receive the service's resolvers, or set your internal DNS servers to forward there. With Active Directory, keep internal zones on the domain controllers and forward everything else. The roaming client needs an internal domains list for the same reason; Cisco recommends populating it before the module ships to a single laptop.
2. Close the side doors on the firewall. Permit outbound 53 and 853 only from your resolvers. Block known DoH servers, then decide in browser management policy whether DoH is off or pinned to your resolver.
3. Deploy the roaming client to every laptop through your endpoint management tool. On Umbrella this is the Cisco Secure Client Umbrella module, supported on Windows 10, Windows 11 including ARM64, and macOS 11 and later. Do not install it on a server that itself serves DNS. Push the OrgInfo.json profile with it; without that file the module sits inert and the status tile in Secure Client shows no state at all.
4. Read the status states before you trust the rollout. Umbrella's documentation lists what the client reports: Encrypted, Protected, Open, Protected Network, Behind Virtual Appliance, and the VPN and trusted-network states where the module hands DNS back to the network. "Open" means the device could not reach the resolvers on UDP 53 or 443 and reverted to whatever DHCP gave it. Laptops in that state are not protected.
5. Turn on logging and look at it. Review blocked queries weekly by category and device. A workstation that tries a new nonsense-looking domain every few minutes is showing you a domain generation algorithm at work, and that machine needs EDR attention, not just a block.
6. Split the policy. The NSA/CISA sheet notes that one policy rarely fits a whole organization. Give guest Wi-Fi a stricter content policy than staff, and give servers a policy that allows little beyond updates and the SaaS endpoints they need.

When to get help

If your staff work from home offices and client sites and your only filtering lives in a firewall they are rarely behind, or if you have a DNS service licensed but no idea how many laptops are actually reporting "Protected," that is the conversation to have with us. Our managed DNS and web security service covers the design, the firewall rules that close the bypasses, the roaming client rollout, and the log review. The first step is a 30-minute intro call at padlocktech.com/#contact.