Abstract

The Domain Name System (DNS) is a foundational Internet service and a persistent security blind spot in enterprise environments. The original DNS concept relied solely on network access (local network presence) to establish trust, but the industry is moving aggressively to adopt encrypted DNS (DNS over HTTPS, and DNS over TLS).

DNS over HTTPS (DoH) and DNS over TLS (DoT) improve the confidentiality of DNS queries; but they do not provide the identity awareness, policy enforcement, auditability, or service concealment required by modern Zero Trust Architectures (ZTA). This paper shifts some of the focal points of the original Integrating SDP and DNS Zero Trust paper towards a more advanced policy-enforced architectural pattern. This new architectural pattern applies modern Zero Trust and Software-Defined Perimeter (SDP) principles to DNS over HTTPS/TLS, and repositions DNS as an identity-aware policy decision-making and enforcement point for service discovery prior to name resolution. By integrating DNS resolution with certificate-based authentication; enterprise Identity and Access Management (IAM): and context-based access decisions, and by enforcing authorization decisions before resolution and (where architecture supports it) returning gateway or rendezvous information for authorized clients, identity-first overlay fabrics, and other Zero Trust enforcement layers; this approach enables fine-grained control, improved visibility, and stronger alignment with authenticate-before-connect and service-hiding requirements.

The paper examines architecture, threat models, failure modes, privacy implications, and standards alignment, and clarifies that Secure Multi-Step DoH functions strictly as a pre-resolution Zero Trust control around hostname-to-IP address mapping. It governs service discovery and name resolution but does not establish, authorize, or maintain application sessions. It complements but does not replace, downstream access and session enforcement mechanisms such as SDP, NHP, ZTNA, identity-first overlays (i.e., OpenZiti), and SASE/SSE architectures.

This advanced architectural pattern is particularly valuable for organizations that are further along in their Zero Trust maturity journey, and a great next step once core Zero Trust principles, such as limiting traffic in general, are already established. It offers substantial benefits, especially for enterprises managing a highly mobile or globally distributed workforce, ensuring consistent and secure policy enforcement regardless of the client’s physical location.

Figure 1: Layered Zero Trust DNS Architecture

Target Audience

Primary:
Business System and Process Owners, CISOs, Security Architects, Security Engineers, Network Administrators, Cloud Security Engineers.

Secondary:
Compliance Officers, Risk Managers, Security Analysts, IT Decision-Makers, Application Developers (with a security integration focus), IoT/Industrial Internet of Things (IIoT) Security Specialists, DevSecOps Engineers, OT/Industrial Control Systems (ICS) Security Engineers and Developers, and Data Scientists (involved in security analytics or network monitoring).

Key Points

• DNS remains a high-value attack surface despite encryption: Even when DNS traffic is encrypted using DNS over HTTPS (DoH) or DNS over TLS (DoT), the DNS resolution process continues to expose critical information about enterprise applications, internal services, and user behavior. Attackers routinely exploit DNS for reconnaissance, command-and-control, and data exfiltration because name resolution typically occurs before other security controls are engaged.

• Pure DoH/DoT is insufficient for Zero Trust enterprises: While DoH and DoT protect DNS traffic confidentiality in transit, they are identity-agnostic and policy-unaware. On their own they do not enforce least privilege, differentiate between trusted and untrusted devices, or prevent unauthorized discovery of internal resources, leaving key Zero Trust requirements unmet.

• Secure Multi-Step DoH enforces policy before resolution: Secure Multi-Step DoH introduces explicit authorization steps into the DNS resolution flow to ensure that identity, device posture, and policy decisions are evaluated before an IP address is returned. This prevents unauthorized or high-risk endpoints from discovering network resources in the first place.

• Identity, device posture, and risk signals are first-class DNS inputs: The DNS authorization layer evaluates signals from IAM, MDM/EDR, and threat intelligence systems before resolution occurs. This enables context-aware enforcement at the earliest stage of access. Downstream technologies (including SDP, NHP, and ZTNA) perform their own independent validation using similar signals, creating defense-in-depth without requiring DNS to share posture data.

• DNS becomes a preventive Zero Trust control, not just telemetry: Secure DNS enforces access policies at the DNS layer. Secure Multi-Step DoH shifts DNS from a passive logging-and-detection posture to a preventive control. This reduces attack surface, limits lateral movement, and stops many malicious activities before network or application connections are attempted.

• This approach integrates with SDP, NHP, and SASE/SSE: DNS authorization is agnostic to the downstream enforcement approach. Organizations can deploy SDP, NHP, identity-first overlays, or traditional ZTNA based on their requirements. Secure Multi-Step DoH enforces identity- and access-aware authorization before resolution, providing consistent pre-resolution control regardless of the authenticate-before-connect model in use.

• The approach enables global workforces to securely access internal resources by routing DNS queries through a centralized, identity-aware Authorization Service, regardless of the client’s physical location. Secure Multi-Step DoH ensures that remote workers, traveling personnel, and on-premises staff operate under consistent security policies and receive authenticated, policy-driven name resolution. This enables organizations to apply a uniform service discovery policy across the enterprise, independent of network location. Where the architecture supports it, the Authorization Service may also return gateway or rendezvous information to authorized clients; in other architectures, it provides only an allow/deny decision for DNS resolution. Network connectivity and application sessions remain the responsibility of downstream enforcement mechanisms such as SDP, NHP, ZTNA, identity-first overlays, or other Zero Trust connectivity solutions, which may eliminate the need for traditional VPNs.

• Protection Against Advanced DNS-Layer Attacks: The identity-aware DNS layer actively defends against sophisticated DNS-specific threats. By analyzing the context of the query alongside threat intelligence the system can block DNS tunneling, domain generation algorithms (DGAs) used by malware, and DNS rebinding attacks.

Scope

This paper focuses on enterprise DNS resolution and policy enforcement within Zero Trust environments. It covers architectural patterns, security controls, operational considerations, and integration with existing Zero Trust components, including Software-Defined Perimeter (SDP), Network-infrastructure Hiding Protocols (NHP), identity-first overlay fabrics, SASE/SSE, and ZTNA authenticate-before-connect workflows. The paper examines how Secure Multi-Step DoH serves as a pre-resolution enforcement layer that complements SDP’s pre-connection enforcement, supporting service concealment and identity-aware access.

Within a layered Zero Trust architecture, Secure Multi-Step DoH operates at the DNS discovery layer, making authorization decisions before name resolution occurs. Downstream access and session establishment are governed by SDP, NHP, ZTNA, or an overlay fabric that independently validates access and enforces authenticate-before-connect principles. Application-layer authorization remains responsible for fine-grained entitlement and resource-level access decisions within the service itself. Together, these layers provide complementary security controls while preserving separation of responsibilities between service discovery, network connectivity, and application authorization.

This paper does not propose replacement of application-layer authorization or prescribe a vendor-specific implementation. It also does not attempt to redesign SDP or ZTNA; instead it describes how DNS-layer controls with modifications to general DNS server designs align with and reinforce these architectures.

Introduction

Traditional Domain Name System (DNS) protocols, despite their critical role as the “phonebook of the Internet” (translating domain names into IP addresses), pose a significant security vulnerability in modern enterprise networks.

The CSA’s original guidance on Integrating SDP and DNS focused on limited security uplifts for existing DNS architectures, such as traditional domain-based filtering and basic logging. However, this approach was inherently limited by the legacy DNS protocol’s lack of identity and policy awareness.

This updated guidance marks a major architectural shift. It moves beyond simply patching an outdated protocol, by fully integrating DNS resolution with Zero Trust principles. Specifically, the Secure Multi-Step DoH model re-architects DNS as an identity-aware, pre-resolution enforcement point. This design is engineered to fundamentally complement modern frameworks like Software-Defined Perimeter (SDP) and Network-infrastructure Hiding Protocol (NHP).

Figure 2: Traditional Plaintext DNS

Standard DNS queries are typically sent in plaintext over UDP or TCP port 53, making them susceptible to eavesdropping, Man-In-The-Middle (MITM) attacks, and DNS hijacking. This exposure enables adversaries to easily:

• Fingerprint internal networks: Observe queries to identify internal services and user activities.
• Launch phishing attacks: Redirect users to malicious sites through DNS spoofing.

