DNS Leak
I have custom DNS rules setup to redirect (let's call it homedomain.com) to an internal IP address and on the surface all appears to work fine.
The expectation was that all requests for this domain would be resolved internally and never have to leave my local network.
However, after checking my NextDNS logs, the reality is that (homedomain.com) is my most "popular" query by far with 47K queries in the last 30 days.
How did the requests even get to NextDNS when they should have been resolved at Firewalla?
Enter HTTPS(Type 65) DNS queries.
Every time the browser makes an A(1) record request for my (homedomain.com), it also makes a simultaneous HTTPS (65) record request to quote "optimize performance and security".
Firewalla responds to the A(1) record with my internal IP but can't respond for an HTTPS(65) record request so it dutifully forwards it to NextDNS for resolution.
So my question is, can Firewalla either:
a) respond correctly to HTTPS (65) record requests for Custom DNS Rule domains
OR
b) block HTTPS(65) DNS requests from leaving the network, IF the domain in question has a corresponding Custom DNS Rule
TL;DR:
DNS requests for local devices are going external and they shouldn't be.
I'd like Firewalla to please respond to or block the offending DNS requests.
-
All devices get their DNS settings from Firewalla via DHCP and use Firewalla's DNS over HTTPS feature to direct external DNS traffic to NextDNS.
As for the internet itself, some of the devices use Firewalla's VPN Client feature to be connected to a 3rd-party VPN, with the setting for "Force DNS over VPN" turned off (else no connection to local servers).
The other devices, have no special settings and simply pass through the Firewalla to the upstream ISP.
In either case, HTTPS (65) queries were observed in the logs of NextDNS for domains which were explicitly defined as local using Custom DNS Rules.
-
I went back and forth with firewalla on this for a while. At the end of the day, firewalla does not support type 65 queries. This really needs to be implemented by firewalla quickly and is going to become more and more of a problem.
This occurs regardless of whether a vpn is used and even when every dns setting in firewalla is disabled. Firewalla simply doesn’t handle type 65 and lets it be passed upstream which defeats the entire purpose of being able to set custom dns in firewalla.
-
@Tyler I agree. This DNS leak issue is not going away since it is a "feature" of modern browsers on all operating systems.
And it affects everyone that is using Firewalla's Custom DNS Rules feature to redirect domains to internal IPs (which I would imagine encompasses most of their use case).
These users believe their requests are kept local but they are not.
If I didn't have NextDNS configured, any upstream external DNS would be able to see the names of all internal services.
-
Exactly. The other major issue is that internal services become completely inaccessible when the dns bypasses firewalla. In my case, the dns queries were resolving to my cloudflare dns entries because firewalla let it through and wasn't routing it. When that happens, the browsers time out and say they could not reach the server because there are no dns entries publicly for those internal services. This is expected when someone tries to access internal services externally, but not when I'm on my own lan and firewalla just lets the dns pass upstream instead of routing it correctly based on the custom rules.
Please sign in to leave a comment.
Comments
8 comments