I have a pair of local LAN DNS servers which forward to a pair of Linux VMs which run Cloudflared and provide DNS over HTTPS. After enabling DNSSec validation on the local LAN servers (Windows Server 2019 DNS, if it matters) both the Cloudflare ENSI Checker and the 1.1.1.1/help site no longer detect that I am using Secure DNS. The ENSI checker does detect that I am now validating DNSSec however.
If I disable DNSSec Validation, both sites detect things properly.
With DNSSec enabled I can see the traffic being forwarded by the LAN server to the Cloudflared server via tcpdump and I can see the Cloudflared server send the correct response back to the LAN server, so it seems DNS resolution is working.
Is this simply a flaw with the way the ENSI checker and 1.1.1.1/help detect Secure DNS, or am I actually exposed in some manner which I may not understand?
isCf will only resolve if the DNS server sees the request coming from a CF IP address (/1.1.1.1), isDot will only resolve if the connection to 1.1.1.1 is over Dns over TLS, and isDoh if it’s via Dns over HTTPS.
If you can see logs of DNS responses, see if Cloudflared is the one responding to these Cloudflareresolve.com DNS requests. My guess is your software may be acting as its own Recursive resolver to validate DNSSEC, but I may be wrong.
Hi Judge - thanks for your reply. I meant to post a reply yesterday, but eventually it just started working - both the ESNI checker and 1.1.1.1/help. I re-enabled DNSSec on the Windows DNS server and on a whim, tested both sites about an hour later and both worked. They still work today.
I know the Windows DNS has to do something with trust anchors, so maybe DNSSec hadn’t been fully activated by just enabling it and telling to download them?
If it breaks, I can definitely enable Windows DNS logging and see what is resolving those, thanks for the tip!