The seemingly benign nature of traditional DNS makes it an attractive target for sophisticated cyberattacks. These attacks exploit the protocol’s inherent plaintext exposure and lack of built-in authentication, often resulting in large-scale security incidents and headline-making data breaches.

A common attack vector is DNS cache poisoning/spoofing, where attackers inject false information into a DNS resolver’s cache, redirecting unsuspecting users to malicious websites, often for phishing or malware distribution. The consequences can be devastating, as demonstrated by numerous high-profile campaigns in which attackers successfully redirected traffic intended for banks, social media platforms, or government sites. Furthermore, Distributed Denial of Service (DDoS) attacks leveraging DNS amplification have become a persistent threat, crippling major Internet infrastructure by bouncing massive volumes of traffic off open DNS resolvers.

Figure 3: Common DNS Attack Vectors (Spoofing and DDoS)

DNS over HTTPS (DoH) and DNS over TLS (DoT) were introduced to address some of the security concerns of traditional DNS by providing point-to-point encryption. However, while the adoption of these methods has improved privacy and interception of DNS requests, these solutions alone are insufficient for a Zero Trust enterprise because they often introduce new challenges:

1. Loss of Visibility: Encrypting queries can blind internal security teams to potential threats and policy violations.

2. Centralization Risk: Relying on a single external DoH provider (i.e., a large tech company) introduces a single point of failure and potential privacy concerns.

3. Inflexible Policy: The standard DoH/DoT lacks the multi-layered controls and identity awareness required to enforce granular Zero Trust policies across users and devices.

Figure 4: Pure Encrypted DNS (DoH/DoT)

While DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt DNS queries, a critical vulnerability remains: DNS Tunneling for Command-and-Control (C2) communication and data exfiltration.

Attackers leverage the highly used ports — port 443 (standard HTTPS) for DoH and port 853 for DoT — to establish covert, persistent communication channels with compromised systems or exfiltrate data secretly.

Traditional perimeter security, including firewalls and deep packet inspection, often fails to decrypt and inspect this traffic. This enables high-frequency malicious DNS queries — carrying C2 instructions or stolen data — to bypass defenses. The frequency with which this sophisticated, stealthy compromise is uncovered in post-mortem breach reports, often months after the initial compromise, highlights the severity of the issue and enterprise blindness to it.

Furthermore, these protocols still allow every user to run any query for any zone, including internal and sensitive ones. This universal access makes it easy for internal threat actors to fingerprint environments.

These real-world security failures demonstrate the urgent need to move beyond passive DNS monitoring. Secure Multi-Step DoH’s pre-resolution policy enforcement provides the necessary active security layer, ensuring communication with known malicious or suspicious domains is blocked before DNS communication can be established.

Figure 5: DNS Tunneling for Command and Control (C2)

Zero Trust architectures enforce the principle of authenticate-before-connect across multiple layers. Software-Defined Perimeter (SDP), Network-infrastructure Hiding Protocol (NHP), and ZTNA solutions enforce policy before network or application connections are established. However, these controls operate after name resolution has already occurred. Unauthorized entities can still confirm the existence of the service before downstream access controls deny connectivity.

Figure 6: DNS Tunneling and Pre-Resolution Policy Enforcement

Secure Multi-Step DoH closes this gap by applying identity-aware policy enforcement. Before DNS resolution, Secure Multi-Step DoH integrates DNS resolution with enterprise Identity and Access Management (IAM), device posture evaluation, and context-based policy decisions. This approach prevents unauthorized service discovery, while maintaining layered access control. This DNS policy enforcement complements, rather than replaces, network segmentation and application authorization controls.

Figure 7: Multi-Step Authorization and Policy Enforcement

Key Requirements for Enterprise-Grade Secure DNS

A truly secure, Zero Trust-aligned DNS infrastructure must go beyond simple encryption. It must incorporate multi-step authentication and policy enforcement to centrally manage and audit resolution requests.

1. End-to-End Encryption and Integrity

• Requirement: All DNS traffic must be encrypted using modern protocols such as DoH or DoT to prevent eavesdropping and MITM attacks.

• Enhancement: Employ authenticated encryption (e.g., ChaCha20-Poly1305 or AES-GCM) and cryptographic signatures to ensure that queries and responses are not tampered with in transit.

2. Multi-Step Policy Enforcement

• Requirement: The DNS resolution process must incorporate intermediate steps for policy validation before the final query is resolved. Weighting should be available for businesses to make dynamic and stackable decisions, not simply a “fail/pass” option.

• Enhancement:

  • Identity-Aware Filtering: Integrate with enterprise Identity and Access Management (IAM) systems to apply filtering policies based on authenticated user, agent, or device identity. Identity integration may be certificate- or key-based (i.e., mutual TLS), federated (i.e., OIDC/SPIFFE-based claims), lifecycle-managed (i.e., SCIM-based provisioning), or a hybrid model. Support for dynamic, claim-driven attributes (e.g., group membership, role, risk score, and conditional access context) enables granular and continuously updated DNS policy enforcement, aligned with enterprise identity lifecycle processes. The effectiveness of identity-aware DNS enforcement depends on the maturity of the underlying IAM integration, including native federation support and automated identity lifecycle synchronization. Enterprises should also account for latency, synchronization delays, and stale or unavailable identity attributes, as outdated or missing IAM data can lead to inconsistent DNS policy decisions or unintended authorization outcomes.

  • Device Posture Check: Use context from Mobile Device Management (MDM), Endpoint Detection and Response (EDR), or similar security platforms to evaluate device trust before DNS resolution. Posture signals must be consumed by the DNS Policy Engine so resolution decisions reflect current device risk (e.g., unpatched, non-compliant, or compromised endpoints). Where posture enforcement also occurs at downstream gateways (e.g., SDP, NHP, or ZTNA), DNS-layer posture evaluation should remain consistent with those controls to ensure coherent, layered policy enforcement. Posture context may also be bound to identity attributes or dynamic claims within the enterprise IAM system to ensure alignment between DNS resolution policy and broader access-control decisions. Devices that are unknown, unregistered, or whose posture cannot be determined, should be treated as untrusted by default, with the Policy Engine restricting or denying resolution for protected namespaces rather than permitting access, in the absence of a verifiable posture signal. These identities and posture checks don’t need to directly come from the source, but can be from a trusted agent. One example is an agent, container, etc. which uses SPIFFE/SPIRE paired with data collected from a hypervisor to provide a full picture, even if the agent or container itself doesn’t provide it.

  • Geographic/Threat Intelligence Check: The DNS Policy Engine must intercept and block resolution requests for known malicious domains or domains in high-risk geographies before forwarding queries to external resolvers.

  • Pinned TLS/Mutual TLS: Require clients to present a valid client certificate (Mutual TLS) and/or to validate the Authorization Service’s certificate using Certificate Pinning. This binds the DNS connection to a verified device/identity beyond simple transport encryption, strongly enforcing ZT’s “Verify Explicitly” principle.

  • Behavioral Anomalies: In addition to static factors, the Policy Engine can analyze behavioral anomalies, such as unusual query volumes, impossible travel (i.e., queries originating from two distant locations within a too-narrow timeframe), and access outside typical working hours, to trigger more restrictive policies. Detection thresholds should be calibrated to organizational baselines periodically to prevent false positives from disrupting legitimate activity. Behavioral anomalies should increase risk weighting rather than independently trigger denial. Real-time risk indicators such as anomalous identity behavior, unexpected patterns in service discovery, privilege escalation, and unusual automation workflows should be considered by organizations when making DNS authorization decisions to support Zero Trust enforcement based on operational risk rather than static policies.

• DNS Resolution speed: Performance can be improved by implementing secure, identity-aware caching mechanisms at the edge or within the Authorization Service to reduce the need for real-time IAM/MDM lookups on every single query, while respecting TTLs and policy changes. However, care should be taken to ensure this doesn’t add additional attack surface or enable policy check bypasses. Additionally, the cache should be easily dumpable by administrators or security practitioners when an upstream DNS poisoning attack is detected.

3. Centralized Auditability and Logging

