What a DNS Layer Actually Stops Before It Reaches Your Team

Almost every attack that reaches a small company arrives through a chain of steps. Someone gets a message. They click a link. Their device looks up a domain name. A connection opens. A page loads. Something is typed, or downloaded, or run.

That chain matters because defences do not all sit in the same place. Endpoint antivirus watches what happens on the machine. Email filtering watches what arrives in the inbox. A DNS layer sits at exactly one step: the name lookup, third in the list above, before any connection exists.

Understanding that position is the whole story. It explains what a filtering resolver catches, why it catches it so cheaply, and why it will never be enough on its own.

The step everyone forgets

Domain names do not go anywhere by themselves. Before a browser can load example.com, something has to turn that name into a numeric address. That something is a resolver, and by default it is whatever your internet provider hands out.

The lookup takes a few milliseconds and nobody thinks about it. But it is a chokepoint, and chokepoints are where filtering gets cheap. At that instant, three things are true at once:

• The device has told you exactly which domain it wants.
• No connection has been opened yet.
• Nothing has been downloaded, rendered or executed.

A resolver that is willing to answer "I have no address for that" ends the chain right there. There is no page to render, no certificate to trust, no form to fill in. The attack does not fail at the last step; it fails before the first one.

Compare that with catching the same thing later. Endpoint software has to let the file arrive, then decide whether it is malicious. A browser warning has to let the page load, then hope the user reads the warning rather than clicking through it. Blocking at the lookup avoids both problems by never getting there.

What this actually catches in a normal week

For a small team, the realistic wins are unglamorous:

Phishing pages. The link in the email points at a domain registered days ago that imitates a login screen. If that domain is on a phishing list, the page never loads and there is nothing to type a password into. This is the single most common thing a small business gets hit by, and it is the thing a name lookup handles best.

Malware calling home. Most malware is useless until it can reach its operator to fetch instructions or send stolen data. That contact almost always starts with a lookup of a command-and-control domain. Blocking it does not remove the malware, but it does turn an active compromise into an inert file, which buys you the time to find it.

Drive-by ad and tracker infrastructure. A large share of the third-party requests on a normal web page never needed to happen. Removing them at the lookup makes pages lighter and removes a category of ad-delivered malware in passing.

A category you have simply decided is not for work devices. Gambling on a shared kiosk machine, adult content on a device in a reception area. This is a policy decision rather than a security one, and DNS is a reasonable place to put it because it applies to every device pointed at the resolver without touching any of them.

What it does not catch, stated plainly

This is the part most vendor pages skip, and it is the part that decides whether you deploy the other layers you still need.

Connections to raw IP addresses. No name, no lookup, no filter. Sophisticated malware sometimes hardcodes addresses precisely to avoid this layer.

Anything already running on the machine. If a laptop is compromised, DNS filtering can cut its outbound contact but cannot clean it, cannot see what it is doing locally, and cannot stop it encrypting files on that machine.

File contents. A resolver sees a domain. It does not see the attachment that arrived from a perfectly reputable file-sharing service.

A new domain nobody has classified yet. Lists are built from observed behaviour, so there is always a window between a domain appearing and it being categorised. Filtering narrows the window; it does not close it.

A determined person on a device you do not manage. They can change the DNS setting back. On a managed device you can prevent this; on someone's personal phone you are relying on agreement, not enforcement.

Everything a resolver is not. Backups, multi-factor authentication, patching, and a half-hour conversation with staff about what a real phishing email looks like. None of these become optional because the name lookups are filtered. If anything, the risk of a first layer is that it makes the missing layers feel less urgent.

Why the position in the chain makes it cheap

There is a practical argument for starting here that has nothing to do with how much it catches.

Because filtering happens at the resolver rather than on the device, there is nothing to install on each machine. You point devices at a filtering resolver, once per profile, using an encrypted DNS setting, a configuration profile on iOS, a QR code on Android, or a single router change for a whole office network. There is no agent to deploy, patch, or troubleshoot when it conflicts with something else. There is also no native mobile app in the picture, which means one fewer thing to keep updated.

For a company where "IT" is one person who is good with computers and already has a full job, that difference is not cosmetic. It is the difference between a change you can make on a Tuesday afternoon and a project that never quite starts.

It also composes well with what you may already have. Apple and Google both ship device-management and screen-time features that work alongside a filtering resolver rather than against it. They solve different parts of the problem: the platform tools manage the device, the resolver manages what the device can reach. Using both is normal and sensible.

How to think about the layers together

A workable mental model for a team of ten to two hundred people:

1. Email filtering catches most malicious messages before anyone sees them.
2. DNS filtering catches a large share of what gets clicked anyway, before a connection opens.
3. Endpoint protection catches what reaches the machine.
4. Multi-factor authentication limits the damage when credentials leak anyway, which they eventually will.
5. Backups are what you actually rely on when all four of the above have failed at once.

DNS filtering is layer two. It is broad, cheap and fast, and its job is to shrink the amount of work layers three, four and five have to do. A company that has layer two and nothing else has a thin defence. A company that has layers one, three, four and five and skips two is doing more work than it needs to.

A realistic way to start

Point a handful of devices at one profile and leave it for a week. Watch what gets blocked. Most teams are surprised by the volume of tracker and ad-infrastructure lookups, and occasionally find something genuinely alarming that had been quietly happening for months.

That week costs you an afternoon of setup and gives you a real picture of your own traffic rather than a vendor's description of it. If the picture is boring, that is useful information too.

If you want to try it, you can create an account on the free tier, or read the setup guide first to see exactly what pointing a device involves.

Related reading

• DNS Filtering for Business: Block Malware, Phishing, and Distractions Without an Agent
• What a DNS Log Actually Contains, and Why It Matters
• DoH vs DoT vs Classic DNS