Zero Trust DNS Starts Before the Connection

You can require authentication before connecting to an internal app and still reveal information about that app through DNS. Consider unauthorized endpoints that can resolve a protected service’s name. They may learn where that service resides before network access controls intervene. Blocking the connection helps, but the discovery has already happened.

CSA’s Integrating SDP and DNS describes Secure Multi-Step DoH. This architecture pattern applies identity-aware policy checks before name resolution. It extends the Software-Defined Perimeter (SDP) principle of “authenticate-before-connect” to “authenticate-before-resolve.” This helps restrict service discovery based on identity, device posture, and context.

Keep reading to learn:

• How Zero Trust DNS strengthens service concealment
• What happens during a policy-controlled lookup
• Which decisions determine whether that protection holds up

 

Why Does Encrypted DNS Still Need Authorization?

DNS translates domain names into IP addresses. In many enterprises, this process reveals info about internal services without first checking the requester's reason.

DNS over HTTPS (DoH) and DNS over TLS (DoT) protect DNS communications in transit. However, transport encryption alone is not enough. It does not establish whether you should allow a particular employee, workload, or device to resolve a protected name. Those decisions require an authorization layer.

For example, an encrypted request for an internal payroll hostname can protect the query from someone observing the network. Whether the requester should receive an answer is a separate question. Do not assume that a guest device and an authorized payroll administrator should receive the same service-discovery info.

Secure Multi-Step DoH repositions DNS as an identity-aware, pre-resolution enforcement point. The enterprise evaluates the requester. Then it allows mapping a protected hostname to an address.

The security benefit comes from combining encrypted transport with policy enforcement. Turning on DoH alone does not create this architecture.

 

What Does Authenticate-Before-Resolve Mean?

It means verifying identity and evaluating authorization policy before returning DNS info for a protected resource. In Secure Multi-Step DoH, the decision can incorporate device health, user role, workload identity, and risk signals.

The paper describes an Authorization Service that acts as a policy-enforcement gateway for DNS traffic. A Policy Engine evaluates the requested domain against enterprise access rules and contextual information.

A simplified lookup follows five steps:

1. Send the protected query: The client sends its DNS request over an encrypted connection to the enterprise Authorization Service. Certificate-based authentication, such as mutual TLS, can bind the connection to a verified client identity.
2. Evaluate identity and context: The Policy Engine uses enterprise IAM data and device posture information. This comes from Mobile Device Management (MDM), Endpoint Detection and Response (EDR), or other trusted sources.
3. Allow or deny discovery: If policy permits resolution, the service forwards the query to a trusted resolver. If authorization fails, it returns a policy-controlled denial or filtered response.
4. Return the permitted information: An authorized client receives an encrypted response. Depending on the architecture, this may identify an SDP gateway, another approved rendezvous point, or the application server itself.
5. Record the decision: The transaction produces audit info that identifies the evaluated identity, applied policy, authorization outcome, and reason for the decision.

 

How Does Zero Trust DNS Strengthen SDP Service Concealment?

SDP enforces authentication and authorization before setting up network connectivity. Secure Multi-Step DoH adds a complementary check earlier, during DNS-mediated service discovery.

The paper calls the combined effect “Dual Concealment.” You restrict service info at the DNS layer while protecting service reachability at the network layer.

Consider an illustrative request for payroll.internal.corp:

• An unauthorized contractor requests the name. DNS policy denies resolution because the identity lacks permission to discover the payroll service.
• An authorized employee uses a high-risk device. The device posture check denies or restricts resolution according to policy.
• An authorized employee uses a compliant device. DNS policy permits resolution. Where supported, it returns an SDP gateway address. The SDP system then evaluates whether to establish connectivity.

These controls reduce the info that an unauthorized requester can obtain through the enterprise DNS path. They also extend least privilege to service discovery. A user’s ability to request a hostname does not confer permission to resolve it.

Both layers should use consistent enterprise identity and posture sources. Otherwise, DNS may authorize discovery using stale info while the SDP controller applies a newer risk assessment.

 

Does Successful DNS Resolution Grant App Access?

No. Secure Multi-Step DoH governs service discovery and name resolution. It does not create, authorize, or maintain app sessions.

The paper separates three authorization tasks:

• Discovery: May this identity and device resolve the protected service’s name?
• Connectivity: May this requester establish a network connection through SDP, ZTNA, or another access mechanism?
• Application: What actions and resources may the requester access within the app?

Every connection does not require DNS. An attacker may already retain a previously resolved address or obtain service info through another channel. Denying a fresh DNS lookup cannot prevent direct IP connectivity by itself.

Downstream controls must continue to secure access independently. Similarly, a device that an attacker compromises after a successful lookup requires appropriate connectivity and session controls. A previous DNS authorization does not provide continuing permission.

Service concealment therefore reduces exposure through controlled discovery paths. Its effectiveness depends on the broader architecture protecting the service itself.

 

What Decisions Make the Protection Effective?

Adding policy checks to DNS creates dependencies that security and network teams must manage together. Four operational decisions are particularly important for preserving service concealment.

 

1. Prevent Alternate Resolution Paths

Clients must use the approved Authorization Service. If an endpoint can send protected queries to another resolver, it may bypass the enterprise’s discovery policy.

The paper recommends network and endpoint controls that:

• Direct DNS traffic to enterprise infrastructure
• Block unauthorized DNS and DoT paths
• Restrict DoH to approved resolvers

 

2. Define Behavior When You Don't Have Context

An IAM outage or missing posture signal should not silently expand discovery permissions. For protected namespaces, the paper recommends fail-closed behavior or a predefined restrictive baseline. This depends on the failure and policy.

Where permitted, support essential operations with:

• Bounded-lifetime cached authorization decisions, or
• Documented emergency procedures

Unknown, stale, or unverifiable context must not become a reason to grant access more broadly.

 

3. Make Caching Respect Identity and Policy Changes

Repeated synchronous calls to remote IAM and device-management services can increase resolution latency. The paper recommends reducing overhead with:

• Locally available or prefetched context
• Secure, identity-aware caching

However, cached decisions must respect validity periods and policy changes. A cached answer or authorization should not let a requester bypass a newly applied restriction. Teams should define when access conditions change. They should define how those changes invalidate or expire protected records and decisions.

 

4. Explain Denials Without Over-Collecting Data

A blocked lookup can look like an ordinary DNS failure to an app or user. Logs should help distinguish an identity problem, an unhealthy device, and an intentional policy denial. Correlating checks with a request ID supports troubleshooting across components.

Those records can also expose internal topology and user behavior. Restrict access, collect only necessary information, and set explicit retention periods. Teams need to design auditability and privacy together.

 

Where Can I Learn More?

Download Integrating SDP and DNS: Enhanced Zero Trust Policy Enforcement 2.0 for more detail. The full paper covers:

• Failure conditions
• Deployment tradeoffs
• Privacy
• Integration with SDP and other Zero Trust principles
• DNS capability comparisons and reference projects
• And more!