• Requirement: Decrypt and inspect DNS traffic in a policy-controlled, secure manner for auditing, threat detection, and compliance.

• Enhancement: All resolution attempts (successes and failures) must be logged centrally, including the associated Identity, Device Posture, and Policy Decisions. This visibility restores the security team’s ability to detect anomalous behavior, such as a sudden increase in queries to a specific TLD, or requests for internal resources from external networks. Because these logs contain identity-linked information organizations should restrict access, minimize collected data, define retention periods, and comply with applicable privacy regulations.

• Modern Log Formats: DNS Authorization logs should leverage modern, high-efficiency formats (i.e., JSON) and align with web server access log standards. Consistency makes the data more easily ingestible and processable by Security Information and Event Management (SIEM) systems and data analytics platforms, while reducing the resource footprint and storage overhead historically associated with verbose DNS logging. At enterprise scale, DNS log volumes can be substantial; enterprises should implement log filtering, sampling strategies, and tiered retention policies to manage storage and processing costs without sacrificing forensic completeness for high-risk or denied resolution events. Because DNS logs at this level of fidelity include identity-linked data they carry significant privacy implications and must be governed using strict access controls, retention limits, and data minimization policies consistent with applicable regulations.

4. Private DNS Resolution

• Requirement: Enterprises often need to resolve private domain names (i.e., *.internal.corp) that are not visible to the public internet.

• Enhancement: A Secure Multi-Step DoH solution must intelligently route private-domain queries to an internal DNS server only after the client and device have been authenticated, ensuring that the internal network infrastructure remains completely hidden from external view (a core tenet of network-hiding protocols like NHP).

5. Global Accessibility

• Requirement: Enterprise employees often travel or work from outside of office spaces, but still need access to secure DNS.

• Enhancement: A Secure Multi-Step DoH solution must remain reachable to authorized clients outside the controlled enterprise network, including when connecting from the public Internet, and must enforce the same identity- and policy-based resolution decisions regardless of client type. The architecture should leverage publicly accessible HTTPS protections while maintaining centralized authorization.

**6. Resiliency, High Availability, and DDoS Protection

• Requirement: DNS is part of the critical path for all network traffic, so the Authorization Service must be highly available.

• Enhancement: Support global Anycast routing, multi-region failover, and active-active redundancy. Protect the Authorization Service with enterprise DDoS mitigation controls because centralized DNS infrastructure is a primary target for volumetric and state-exhaustion attacks. Restrict administrative access to authorized personnel. Require formal approval for policy changes. Continuously monitor for policy-engine compromise. Regularly test disaster recovery procedures. Protect audit logs from unauthorized modification using tamper-evident mechanisms where appropriate. Rotate cryptographic keys and certificates according to enterprise lifecycle policies.

Controls and Standards Alignment

Secure Multi-Step DoH applies established Zero Trust and access-control principles at the DNS resolution layer. The following tables illustrate how the architecture aligns with selected controls and principles from widely recognized security frameworks.

NIST SP 800-81r3: Secure DNS Deployment Guide

NIST SP 800-207: Zero Trust Architecture

Mapping Secure Multi-Step DoH Components to NIST SP 800-207 Logical Components

CISA Zero Trust Maturity Model

CSA Software-Defined Perimeter (SDP) / ZTNA Principles

NIST SP 800-53 Rev. 5

CSA AI Controls Matrix (AICM)

These mappings illustrate how Secure Multi-Step DoH extends identity-aware policy enforcement to the DNS resolution phase, complementing downstream access controls such as SDP, NHP, ZTNA, and identity-first overlays rather than replacing them.

Compliance Considerations

Secure Multi-Step DoH introduces identity-aware enforcement and centralized decision logging at the DNS resolution layer. These capabilities strengthen governance posture and require appropriate operational oversight.

Access Governance and Least Privilege

Secure Multi-Step DoH enforces identity and posture-based decisions before authorizing name resolution. DNS authorization policies, therefore, function as access-control logic for service discovery and namespace exposure, and must follow enterprise access-governance processes. Role-based controls, documented policy definitions, and periodic review cycles should apply to DNS-layer enforcement rules. The rules and engine should allow for easy labeling or metadata to show whom and how the approval of each rule and access was made to make governance easier.

Auditability and Evidence Generation

All DNS resolution attempts, both approved and denied, can be centrally logged, along with the associated identity, device posture, requested domain, and policy outcome. These records provide verifiable evidence of least privilege enforcement, support incident investigations, and demonstrate consistent policy application during audits or assessments. At minimum audit records should identify the policy applied, the identity evaluated, the authorization decision, and the reason for that decision. Because these logs contain identity-linked and domain-level data, they are sensitive data assets in their own right. Access must be restricted to authorized security and compliance personnel, with controls in place to prevent unauthorized viewing, export, or modification. Exposure of DNS audit logs to unauthorized parties could reveal user behavior patterns, internal service topology, and identity attributes, creating risks that extend beyond the DNS layer.

Logging Governance

DNS authorization logs should be governed under documented retention and access-control policies to ensure integrity, controlled administrative access, and audit readiness. Oversight of DNS audit data should be restricted to authorized security and compliance personnel, with monitoring and review processes aligned to enterprise governance standards. Retention periods should be explicitly defined and enforced to balance forensic and compliance requirements against storage costs and privacy obligations; with shorter retention applied to low-risk resolution events and longer retention reserved for denied, anomalous, or policy-significant events. Enterprise-scale DNS logs can place significant pressure on storage and processing infrastructure; governance policies should therefore include provisions for log aggregation, tiered storage, and capacity planning to ensure the logging pipeline remains reliable under peak loads. An advantage is that these are HTTP-access-style logs, so they can leverage mature HTTP logging solutions.

Operational Change Management

Because DNS authorization decisions influence access to protected services, DNS-layer policy rules should be subject to formal change management procedures. This includes documented policy updates, controlled testing before deployment, defined approval workflows, and segregation of duties between policy authors and operational administrators. Policy misconfigurations at the DNS layer carry elevated risk because an incorrect rule can silently block legitimate resolution or inadvertently expose protected namespaces- errors that may not be immediately visible, but can affect a broad population of users and services. Change procedures should include mandatory pre-deployment validation in a staging environment and defined rollback strategies that allow rapid reversion to a known, good policy state without requiring a full redeployment cycle.

Policy governance does not end after deployment. Organizations should periodically review DNS authorization policies. Reviews should confirm policy ownership, remove stale or unused rules, and retire temporary exceptions that are no longer required. Review emergency policy changes after implementation. Periodically compare policy definitions with observed DNS resolution activity to identify unintended access or unnecessary restrictions.

Separation of Enforcement Layers

Secure Multi-Step DoH governs only service discovery because connectivity doesn’t require DNS, such as direct IP connectivity is unaffected. Session establishment, connectivity enforcement, and continuous authorization remain the responsibility of downstream mechanisms such as SDP, NHP, ZTNA, or SASE/SSE. Maintaining this separation preserves architectural clarity and ensures governance controls remain aligned with their respective enforcement layers.

Privacy Considerations

The enhanced visibility provided by Secure Multi-Step DoH, while critical for security and auditability, necessitates careful consideration of user privacy. Centralized logging of all DNS resolution attempts, including the associated user identity and device context, generates sensitive data that must be managed in accordance with organizational policy and legal frameworks (e.g., GDPR, HIPAA). Enterprises should implement a strict data minimization policy, retaining logs only as long as necessary for security and compliance purposes.

Crucially, the scope of DNS monitoring should be carefully defined:

• Minimizing PII Exposure: While logging user identity is essential for Zero Trust enforcement on enterprise-managed assets, resolution data for highly sensitive, protected domains, such as those related to government services, healthcare providers, or financial institutions, should, where policy allows, be excluded from detailed logging — or at least filtered to avoid accidental PII data logging — to preserve user and customer privacy, to mitigate risk exposure per local laws and company privacy standards.

