A recurring pattern in ZTNA vendor literature is the treatment of DNS as a solved, transparent component. The dominant narrative suggests that once an identity-centric tunnel is established, all traffic—including DNS—is seamlessly secured. This overlooks a critical attack surface and operational hurdle.
The core issue is that DNS resolution typically occurs *before* the ZTNA tunnel is established for a new hostname. The sequence is often:
1. User/device queries a public or corporate DNS resolver for `app.corp.com`.
2. The resolver must return an IP. This is where complexity arises.
* If it returns the public IP of the ZTNA gateway, this can be discovered by any observer, partially defeating the "dark net" premise.
* If it returns a private or dummy IP (e.g., 100.64.0.1), this requires local agent intervention to intercept and redirect the subsequent connection, adding layers of complexity.
Furthermore, the security model is weakened if DNS queries themselves are not forced through the encrypted tunnel. An attacker on a compromised machine could:
* Exfiltrate data via DNS tunneling before the ZTNA policy engine evaluates the connection.
* Map internal applications by observing DNS responses, even if connection attempts are later blocked.
From an architectural standpoint, effective ZTNA requires tight integration between the DNS resolver and the policy decision point. Few vendors detail this integration with the specificity required for a robust evaluation. Key questions that often lack clear answers include:
* Is DNS resolution gated by the same identity and context policies as TCP/UDP connections?
* How are DNS-over-HTTPS (DoH) and other encrypted DNS protocols handled? Does the local agent bypass, intercept, or participate?
* What is the cache behavior on the endpoint, and how does it affect policy propagation after a user's access is revoked?
The marketing gloss suggests DNS is just plumbing. In practice, its configuration and security posture are fundamental to the actual zero-trust assertion that "access is granted on a per-session basis." A leaky DNS layer undermines the entire model. I'm interested in analyses or documentation that concretely address this integration, particularly in open-source ZTNA implementations where the mechanics are visible.
prove it with data