DNS over HTTPS (DoH) and other encrypted DNS protocols like DNS over TLS (DoT) & DNS over QUIC (DoQ) enhances user privacy and security by encrypting DNS queries in transit, shielding them from eavesdropping, tampering, and censorship on untrusted networks. This prevents ISPs and local attackers from logging or manipulating domain resolutions, fostering a more trustworthy internet experience.

However, a key setback is that conventional application of encrypted DNS causes network defenders—such as enterprise admins or parental controls— to lose visibility and enforcement over DNS traffic, undermining their ability to apply Protective DNS rules, block malicious domains, or monitor for threats.

The status-quo response to this problem is to attempt to block DoH services to regain the security control of PDNS, and sacrifice the security value of DoH in the process. This is in some cases very hard to do and stealthy malware goes to great extreme to not be detected when using DoH as C2 channel.

See CISA’s Memorandum from 2020

The good news is that the use of a local Zero Trust Resolver could allow defenders to have the benefit of using DoT, DoH & DoQ while maintaining complete control over DNS policy enforcement.

The focus here is on a gateway-level approach which means no modification to endpoint devices’ DNS needs to be made.

In the case where an endpoint attempts to use a non-assigned DNS resolver, let’s use this example in a lab on my macOS environment. Encrypted DNS is offered opportunistically via DDR:

davidredekop@mbpro ~ % cat /etc/resolv.conf |grep nameserver
nameserver 10.53.10.1

davidredekop@mbpro ~ % netstat -nr | grep default
default            10.53.10.1         UGScg                 en6     

davidredekop@mbpro ~ % dig TYPE64 _dns.resolver.arpa
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 7915
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; _dns.resolver.arpa. 		IN	SVCB

;; ANSWER SECTION:
_dns.resolver.arpa. 	60	IN	SVCB	1 anw-jcmhp33c4zj.2my.network. alpn="h2" port=443 ipv4hint=10.53.10.1 dohpath="/dns-query{?dns}"

;; Received 131 B
;; Time 2025-10-31 13:42:46 EDT
;; From 10.53.10.1@53(UDP) in 2.3 ms

The gateway and assigned DNS resolver is the only way that outbound traffic will be allowed. Now let’s see what happens if we use a non-local resolver, which is going to get hijacked when using Do53:

davidredekop@mbpro ~ % dig @1.1.1.1 badactor.co
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4580
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; badactor.co.        		IN	A

;; ANSWER SECTION:
badactor.co.        	60	IN	A	10.53.10.1

;; Received 56 B
;; Time 2025-10-31 09:48:09 EDT
;; From 1.1.1.1@53(UDP) in 1.5 ms

What we see here is that an answer was provided, which is the blocked IP address. The endpoint experiences a policy-based answer, even though it attempts to bypass it. This demonstrates that Do53 queries are zero risk while simultaneously having full functionality as the policy engine permits.

This is where DTTS (Don’t Talk To Strangers) kicks in. Let’s use the same environment and try and use a DoT or DoH query:

davidredekop@mbpro ~ % dig +tls @1.1.1.1 badactor.co.
;; WARNING: can't connect to 1.1.1.1@853(TLS)
;; ERROR: failed to query server 1.1.1.1@853(TCP)

davidredekop@mbpro ~ % dig +https @1.1.1.1 badactor.co.
;; WARNING: can't connect to 1.1.1.1@443(HTTPS)
;; ERROR: failed to query server 1.1.1.1@443(TCP)

Unlike Do53 hijacking above, DoT and DoH are not hijackable and shouldn’t be. However, the DNS query attempts are simply blocked.

It is really important to understand that this blocking isn’t happening via a blocklist. This blocking of direct-by-IP is because 1.1.1.1 was not resolved by an allowed DNS query to begin with. Any attempt to do so will fail at the DNS level with the default rule of Enable DNS firewalling. For example:

davidredekop@mbpro ~ % dig one.one.one.one
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 30152
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 17 (Filtered): 'nxdomain-ed by rule'

;; QUESTION SECTION:
;; one.one.one.one.    		IN	A