• Device Ownership: The policy should explicitly state that Zero Trust enforcement and monitoring apply only to employee-owned devices where no expectation of privacy exists, and corporate-owned, managed devices. Resolution attempts originating from non-corporate or unmanaged devices should be blocked, routed to a non-logging public resolver, or placed in “Privacy-Preserving” mode, which enforces a baseline security policy without logging the query’s identity or domain. Policy should define explicitly what data is always logged, such as timestamp, authorization outcome, and policy rule applied, and what is conditionally excluded, such as resolved domain names and identity attributes, depending on device ownership status or domain sensitivity classification. Privacy-Preserving mode is triggered by the absence of a valid enterprise device certificate, an unrecognized posture signal, or classification of the request as originating from an unmanaged endpoint; in this mode only the minimum operational data necessary to enforce baseline security controls is retained.

• Legal Compliance: All logging and data retention practices must be regularly reviewed to ensure ongoing compliance with local regulations, such as retaining logs within specific data residency zones and providing mechanisms for subject access requests. The objective is to support security monitoring while limiting unnecessary collection and retention of sensitive data.

Implementing Secure Multi-Step DoH with an Authorization Service

Client Bootstrap

In scenarios where clients connect to novel or untrusted network environments, such as public Wi-Fi, certain networks may intercept DNS queries to redirect users to captive portals before granting broader Internet access. Detection of such redirection is significantly complicated by the lack of standardized implementation methods. One potential mitigation strategy is to enable users to preconfigure a “hotspot network” status, which facilitates a temporary redirect until a secure connection to the authorization server is established.

Successful initiation of a connection, and subsequent policy evaluation with the Authorization Service, require a reliable mechanism for clients to discover and securely connect to the Multi-Step DoH DNS server. This bootstrap mechanism is security-sensitive because it must circumvent local network poisoning attempts. Two primary methodologies facilitate this secure communication.

• Public DNS with DNSSEC/TXT Validation: The client may be configured dynamically or in advance to query the address of the Multi-Step DoH service. Examples through normal DNS would be looking up something such as a TXT record against a DNS service, or a local configuration file to use a public DNS resolver to query the address of the Multi-Step DoH service, validating the response’s integrity via DNSSEC and verifying a predetermined TXT record. This method depends on external DNS availability during the initial bootstrap phase; if external DNS is unavailable or compromised, clients should fall back to static bootstrap IPs to ensure the Authorization Service remains reachable.

• Static Bootstrap IP(s): A static, pre-configured list of trusted bootstrap IP addresses for the Multi-Step DoH Authorization Service may be embedded directly within the client software package.

Furthermore, to safeguard the Authorization Service connection against local DNS or traffic manipulation, the client must implement Intermediate Certificate Authority (CA) Certificate Pinning. This ensures that the server-side certificate of the Authorization Service is validated against a known pinned credential within the client software, establishing a robust cryptographic binding to prevent man-in-the-middle attacks, even if traffic is redirected to a malicious destination. Compromise of a pinned trust anchor represents a high-impact failure condition; enterprises should maintain a limited set of explicitly trusted credentials, and have defined procedures for trust anchor revocation and reissuance. Certificate Authority updates and key rotation must be coordinated with client update cycles, maintaining a transition window that supports both outgoing and incoming credentials simultaneously to prevent service disruption during rotation.

Client and Server Interaction

A practical implementation of Secure Multi-Step DoH involves integrating an Authorization Service — analogous to an NHP Server — that serves as a policy-enforcement gateway for all DNS traffic.

Secure Multi-Step DoH Client and Authorization Service Interaction Flow

In architectures that also deploy a Software-Defined Perimeter (SDP), completing Step 6 does not grant access to applications. Rather, successful DNS resolution returns the address of an SDP gateway or controller, after which SDP independently evaluates session establishment and connectivity authorization. Secure Multi-Step DoH therefore governs discovery, while SDP governs session creation and network access. The two operate sequentially but remain architecturally distinct.

By enforcing policy checks before resolution, Secure Multi-Step DoH ensures that an unauthorized or high-risk device cannot even discover the IP address of a protected resource or malicious site. This approach transforms DNS from a pervasive vulnerability into an active, identity-aware component of the Zero Trust security fabric.

Integration with and Concepts Taken from SDP

The Secure Multi-Step DoH architecture is fundamentally designed to align with and reinforce the principles of Software-Defined Perimeter (SDP). SDP, a key Zero Trust Network Access (ZTNA) model, operates on the principles of Authenticate-Before-Connect and Service Concealment. Secure Multi-Step DoH extends these core concepts to the very first step of network communication: name resolution.

Figure 8: DNS Tunneling and Pre-Resolution Policy Enforcement

Reinforcing Core SDP Principles

The integration provides layered enforcement across discovery and connectivity.

• Authenticate-Before-Resolve (Secure Multi-Step DoH): Secure Multi-Step DoH ensures that an authenticated identity and a policy-compliant device posture are verified before a protected resource’s name is resolved to an IP address. This pre-resolution, identity-first policy check precedes the network session attempt.

• Authenticate-Before-Connect (SDP): Once DNS resolution succeeds (often returning the IP address of an SDP Gateway rather than the application server), the SDP mechanism takes over. The client must then independently authenticate, and the SDP Controller must re-verify the context and policy before establishing a network connection (the session establishment layer).

Service Concealment

The most significant concept borrowed from and enhanced by SDP is Service Concealment (or “Network Hiding”).

FIGURE I: Comparison of Service Concealment Approaches (SDP vs. Secure Multi-Step DoH)

By governing the DNS resolution phase, Secure Multi-Step DoH prevents an unauthorized entity — internal or external — from even discovering the IP address of a protected resource. This pre-discovery control strengthens SDP’s network-level concealment, moving the overall architecture closer to a complete “Default-Deny” state.

Context-Based Access (CBA) Alignment

SDP relies on Context-Based Access (CBA) to define policy, evaluating factors like user role, device posture, location, and time of day. Secure Multi-Step DoH integrates with the same enterprise Identity and Access Management (IAM) and security platforms (MDM/EDR) to fetch this crucial context. This ensures policy consistency: the policy decision made at the DNS layer (allow/deny resolution) is informed by the same data sources that dictate the policy decision at the SDP layer (allow/deny connection). This unified context management prevents policy gaps and ensures that the Zero Trust enforcement is coherent across the discovery and connectivity phases.

Integration with Network-infrastructure Hiding Protocols (NHP)

The defensive power of Secure Multi-Step DoH is significantly enhanced when integrated with technologies such as Network-infrastructure Hiding Protocols (NHP). NHP, by design, enforces cryptographic pre-authentication at the network layer, making internal enterprise services completely unreachable and invisible from the public Internet, masking them from reconnaissance and direct attack attempts. An example of an open source implementation aligned with this approach is the OpenNHP Stealth DNS project (see Appendix 1, Reference Projects), which illustrates how DNS-layer authorization can be combined with NHP-based infrastructure hiding, in which domain names, IP addresses, and service ports are not exposed or discoverable until authorization succeeds.

When combined with Secure Multi-Step DoH, this creates complementary DNS- and network-layer controls:

• Pre-Resolution Concealment: Secure Multi-Step DoH ensures that even if an attacker attempts to resolve a domain name (i.e., payroll.internal.corp), the query is first subject to policy enforcement based on identity and device posture. Unauthorized devices or users receive a null response, preventing them from ever acquiring an internal IP address.

• Post-Resolution Barrier: For authorized users, successful resolution reveals only the NHP gateway address, not the internal service’s actual IP. This ensures that even after a successful DNS lookup, the endpoint must still pass the NHP Server’s continuous authentication and authorization checks to establish a session, preventing lateral movement or direct endpoint compromise.

• Total Endpoint Protection: By restricting resolution of internal names and requiring continuous verification for access the combination of Secure Multi-Step DoH and NHP provides comprehensive protection against insider threats, credential theft, and sophisticated external attackers seeking to map and exploit internal infrastructure. This moves the enterprise further toward the true “Default-Deny” posture required by ZTA.

Integration with SASE/SSE Architectures

The principles underlying Secure Multi-Step DoH- identity-aware policy enforcement at the network edge- make it a natural and essential component of modern Secure Access Service Edge (SASE) and Security Service Edge (SSE) frameworks. SASE/SSE models seek to consolidate networking and security functions into a unified, cloud-delivered service.

Integrated into either framework, Secure Multi-Step DoH acts as a foundational control plane for a SASE/SSE platform.

