Block domains at DNS — infrastructure defense in depth

I rarely start domain blocking with “which zone wizard?”

I start with:

• What’s the purpose?
• What still works when the endpoint agent misses?
• Where do domain-joined clients already resolve names?
• What should fail before a TCP session even starts?

Endpoint security matters. It is not the whole system. If a name you do not want still resolves to a real IP, the client already has a usable path. For traffic that uses internal DNS, I want that path to die at resolution.

Context

The easy path

Rely on the agent alone — “it will catch it.”

Why that is not enough

• Workstations already point at Active Directory DNS.
• Agents miss cases. That is normal operations, not a surprise.
• A live DNS answer means the connection can start.
• A block that lives on only one domain controller is fragile.

How I look at the system

Without a sinkhole:

client asks for a bad name
        →  DNS returns a real IP
        →  TCP can start
        →  the agent may or may not stop it

So I treat DNS as another place the path can fail early — not as a replacement for the agent.

What I proposed

An AD DNS sinkhole: apex and wildcard to 0.0.0.0, replicated, dynamic updates off.

query:  bad.example / *.bad.example
answer: 0.0.0.0

What makes it a real control

• Block at AD DNS — clients already trust it; no new resolver to invent.
• Apex and wildcard both to 0.0.0.0 — the base name and subdomains fail the same way.
• Dynamic updates off — the blocklist should not rewrite itself quietly.
• Replicate across domain controllers — one DC down should not remove the control.

Why not “only buy a better agent”?

Keep the agent. Add the sinkhole. Defense in depth here means a second early fail, not another product pitch.

Limits I stay honest about

A sinkhole is useful. It is not complete.

• Public DNS, some VPNs, and DNS over HTTPS can bypass local answers — that needs policy elsewhere.
• Local cache can delay the change — verify after ipconfig /flushdns.
• A huge custom blocklist empire is usually overkill — start with names you actually need to stop.
• DNS alone does not “secure the company” — it is one early fail in a wider stack.

The bar: for clients on internal DNS, deny a usable answer, document what still bypasses you, keep endpoint tools.

What “done” means

Not “the zone exists.”

From a domain-joined client still using internal DNS:

ipconfig /flushdns
nslookup example.com
nslookup anything.example.com

Both return 0.0.0.0, and the browser fails to connect.

That is the outcome I care about: no usable path at resolution, with clear eyes on the edges.