;; Received 69 B
;; Time 2025-10-31 10:29:39 EDT
;; From 10.53.10.1@53(UDP) in 1.8 ms

Any DNS-based blocking also includes an Extended DNS Error (EDE) as can be seen above.

Let’s try and use a deliberately-allowed DoH service as an example of one that wasn’t DNS-blocked, and therefore DNS queries are made blind to the network controller.

It is impossible to enumerate or detect all DoH URLs with certainty, so let’s just use dns.google for the sake of this illustration. But first, remember:

• The network-assigned DNS resolver is the local gateway running DTTS (Don’t Talk To Strangers)

• The endpoint’s only outgoing IP connections must be verified by policy and resolved at the assigned resolver, which creates a short-lived allow rule

• Any other IP discovery service does not indiscriminately allow egress

Let’s try it out by attempting a simple DoH resolution:

davidredekop@mbpro ~ % dig +https @dns.google www.example.com
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; HTTP session (HTTP/2-POST)-(dns.google/dns-query)-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 4; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR
;; PADDING: 310 B

;; QUESTION SECTION:
;; www.example.com.    		IN	A

;; ANSWER SECTION:
www.example.com.    	291	IN	CNAME	www.example.com-v4.edgesuite.net.
www.example.com-v4.edgesuite.net. 16006	IN	CNAME	a1422.dscr.akamai.net.
a1422.dscr.akamai.net.	14	IN	A	23.223.17.165
a1422.dscr.akamai.net.	14	IN	A	23.223.17.179

;; Received 468 B
;; Time 2025-10-31 10:48:23 EDT
;; From 8.8.8.8@443(HTTPS) in 55.4 ms

This is the concern and the “blind” aspect that network defenders are concerned about and perfectly describes the frustration of “my network, my rules” was taken away from the defenders.

Ok fine, the resolution took place, but from the perspective of Zero Trust connectivity, that IP address is a stranger and has not been added to the outbound short-lived allow rule.

Attempting to connect with curl does this:

davidredekop@mbpro ~ % curl -v -k https://23.223.17.165  
*   Trying 23.223.17.165:443...
* connect to 23.223.17.165 port 443 from 10.53.10.149 port 62336 failed: Connection refused
* Failed to connect to 23.223.17.165 port 443 after 3 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to 23.223.17.165 port 443 after 3 ms: Couldn't connect to server

The rejection is happening at the gateway. This is because from the perspective of the security gateway, 23.223.17.165 is a stranger. The name resolution did not occur on the network-assigned resolver and gateway, so it’s not part of any allow rule.

On the other hand, www.example.com works just fine when following policy:

davidredekop@mbpro ~ % curl https://www.example.com
<!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="width=device-width, initial-scale=1"><style>body{background:#eee;width:60vw;margin:15vh auto;font-family:system-ui,sans-serif}h1{font-size:1.5em}div{opacity:0.8}a:link,a:visited{color:#348}</style><body><div><h1>Example Domain</h1><p>This domain is for use in documentation examples without needing permission. Avoid use in operations.<p><a href="https://iana.org/domains/example">Learn more</a></div></body></html>

This default-deny-all is and can be done at scale with this approach. For scenarios where external DNS resources must be allowed during onboarding and avoid disruption of connectivity, of course it can be facilitated with a modified, permissive policy, which can be selectively assigned.

Once a rollout is complete, though, the target state offers DNS Encryption inside the perimeter and only uses DNS Encryption to other protective resolvers.

Endpoint using Encrypted DNS → Zero Trust Resolver → Protective Resolver(s)

See NSA’s Guidelines on the Adoption of Encrypted DNS in Enterprise:

https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF

At the time of publication, adam:ONE® already offers defenders all the technical requirements for fulfilling these guidelines with the ability to provide internal encrypted DNS as well. For more information visit https://adamnet.works

1 post – 1 participant

Read full topic

*** This is a Security Bloggers Network syndicated blog from The ADAM Blog - ADAMnetworks authored by David. Read the original post at: https://support.adamnet.works/t/preventing-dns-filtering-bypass-by-encrypted-dns-dot-doh-doq/1490