• Unified Policy Enforcement: The policy decisions enforced by the Multi-Step DoH Authorization Service (e.g., Identity-Aware Filtering and Device Posture Check) are synchronized with broader SASE/SSE policies. This ensures a consistent security posture across all user access points, when accessing a SaaS application, a public cloud resource, or an internal enterprise application.

• Enhanced Zero Trust Network Access (ZTNA): Within SASE/SSE, the DoH layer provides the initial, highly granular pre-access policy check. By controlling DNS resolution, the system prevents unauthorized devices from even initiating a connection to a cloud or internal resource protected by the SASE/SSE fabric, minimizing attack-surface exposure from the outset.

• Comprehensive Threat Protection: By intercepting and analyzing all DNS queries, the Secure Multi-Step DoH architecture feeds crucial threat intelligence directly into the SASE/SSE platform’s Secure Web Gateway (SWG) and Cloud Access Security Broker (CASB) functions.

• Simplified Operational Visibility: The centralized logging and auditability inherent in Secure Multi-Step DoH are integrated into the central SASE/SSE management console. Security teams gain full visibility into all DNS activity with policy context, streamlining compliance reporting and accelerating incident response by correlating access attempts against policy outcomes.

Applicability Beyond SDP, NHP, and SASE/SSE Frameworks

While Secure Multi-Step DoH achieves its full defensive potential when integrated with advanced architectures such as Software-Defined Perimeter (SDP), Network-infrastructure Hiding Protocols (NHP), and SASE/SSE frameworks, the core methodology remains valuable and implementable on its own. Enterprises do not need a full SDP deployment, SASE migration, or NHP implementation to realize significant security benefits.

Even in environments that do not deploy a full SDP architecture, Secure Multi-Step DoH independently enforces identity-aware resolution before connection attempts occur. While SDP governs session establishment and network connectivity, Secure Multi-Step DoH strengthens any architecture by preventing unauthorized discovery of protected resources before attempting connectivity.

The fundamental value proposition of Secure Multi-Step DoH, transforming DNS from a plaintext vulnerability into an encrypted, policy-aware access control mechanism, is universally applicable:

• For Legacy Environments: Organizations operating with traditional network perimeters and non-cloud-native security stacks can still deploy the Authorization Service and Policy Engine as a standalone gateway. This provides immediate, granular control over all outbound DNS traffic, restoring visibility and enabling identity-aware filtering without overhauling the entire network architecture.

• Decoupled Policy Enforcement: The multi-step process effectively decouples the security decision (allow/deny resolution) from the network transport layer. The Policy Engine’s reliance on IAM and MDM data (as detailed in Context-Based Access) means the solution remains effective even for enterprises using legacy VPNs or a mix of on-premises and cloud resources, provided the contextual data sources are available.

• Incremental Zero Trust Adoption: Secure Multi-Step DoH can serve as an initial, incremental deployment model for Zero Trust. By making DNS resolution dependent on identity and device posture, the enterprise establishes a foundational “verify first” control point that can be easily expanded later to cover application access (ZTNA) or web access (SWG/CASB) when budget or architectural readiness permits.

Threats and Mitigations

The integration of Zero Trust principles into DNS resolution adds identity-aware enforcement capabilities. The following table outlines major DNS-related threats and details how the Secure Multi-Step DoH architecture specifically mitigates them, often transcending the capabilities of traditional or purely encrypted DNS solutions.

Threat Matrix Mitigation

Why Secure Multi-Step DoH Transcends Pure Encrypted DNS

While the shift from plaintext DNS to encrypted protocols like DoH and DoT is a necessary first step, relying solely on them for enterprise security provides a false sense of security. Pure DoH/DoT fails to meet Zero Trust requirements for three primary reasons:

1. Security Blind Spot: Simple encryption, particularly DoH over port 443, cloaks DNS queries from legacy security appliances. This “traffic obfuscation” prevents traditional firewalls, Intrusion Detection Systems, and even some Secure Web Gateways from performing necessary inspection and policy enforcement, creating a critical blind spot for Command-and-Control (C2) communication and data exfiltration via tunneling.

2. Lack of Identity/Context: Standard DoH/DoT provides session-level encryption but is entirely identity-agnostic and policy-unaware. It cannot differentiate between a patched, authorized corporate laptop and a compromised, unmanaged device. It cannot enforce least-privilege access based on user role (i.e., Finance vs. Guest). Secure Multi-Step DoH explicitly addresses this by integrating Context-Based Access (CBA) into the resolution process.

3. Inflexibility and Centralization Risk: Pure encrypted DNS often forces reliance on external, third-party resolvers, ceding control over crucial policy and logging functions. Secure Multi-Step DoH maintains internal control via the Authorization Service, enabling granular, multi-step policy enforcement, private DNS resolution, and centralized auditability, all essential for compliance and robust incident response.

Transition and Backward Compatibility

A key advantage of deploying Secure Multi-Step DoH through an internal Authorization Service/Gateway is the flexibility it offers during phased migration. The system is designed for backward compatibility and incremental adoption:

• Coexistence with Traditional DNS: The Authorization Service can be configured to accept not only DoH/DoT from newly provisioned clients but also traditional plaintext DNS queries (UDP/TCP 53) from legacy systems or non-upgradable devices via a client-local loop or within secure internal enterprise networks. The gateway immediately upgrades basic DNS to encrypted dns and applies the same multi-step policy check to these plaintext queries before resolution, providing an instant security uplift across the entire network perimeter. In cases where DNS is received over the network rather than by a native multi-step dns client, IP-based authentication can serve as a fallback during migration.

• Gradual Client Rollout: Enterprises can deploy the client-side DoH configuration to user groups incrementally. While migration is underway the Policy Engine ensures that all DNS traffic, regardless of protocol (DoH, DoT, or legacy DNS), is consistently governed, thereby avoiding the security gaps typical to mixed environments.

• Minimal Network Disruption: The solution operates as an overlay. By leveraging existing IAM and MDM infrastructure for contextual data, it avoids the need for large-scale infrastructure replacement of core networking hardware and makes the security enhancement an immediate, low-friction investment. This provides a smoother path to Zero Trust compliance without sacrificing the functionality of existing applications reliant on traditional DNS resolution.

• Migration Considerations: The introduction of an Authorization Service into the DNS resolution path adds processing overhead that should be baselined and monitored during rollout, particularly in environments with high query volumes or latency-sensitive applications. During the transition period, policy inconsistencies may arise where some clients operate under full Multi-Step DoH enforcement while others remain on legacy DNS paths; these gaps should be tracked explicitly and resolved incrementally rather than accepted as a permanent mixed state. Legacy systems that cannot be updated to support DoH or mTLS may require long-term IP-based authentication fallbacks, and their limitations should be documented as known exceptions within the enterprise risk register until migration is complete.

Secure Multi-Step DoH is an architectural pattern that can be layered onto existing infrastructure, providing a critical, high-impact security upgrade independent of broader network transformation initiatives.

Failure and Mitigations

In traditional DNS deployments, failures are treated primarily as availability problems to be mitigated through redundancy and failover. In Zero Trust architectures, DNS failures must also be evaluated as potential security events that could enable policy bypass, unauthorized discovery, or audit gaps.

Secure Multi-Step DNS over HTTPS intentionally changes how DNS behaves under failure conditions. Unlike traditional DNS or basic encrypted DNS protocols, failures are treated as both availability and security events. Secure Multi-Step DoH enforces explicit security guarantees when identity, policy, or contextual dependencies cannot be satisfied. These guarantees ensure that DNS does not silently downgrade to weaker resolution mechanisms or expose protected services under degraded conditions.

Failure Condition Mitigation Matrix

DNS Security Capabilities Comparison

The Domain Name System plays a foundational role in enterprise networking, yet its security properties vary significantly depending on how DNS resolution is implemented. To understand these differences, it is necessary to examine both the security capabilities available at the DNS layer and how those capabilities contribute to Zero Trust objectives.

