DNS Encryption (and DNS-over-HTTPS specifically) has been simultaneously a very good step forward for security and privacy, and temporarily bad for network security environments where they did not immediately adopt additional necessary changes.
The benefits of DNS encryption has been obvious: the last remaining default clear-text network traffic is finally being secured and encrypted, offering privacy as well as preventing miscreant-in-the-middle (MiTM) attacks that leverage DNS answers for malicious purposes.
On the other hand, DNS as a control plane in the context of traditional network protection has been completely disrupted. Let’s say you depended upon endpoints gracefully accepting the DHCP-provided DNS server of your internal protective DNS resolvers and suddenly, browser updates ignore system-provisioned DNS and just use a public non-protective resolver directly. This is what happened by default with Firefox when DoH rapidly became a standard and told the browser to just use 1.1.1.1. When this happened, a massive amount of previously-protected devices instantly went unprotected; or were subject to external policy decisions completely different from that of the local network administrator. See the 2020 CISA Memorandum for disallowing DoH/DoT on Federal Agency Networks.
I can just hear the collective scream of frustration from all the network security teams around the world that used good, solid standards of Protective DNS servers before they were even called such a nice name. It became a moment of collision of the good efforts of the past with well-intentioned efforts of the future. We want to have our cake and eat it, too.
In other words, we want all of the privacy, protection and security we can get with DNS encryption, but now we have to change our ways in order for our security model to keep working.
The goal is to do both: Offer DNS encryption and keep it as a control plane.
For us to do well at ADAMnetworks by those we protect, we must do everything right by addressing traditional, legacy, clear-text DNS, as well as offer encryption in a way it is intended. At the same time, we will prevent this approach from being abused by bypassing it as the control plane.
Here is how we do it with adam:ONE® provisioning:
-
Legacy DNS queries (those running over UDP and TCP port 53) to an internet-bound server are simply redirected and answered locally by the adam:ONE® caching resolver, using a policy approach
-
For newer Operating Systems that use Discovery of Designated Resolvers (RFC9462) we offer DoT and DoH from the edge of the network to any and all internal devices
% dig SVCB @192.168.128.254 _dns.resolver.arpa +short 1 anycorp-1zsq1h7h.2my.network. alpn="h2" port=443 ipv4hint=192.168.128.254 key7="/dns-query{?dns}" 1 anycorp-1zsq1h7h.2my.network. alpn="dot" port=853 ipv4hint=192.168.128.254 -
Upstream DNS queries to Encryption-supported hosts such as Quad9, concurrently checking with multiple Protective DNS resolvers concurrently (can be on-prem or in the cloud) via DNSharmony
-
Deploy Don’t Talk To Strangers (DTTS) so that only locally-provided DoH answers are usable
Note that even if a publicly-reachable service offers DoH, any IPs discovered through means other than adam:ONE, do not open outbound channels so those connections are never successfully made
In the end, the ADAMnetworks approach is simple, elegant, and it works. Endpoints experience encrypted DNS, the control plane is intact so privacy and security are all maintained.
It really is that simple.
Without Zero Trust connectivity, the remaining concern for networks everywhere is that the DoH channel offers a remarkable available resource for bad actors to hide in plain sight. GoDoH isn’t the only open and free resource available to do exactly that. It is essential to go all the way with ZTc in order to prevent DoH from being used as a C2 channel by malicious actors. Not only are direct-by-IP connections denied by default (e.g. https://1.1.1.1 is not reachable, nor is any other IP) unless it was allowed by a DNS query by policy (see how DTTS works). Furthermore, the Protective DNS Resolver of ZTc denies connections to FQDNs that offer DoH services.
For more information on setting up Encrypted DNS on your adam:ONE® ZTc security stack see this article.