The server can resolve only approved names. Can it still connect to an unrelated database by address?
Those are different questions. A containment review needs answers to both.
DNS policy belongs in a microsegmentation design. It should not quietly become the whole design.
The Useful Shift In DNS Security
NIST published SP 800-81r3 in March 2026. Its guidance treats DNS as more than infrastructure plumbing: DNS can support Zero Trust policy enforcement and provide information for access decisions. The publication also addresses authoritative and recursive DNS security.
That is a useful direction. My implementation takeaway is narrower: connect DNS policy to the actual workload boundary, rather than treating a clean resolver log as proof that the boundary holds.
Start by distinguishing three controls:
- Resolver governance: which service may answer this workload’s DNS queries?
- Destination policy: which network destinations may this workload contact?
- Application authorization: which operations may its identity perform there?
These are proposed review categories, not interchangeable product features. Record the enforcement point for each one.
A Resolver Decision And A Connection Decision Are Different
Consider a proposed policy for an invoice-processing worker. It needs a queue, a document store and a telemetry collector. It does not need the database administration listener, even if that database has a perfectly legitimate internal DNS name.
My connection contract would explicitly allow the three application dependencies and deny unrelated workload and management access. Permission to resolve the database name would not change that contract.
The same distinction applies during quarantine. A response policy might preserve a designated resolver and evidence collector while denying ordinary application peers. It should not inherit every connection the worker could make before isolation merely because those destinations have approved names.
This is architectural reasoning, not a claim that protective DNS is ineffective. Name-based controls and workload relationship controls answer different questions. Use both where appropriate and test their intersection.
Do Not Confuse Protective DNS With DNS-Integrated Endpoint Enforcement
There is an important exception to simplistic statements about DNS filtering.
Microsoft’s Zero Trust DNS documentation describes Windows DNS client integration with Windows Filtering Platform. It blocks outbound IP traffic by default and permits destinations resolved through trusted protective DNS servers or explicitly configured exceptions. Its documented model includes temporary allow entries and both address families.
That is connection enforcement informed by DNS, not merely a resolver refusing to answer a query. Evaluate the installed mechanism, not the category label.
My remaining design question would be: does the resulting permission match the intended workload relationship? An approved destination address does not, by itself, express my proposed rule that the invoice worker may use an application API but not administer the host behind it. Check which additional controls enforce that distinction in your environment.
Close The Resolver Escape Route Deliberately
NSA’s encrypted DNS guidance recommends sending enterprise DNS traffic only to designated enterprise resolvers and disabling or blocking other resolvers. It also warns that browsers and other software can use encrypted DNS outside the enterprise’s traditional defenses.
For a segmentation rollout, I would turn that recommendation into an explicit dependency review:
- Identify the approved resolver endpoints for each environment.
- Define the required transport and fallback behavior.
- Configure applications and operating systems to use the approved path.
- Test attempted access to an unapproved resolver from a controlled workload.
- Review general web egress separately instead of declaring encrypted DNS blocked because a traditional DNS port is blocked.
The goal is not to break encrypted DNS. It is to make the selected resolver path enforceable without opening general outbound access as a troubleshooting shortcut.
A Small Acceptance Matrix
Use a controlled source and known healthy test services. The following is a proposed matrix, not a universal production rule set.
| Attempt from the invoice worker | Normal state | Quarantine state |
|---|---|---|
| Query designated resolver | Allow required resolution | Allow only if response design requires it |
| Query unapproved test resolver | Deny | Deny |
| Connect to approved queue listener | Allow | Deny unless explicitly required for response |
| Connect to unrelated database by address | Deny | Deny |
| Connect to management listener on an otherwise approved destination | Deny | Deny |
| Send evidence to designated collector | Allow if required | Allow narrowly |
For each result, capture the source workload identity, destination, protocol, policy revision and corresponding enforcement evidence. Confirm that a failed connection was blocked by the intended control, rather than by an unhealthy listener or failed lookup.
Repeat applicable cases with both a hostname and a controlled direct-address connection. Use a protocol-appropriate client: changing an HTTPS request to a bare IP can introduce certificate or virtual-host failures that say nothing about segmentation.
Also test the resolver outage state. Decide in advance whether the application should fail closed, use an approved secondary resolver or enter a documented degraded mode. Do not discover that decision during an incident.
Give The Exception An Owner
My rollout would start with one application and one short list of required connections. Each DNS or network exception would have an owner, a business reason and a review condition. Static address exceptions deserve the same scrutiny as name-based ones.
Then prove two things independently: the workload uses the approved resolution path, and it cannot make prohibited connections even when the destination address is already known.
A successful lookup is not an authorization decision for every service at that address. A blocked lookup is not proof that every route to the destination is closed.
Containment starts where that distinction becomes an enforced, tested boundary.