Figure L compares security capabilities across different DNS resolution models, from traditional plaintext DNS through encrypted DNS protocols such as DNS over HTTPS (DoH) and DNS over TLS (DoT), and finally to Secure Multi-Step DNS over HTTPS. The comparison shows that DoH and DoT improve confidentiality in transit but do not provide identity awareness, policy enforcement, auditability, or service concealment. Secure Multi-Step DoH extends DNS beyond transport security by integrating identity, device posture, contextual policy evaluation, and centralized logging into the resolution process.

DNS Model Architecture Security Matrix

Security capabilities alone, however, do not fully explain how DNS participates in a Zero Trust Architecture. Zero Trust requires explicit verification, least-privilege enforcement, continuous evaluation, and assume-breach operation across all control points, including DNS.

Figure O examines how the same DNS resolution models align with core Zero Trust principles, highlighting the extent to which each approach supports explicit verification, limits unauthorized discovery, enables continuous policy enforcement, and provides audit visibility. Together, the two tables show not only how DNS security capabilities evolve, but also how DNS can transition from a passive infrastructure dependency into an active Zero Trust enforcement point.

DNS Architecture Zero Trust Mapping

While Figure M illustrates general alignment patterns, downstream Zero Trust access technologies vary significantly in their native support for device posture evaluation, service-level segmentation, and identity-based service abstraction. For example, some Network Hiding Protocol (NHP) implementations rely on external posture integration and gateway-based segmentation, whereas full ZTNA platforms or identity-first overlay fabrics (e.g., OpenZiti and NetFoundry) may incorporate posture-aware clients and identity-native service routing. Secure Multi-Step DoH complements these models at the DNS discovery layer but does not standardize or replace their downstream enforcement capabilities.

Benefits

1. Security & Zero Trust Enforcement

• Stronger Zero Trust enforcement through identity, device, and context aware DNS decisions prior to resolution

• Service concealment that keeps internal resources undiscoverable unless the client is explicitly authorized

• Reduced attack surface by preventing DNS-based reconnaissance and limiting lateral movement

• Early threat prevention by blocking DNS tunneling, Command-and-Control (C2), Domain Generation Algorithms (DGA), and phishing domains before network connections are established

• Deterministic fail-closed behavior prevents downgrade or policy bypass under failure conditions

2. Operational & Architectural Advantages

• Operational simplification by decoupling access policy from network topology, IP addressing, and transport-layer constraints

• Incremental Zero Trust adoption without requiring a full network redesign or forklift infrastructure replacement

• Enables measurable Zero Trust maturity improvements before broader ZTNA, SDP, or network transformation initiatives are complete

• Seamless integration with SDP and NHP architectures, extending authenticate-before-connect principle to the DNS discovery layer, and ensuring services are neither resolvable nor reachable without authorization

• Backward compatibility with legacy DNS clients while maintaining centralized policy enforcement

3. Governance, Compliance, & Visibility

• Consistent global access control for on-premises, remote, and roaming users without reliance on traditional VPN-based perimeter models

• Enhanced auditability through centralized, identity-bound DNS logging and policy decision recording

• Improved compliance posture by aligning DNS enforcement with regulatory expectations for access control, logging, and data protection (e.g., PCI DSS, HIPAA, GDPR)

• Policy transparency and traceability for forensic analysis and incident response

Challenges, Limitations, and Tradeoffs

While Secure Multi-Step DoH offers significant security advantages and full Zero Trust alignment, its increased complexity and reliance on additional components introduce several operational and architectural challenges that enterprises must consider.

Performance and Latency

The introduction of multiple policy checks and an intermediary Authorization Service adds steps to the DNS resolution process, potentially increasing latency compared to a single-step, non-contextual DNS lookup.

Performance Impact Mitigation

Operational Complexity and Maintenance

The shift from managing simple, often static, DNS servers to a dynamic, identity-aware authorization service increases the required skill set for operations and engineering.

Operational Complexity Mitigation

Ecosystem Limitations and Tradeoffs

Integrating a non-standard DNS approach into an existing security and networking ecosystem carries specific limitations.

Ecosystem Limitation and Tradeoffs Matrix

Conclusion and Future Outlook

Conclusion

The Secure Multi-Step DNS over HTTPS architecture introduces a significant extension to Zero Trust enforcement at the DNS layer, transforming the Domain Name System from a critical security blind spot into an identity-aware, pre-resolution control point. By integrating certificate-based client authentication, enterprise Identity and Access Management (IAM), and continuous device posture checks, directly into the DNS resolution flow, this model successfully enforces the Zero Trust principles of Verify Explicitly and Assume Breach at the earliest possible stage: service discovery. This capability is crucial, as it prevents unauthorized users and non-compliant devices from resolving internal resource names, effectively closing off a high-value reconnaissance vector and reinforcing the core tenet of service concealment required by modern frameworks such as SDP and NHP. While pure encrypted DNS (DoH/DoT) only addresses transport confidentiality, Secure Multi-Step DoH provides the essential layer of pre-access authorization and centralized, identity-bound auditability that is foundational for robust compliance and forensic analysis in a global, perimeter-less enterprise. Its complementary role within downstream enforcement layers (such as ZTNA and SASE/SSE) creates a cohesive, defense-in-depth security fabric in which DNS policy governs discovery and the access layer governs session establishment, providing a comprehensive and resilient path toward full Zero Trust maturity.

Future Outlook

Protocol Evolution and OS Integration

The Secure Multi-Step DoH architecture demonstrates a critical shift: transforming traditionally unauthenticated, plaintext foundational services (like DNS) into identity-aware, policy-enforced control points. This architectural pattern is not exclusive to DNS; it provides a model for applying Zero Trust controls to other foundational network protocols.

Securing Foundational Network Protocols

The success of encrypted DNS (DoH/DoT) will inevitably lead to the standardization and adoption of similar authentication and encryption overlays for other ubiquitous, yet vulnerable, network protocols. Given that Zero Trust requires verification of all communication, securing these foundational services, currently the first vectors of network reconnaissance, is paramount.

The increasing usage of Agentic AI platforms raises novel problems related to service discovery. Autonomous agents conduct more and more DNS lookups, API discovery, and service enumeration in an unsupervised way. Zero Trust environments of tomorrow will need to provide identity-based policies for service discovery conducted by Non-Human Identities (NHI) and further abstractions away from traditional human-centric models.

Foundational Network Protocol ZT Migration

Further details are provided in Appendix F.

This systemic OS change will fundamentally align endpoints and Operating Systems with the Zero Trust “Verify Explicitly” principle, from the moment they attempt to discover the network or synchronize their clocks, ensuring that unmanaged or compromised devices cannot participate in even basic network functions.

Glossary of Terms

Zero Trust Glossary References:

• CSA Glossary (primary resource)
• On2IT ZT Glossary - Zero Trust Dictionary (John Kindervag)
• CSA SDP Glossary (Software Defined Perimeter)

Useful References

• Cloud Security Alliance (CSA), SDP Architecture Guide v3, May 2026
• Cloud Security Alliance (CSA), Stealth Mode SDP for Zero Trust Network Infrastructure: Introducing the Network-Infrastructure Hiding Protocol (NHP), February 2026
• Cloud Security Alliance (CSA), Integrating SDP and DNS: Enhanced Zero Trust Policy Enforcement, April 2022
• Cloud Security Alliance (CSA), Software-Defined Perimeter (SDP) Specification v2.0, March 2022
• Cloud Security Alliance (CSA), Software-Defined Perimeter as a DDoS Prevention Mechanism, October 2019
• NIST SP 800-207, Zero Trust Architecture, August 2020
• NIST SP 1800-35 (4th Preliminary Draft) Implementing a Zero Trust Architecture, Date Published: July 31, 2024, Comments Due: September 30, 2024
• NIST SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide, March 2026
• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape, November 2022
• Department of Defense (DoD), Zero Trust Reference Architecture, Version 2.0, July 2022
• Open source Zero Trust Networking & SDP with OpenZiti
• OpenNHP. Github. Open Source NHP Implementation, 2026
• Go Development, DNS-over-HTTPS, Version 1.4.2, Accessed February, 2026
• Google Public DNS, DNS-over-HTTPS (DoH), Accessed February, 2026

DNS Standards and Protocol References

