Microsoft recently announced what they refer to as ZT DNS. It is exciting to see that some of the larger industry players are finally awoken to explore applying Zero Trust tenets to internet connectivity.
Since the first Don’t Talk to Strangers (DTTS)® enabled adam:ONE® system went online in our lab in 2016, we have been strongly advocating for Zero Trust connectivity (ZTc) and a lot of refinement had to go into adam:ONE® to make ZTc truly practical. It is great that the immense value of operating in a ZTc environment could now finally become clear to the security community as industry forces are starting to explore this path.
Our aim is to protect people and the systems they rely on. Applying Zero Trust connectivity correctly has values far beyond the obvious expected security consequences. Let’s look at some key points together.
Main Goals
In this article, we will illustrate why the approach to Zero Trust connectivity (see adamnet.io/ZTc) is best achieved by applying it at the gateway for persistent devices and on the endpoint for multi-homed/roaming devices, while using a single pane of glass for rules and policy management.
At the core of ADAMnetworks’ ZTc enabling technologies lies DTTS® (Don’t Talk To Strangers®) which is described in a School of Cyber post here:
Part of the question is how to get DNS secured in the first place.
As stewards of technology, any time we move from an insecure-by-design to a secure-by-design approach, we encounter problems that are often compared to open heart surgery: it’s important to stay alive during the process. Likewise, there’s a strong desire to secure networks without breaking them in the process beyond necessity.
The industry has done this several times now with protocol-level security improvements including:
- Email: SMTP plaintext to STARTTLS - this one we solved within the SMTP conversation by asking “Can we start encrypting our data exchange?”
- The web: HTTP to HTTPS - this one was much more complicated but we’re basically there now without having broken any http-only services which still play an important role.
- DNS to DoH/DoT - for this one, RFC9462 became standard in November 2023 and it involves the endpoint asking the current clear-text DNS provider “do you have any secure DNS I can use?” which is technically done with an SVCB (Type 65) query of _dns.resolver.arpa aka DoH bootstrapping.
Sometimes we can make a case for killing the insecure protocol and just replacing it entirely. We did this decades ago with Telnet (TCP port 23 default) and simply started using SSH (TCP port 22 default) instead. Microsoft seems intent on taking this approach with DNS and avoids legacy DNS entirely, but thereby making it highly impractical to be adopted.
Comparing ADAMnetworks ZTc (Zero Trust connectivity) with Microsoft ZTDNS
| ZTc (adam:GO™ Windows) | ZTDNS | |
|---|---|---|
| DoH bootstrapping | Via RFC9462, does not need to be a managed endpoint, so it is more widely deployable. It is compatible with earlier versions of Windows since Windows 10 1909. | Via MDM, must be managed via MDM, may be limited to Windows 11+ |
| Captive Portal compatibility | Compatible | Incompatible (expressly with no plans for making it compatible) |
| Printing (mDNS-dependent printers) | Compatible | Incompatible |
| SMB File Shares | Compatible | Incompatible unless “Protective DNS Servers” are local |
| Teleconferencing Apps | Compatible via well-known Enablers | Incompatible |
| Casting to wireless displays | Compatible | Incompatible |
| Apps with hard-coded or non-DNS-discovered IP addresses | Customizable Enablers facilitate FQDN, IP ranges, protocol and port ranges | Incompatible unless allow-listed manually |
| IP allowlisting | Enablers available for well-known apps, tools available to discover IP addresses, protocols and ports to be permitted | Unclear |
| Multi-policy | Role-appropriate policy can be unique or group-based | Unclear if this will be an option |
Potential Modes of operation of Windows endpoints
When considering the importance of protecting Windows endpoints, there are a variety of options:
Mode 1: adam:ONE® only (no ZTDNS or other Windows agent)
- Active from the first time device is powered on, never experiences a moment without ZTc while it remains on the protected network and on the appropriate policy
- Lowest overhead and deployment support required for devices that never leave the designated LAN
Mode 2: ZTDNS without adam:ONE® (for multi-homed devices)
- DoH/DoT “Protective DNS Server” must be reachable from anywhere the multi-homed device may travel
- For enterprise deployments, this may mean
- DoH and/or DoT client certificates need to be delivered to endpoint (via MDM)
- Be prepared for many incompatibilities
- If the “protective DNS” is Active Directory, the danger is that AD needs to be in the most permissive policy of all when it is the recursive resolver for endpoints (this goes against the notion of protecting more valuable assets with stricter policies)
Mode 3: ZTDNS with adam:ONE® as “Protective Resolver” (for multi-homed devices)
- adam:ONE® is deployed to be reachable from anywhere
- Some ZTDNS incompatibilities are resolved with adam:ONE® being the protective resolver, ie File and Print
- adam:ONE® policy for ZTDNS clients represents no conceptual incompatibilities since DTTS features are disabled at the gateway when those functions are applied at the endpoint
- This service is available only on managed plans with Licensed Technology Partners
Mode 4: adam:GO™ Windows (without ZTDNS client) (for multi-homed devices)
- The same protections are offered as ZTDNS but without most of the incompatibilities
- This service is available only on managed plans with Licensed Technology Partners
Mode 5: adam:OSN™ Windows* (without ZTDNS client) (for multi-homed devices)
- OSN = Operating System Native implementation of adam:ONE® with DTTS
- Note this product is in development
- Could not coexist with ZTDNS as adam:OSN™ uses Windows Firewall integration for outbound allow rules
- This service will be available only on managed plans with Licensed Technology Partners
Comparing Modes and Deployments
| Mode | Ideal for fixed computers/servers/VMs/IoT/other | Appropriate for multi-homed Windows devices |
|---|---|---|
| adam:ONE® gateway (no endpoint agent) | Yes | No |
| ZTDNS with “protective DNS” (not adam:ONE®) | No | Good |
| ZTDNS with adam:ONE® | No | Better |
| adam:GO™ (Windows, ChromeOS, iOS, Android) | No | Best |
| adam:OSN* (in alpha for iOS, in development for Windows) | No | Best |
adam:ONE® vs adam:GO™ vs adam:OSN™*
adam:ONE®: Endpoint → gateway (ZTc) → Internet:
adam:GO™ Endpoint → Full always-on VPN tunnel → gateway (ZTc) → Internet:
adam:OSN™* Endpoint ZTc native via agent/app/service → any hostile gateway → Internet:
Combined: one pane of glass of centralized controls but decentralized protection:
*adam:GO™ OSN is a product in development and testing, and not yet available to the public as of this posting
Additional notes
It is worth noting that as ZTc is more broadly adopted, application developers will be motivated to use DNS as the only IP discovery mechanism and thereby minimize application support requirements.