• IETF, RFC 8310 – Usage Profiles for DNS over TLS and DNS over DTLS, March 2018.
• IETF, RFC 8484 – DNS Queries over HTTPS (DoH), October 2018
• IETF, RFC 7858 – Specification for DNS over Transport Layer Security (TLS), May 2016
• IETF, RFC 8310 – Usage Profiles for DNS over TLS and DNS over DTLS, March 2018
• IETF, RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3, August 2018
• IETF, RFC 4033 – DNS Security Introduction and Requirements, March 2005/ Replaced by RFC 9364
• IETF, RFC 4034 – Resource Records for the DNS Security Extensions (DNSSEC), March 2005/ Replaced by RFC 9364
• IETF, RFC 4035 – Protocol Modifications for the DNS Security Extensions (DNSSEC), March 2005/ Replaced by RFC 9364
• IETF, RFC 9156 – DNS Query Name Minimization to Improve Privacy, November 2021
• IETF, RFC 9364 - DNS Security Extensions (DNSSEC), February 2023

Appendix: Deep Dive into Core Technologies

This appendix provides a more technical examination of the core security technologies and concepts discussed in the context of Secure Multi-Step DoH and Zero Trust.

A. Encrypted DNS Protocols: DoH vs. DoT

While both DNS over HTTPS (DoH) and DNS over TLS (DoT) provide the critical function of encrypting DNS traffic, their implementation and enterprise suitability differ.

Mechanism

DNS over HTTPS (DoH)

DoH encapsulates DNS queries within the familiar HTTPS protocol (HTTP/2 or HTTP/3), typically over TCP port 443.

• Pros: It leverages the same port as standard web traffic, making it extremely difficult for traditional firewalls to differentiate and block, a feature often favored by privacy advocates but challenging for enterprise visibility. It benefits from the ubiquity of HTTP/S infrastructure.

• Cons: Using port 443 for multiple traffic types (web browsing, API calls, and DNS) causes traffic obfuscation and directly contributes to the “Loss of Visibility” challenge mentioned earlier, unless dedicated, policy-aware decryption points are implemented.

DNS over TLS (DoT)

DoT wraps DNS queries directly within a TLS tunnel, typically using the dedicated TCP port 853.

• Pros: Using a dedicated port makes it easier for internal security devices to identify, inspect, and enforce policies specifically on DNS traffic, while still maintaining end-to-end encryption.

• Cons: Since it uses a non-standard port, it can be easier for motivated internal users to detect and block, or for external networks to filter.

B. Context-Based Access (CBA)

Context-Based Access is a foundational principle of Zero Trust that moves beyond simple static credentials. It requires continuous, dynamic evaluation of numerous factors before authorizing a connection or DNS resolution.

Context-Based Access for ZT DNS

Secure Multi-Step DoH leverages CBA by injecting these contextual factors into the Policy Engine (Step 3 in the implementation table) before deciding whether to forward or deny the DNS request.

C. Network Hiding Protocols (NHP)

Network Hiding Protocols (NHP) are architectural patterns aligned with Zero Trust and Software-Defined Perimeter (SDP) principles that eliminate direct network reachability to protected services. Rather than exposing internal resources to routable IP addresses protected by firewalls, NHP ensures that services are functionally unreachable and undetectable until identity and policy validation are complete. NHP primarily operates at the session layer, using cryptographic validation and control-plane authorization to gate connectivity and conceal protected endpoints. While it reflects Authenticate-Before-Connect design principles common to SDP and ZTNA models, NHP focuses specifically on session-level concealment and endpoint hiding, rather than providing a complete access architecture. Broader SDP/ZTNA platforms additionally include service abstraction, policy-driven routing, posture-aware clients, and large-scale multi-service segmentation.
Mechanism

• An authenticated session client or lightweight tunnel agent focused on cryptographic session establishment and endpoint concealment.
• A centralized authorization or gateway component
• Policy-driven session establishment following successful identity validation.

Protected resources do not expose public IP addresses or open ports. Instead, authorized clients establish connectivity only after control-plane validation, preventing unsolicited inbound access and network reconnaissance. These session clients are primarily responsible for authenticated connection gating and concealment. While they may share architectural similarities with ZTNA clients, they do not inherently provide the full posture-aware, identity-federated, or service-aware policy capabilities commonly found in broader SDP/ZTNA platforms.

Relationship to Secure Multi-Step DoH

Secure Multi-Step DoH complements NHP by extending concealment and policy enforcement to the DNS layer:

• Pre-resolution concealment: Unauthorized entities cannot resolve protected internal domain names.

• Post-resolution isolation: Authorized resolution reveals only the NHP gateway address, not the internal resource’s actual IP.

• Layered enforcement: DNS-layer policy validation (Secure Multi-Step DoH) precedes connectivity-layer authorization (NHP), creating defense-in-depth across discovery and access phases.

Together, Secure Multi-Step DoH and NHP ensure that protected services are neither discoverable via DNS nor reachable via the network without prior identity validation and policy authorization. Secure Multi-Step DoH governs service discovery at the resolution layer, while NHP enforces authenticated session establishment and endpoint concealment at the connectivity layer. Ongoing or continuous posture and context re-evaluation, where implemented, typically depends on integration with external IAM, MDM, or EDR systems, and varies by implementation. Broader SDP/ZTNA platforms incorporate more extensive continuous identity federation and posture-aware policy evaluation within their client and control-plane architectures.

For more on NHP, see Stealth Mode SDP for Zero Trust Network Infrastructure: Introducing the Network-Infrastructure Hiding Protocol (NHP)

D. Identity-First Overlay Fabrics: OpenZiti

OpenZiti is an open-source, SDP-aligned identity-first overlay implementation that illustrates a different, but complementary, relationship between DNS, service discovery, and Zero Trust connectivity. Rather than treating a resolved IP address as the primary object of access control, OpenZiti defines named services as policy objects and uses cryptographic identities and service policies to determine which identities may provide (“Bind”) or consume (“Dial”) those services. Connectivity is established across the overlay only after identity and policy authorization. OpenZiti service policies explicitly associate identities with the services they are permitted to Dial or Bind.

For applications that rely on conventional hostname resolution, OpenZiti tunneling clients can provide a local DNS resolver for authorized Ziti services and intercept traffic addressed to configured service names. The DNS name therefore acts as an application-compatible service identifier rather than exposing the protected service’s actual network location. Intercept policies can similarly identify services using IP addresses, CIDRs, or wildcard names. This allows existing applications to access identity-authorized services without requiring the destination itself to be directly reachable from the initiating endpoint through the underlying network.

Relationship to Secure Multi-Step DoH

• Identity-defined reachability: With an identity-first overlay, authorization applies directly to the relationship between an authenticated identity and a named service. An unauthorized identity is not given an authorized service path, irrespective of its knowledge of underlying network addresses.

• DNS as a service abstraction: Where DNS-based interception is used, local resolution is derived from services already authorized to the identity. Conventional DNS resolution of the protected endpoint is therefore not required as the security boundary.

• Complementary enforcement: Secure Multi-Step DoH remains useful for conventional DNS-mediated discovery, including Internet, SaaS, legacy, and other resources outside the overlay. It can complement an identity-first overlay but is not a prerequisite for protecting services whose reachability is already controlled by the overlay.

• Service concealment: Protected services do not need to expose directly reachable addresses or unsolicited inbound paths to consuming identities. Authorization determines whether a service path exists before connectivity is established.

This illustrates two complementary Zero Trust patterns. Secure Multi-Step DoH applies identity and policy to discovery before resolution, followed by downstream connectivity enforcement. Identity-first overlays such as OpenZiti can instead abstract the protected service from its network locator and apply identity and policy directly to service reachability. The approaches may coexist within the same enterprise architecture depending on whether a resource remains dependent on conventional DNS-mediated connectivity.

Figure 9: OpenZiti applied to multistep DoH

E. Software-Defined Perimeter (SDP)

Software-Defined Perimeter (SDP) is an architectural framework that enforces authenticate-before-connect access, identity-centric authorization, and least-privilege network connectivity. Unlike traditional perimeter-based models that expose services on routable networks and rely on firewalls for restriction, SDP inverts the model: resources are not reachable until identity and policy validation are completed.

Mechanism

An SDP architecture typically separates:

• Control Plane: Responsible for identity verification, device validation, policy evaluation, and authorization decisions.

• Data Plane: Responsible for enforcing connectivity only after control-plane authorization succeeds.

In an SDP system, initiating entities request access to a protected resource, but cannot reach their target until the controller authorizes the request. This prevents reconnaissance, port scanning, and lateral movement by ensuring that protected resources are not discoverable before authentication.

Relationship to Secure Multi-Step DoH

Secure Multi-Step DoH aligns closely with SDP principles, and can be understood as extending SDP enforcement to the DNS resolution layer.

• Authenticate-before-resolution: Just as SDP requires authentication before connectivity, Secure Multi-Step DoH requires identity and policy validation before name resolution.

• Policy-based enforcement: DNS decisions are made by a policy engine analogous to an SDP controller.

• Reduced attack surface: Unauthorized entities cannot resolve protected internal namespaces, preventing DNS-based reconnaissance.

When deployed together, Secure Multi-Step DoH strengthens SDP by ensuring that protected resources are unreachable — not only at the network layer, but also at the DNS layer. This extends the hidden infrastructure model central to SDP design.
For more on SDP, see SDP Architecture Guide v3, May 2026

F. Reference Projects

To illustrate the concepts of Secure Multi-Step DoH and Context-Based Access (CBA), and the role of an Authorization Service, a proof-of-concept reference implementation has been created.

The project, available on GitHub, provides a functional example of:

• A lightweight DoH/DoT server proxy that intercepts DNS queries.
• Integration points for simulating IAM and MDM checks to determine device posture and identity.
• A Policy Engine that enforces multi-step access rules (i.e., deny resolution if the device posture is “high-risk”).

This reference project is available at penguintechinc/squawk, and serves as a valuable starting point for architects and engineers looking to test and implement this Zero Trust DNS model.

In addition, open source projects are beginning to demonstrate how DNS-layer authorization can be integrated with the principles of the Network Infrastructure Hiding Protocol (NHP). The OpenNHP Stealth DNS project provides a reference example of this approach, combining Secure Multi-Step DoH-style policy enforcement with NHP-based service concealment. In this model DNS resolution decisions are tied to identity and policy evaluation, while network infrastructure elements — including domain names, IP addresses, and service ports — remain undiscoverable until authorization succeeds. The project supports multiple platforms, including Windows, Linux, macOS, iOS, and Android, illustrating its applicability across diverse enterprise environments. This demonstrates how DNS-layer controls and network-layer hiding can operate together within a layered Zero Trust architecture.

G. Further discussion on Network Protocol Security

Network Time Migration

Major operating systems (OS) are beginning to set the stage for making encrypted foundational protocols the default, aligning with a global push for enhanced privacy and security.

• NTP/PTP Over HTTPS/TLS as OS Default: The ongoing push for comprehensive network security extends beyond data transport and name resolution, increasingly focusing on the integrity of foundational protocols. Similar to the critical shift toward encrypted DNS via protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH), a parallel security transformation is anticipated for time synchronization. Operating system developers and hardware manufacturers are expected to rapidly adopt Network Time Security (NTS) or comparable secure time-synchronization protocols. NTS is an IETF standard that provides cryptographic security for the Network Time Protocol (NTP) and, by extension, the Precision Time Protocol (PTP), the established methods for clock synchronization across computer networks. This transition involves wrapping the traditional time protocols (NTP/PTP) in Transport Layer Security (TLS) or HTTPS, similar to what we describe for DNS.

Techniques like NTS are needed to secure all core networking protocols.

• Mitigating a Neglected Attack Vector: NTP, in its legacy form, is vulnerable to Man-In-The-Middle (MITM) and other spoofing attacks. An attacker can easily feed incorrect time information to a client system with devastating security consequences. NTS secures this vital but frequently neglected attack vector by ensuring that time data is authentic and untampered.

• Crucial for Digital Certificates: Accurate and verifiable time is the bedrock of Public Key Infrastructure (PKI). Digital certificates rely on correct time to validate effective dates and determine revocation status via mechanisms such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). If a system’s clock is maliciously altered, the system can be tricked into accepting expired or revoked certificates, completely undermining the trust model.

• Ensuring Logging and Forensics Integrity: Security Information and Event Management (SIEM) systems and forensic analysis depend entirely on synchronized, tamper-proof timestamps across all network devices. If an attacker can manipulate a server’s clock they can obscure their tracks, invalidate audit logs, or make it impossible to correlate security events.

• Enforcing Security Policies: Time is often a criterion for enforcing granular security policies, such as time-based access control (i.e., allowing access only during business hours) and validity periods for temporary credentials. Inaccurate time can lead to policy bypasses.

Organizational Imperatives and Deployment Strategy

Given the inevitability of this industry-wide shift, organizations must adopt a proactive stance. Organizations should proactively deploy and validate NTS-capable time servers with enhanced logging.

Steps for Proactive Deployment.

1. Server Upgrade and Validation: Upgrade existing or invest in new infrastructure to support NTS-enabled time servers (e.g., specialized hardware clocks or software running the latest NTP daemon versions, which include NTS support). Validation is key: test the NTS handshake and ensure that the cryptographic verification process works correctly between servers and a test client.

2. Network and Firewall Configuration: Adjust firewall rules to allow the necessary secure connections (e.g., port 4460 for NTS over TCP; the protocol can operate on other ports).

3. Enhanced Logging Implementation: The new NTS infrastructure must integrate with centralized logging solutions. Enhanced logging should capture cryptographic handshake details, successful and failed authentication attempts, and any time discrepancies or synchronization issues, to provide a robust audit trail.

4. Client-Side Readiness: Begin updating operating system images and software to versions that natively support NTS clients. This ensures that the entire device fleet benefits from the new layer of security.

5. Deeper Architectural Integration: The policy model established by Secure Multi-Step DoH (where identity and device posture drive policy decisions for basic services) will be integrated directly into core OS networking stacks. Future OS builds will likely:

   1. Natively support policy enforcement: Mandatory authentication and authorization for services like DNS and NTP will be enforced at a low-level, non-bypassable layer.

   2. Integrate posture signals: The OS will automatically feed real-time device health (patch level, malware status) into the policy engine (like the one used in Secure Multi-Step DoH) before authorizing any foundational network request.

Dynamic Host Configuration Protocol (DHCP)

The successful transformation of DNS into an identity-aware control point via Secure Multi-Step DoH sets a precedent for securing other foundational network protocols, notably DHCP. As Zero Trust principles permeate infrastructure, relying on unauthenticated protocols for core services poses unacceptable risk. DHCP (Dynamic Host Configuration Protocol), which is responsible for automatically assigning IP addresses and configuring networks, currently lacks inherent authentication and is highly susceptible to rogue-server attacks, spoofing, and unauthorized network mapping.

The logical next step in this evolution is migration to authenticated, encrypted DHCP alternatives, such as DHCP over TLS/HTTPS (DHCPS). This model leverages the same principles applied to DoH.

• Mutual TLS (mTLS) Authentication: The client device must present a valid, enterprise-issued certificate to the DHCPS server, and the server must present a valid certificate in return. This ensures that only trusted devices receive network configuration, and prevents rogue DHCP servers from operating.

• Identity Binding: The DHCP request can be explicitly bound to a machine or user identity (similar to the DNS authorization step), ensuring that network configuration is granted only according to defined policy (i.e., a high-risk device receives a segregated VLAN configuration).

• Encryption: All configuration exchange is encrypted, preventing eavesdropping on network parameters including DNS server addresses.

Some forward-leaning organizations have already developed proprietary or custom DHCP alternatives that utilize HTTPS and machine TLS authentication to secure data centers and offices. This pattern — moving critical infrastructure configuration away from plaintext, unauthenticated protocols to identity-bound, encrypted alternatives — should under strategic migration plans for all foundational services.

DHCP ZT Migration

Full Zero Trust maturity requires Operating System (OS) and core network services to natively support authenticated, encrypted protocols. Just as modern OSes now support native DoH/DoT configuration, future OS versions must incorporate native DHCPS client capabilities. This shift will ensure network access is granted only after identity and policy have been verified, closing the final unauthenticated gaps in the Zero Trust network fabric.