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.
-
Definitely a major pain point here for those self-hosting services and relying on a Firewalla device. I've spent more time than I care to admit, troubleshooting my in-house applications and services and assuming I had something incorrectly configured, only to find that aside from setting up something additional (hardware or software wise) to handle DNS queries, nothing could be done. Users need to be given a way to easily manage DNS on their Firewalla device, comprehensively, or Firewalla should update the software to make assumptions based on the custom DNS entries. If a custom DNS entry exists for a given DOMAIN, then redirect all queries for that domain, be it an A, AAA, or HTTPS record etc. Otherwise whats the point of using any DNS rules if they are all bypassed by current devices like Apple iPhones. Hopefully Firewalla is already working on implementing this asap.... if not... what are the best ways to get this bumped to the front of the feature queue @Firewalla ?
-
I've been chasing some issues down around ECH related to my internal services (LAN only) and today I discovered that Firewalla has been leaking my internal queries to an external service because of this gap... On top of this, as others have stated, it causes issues with even accessing my internal services backed by my internal CA.
This is very disappointing and has me considering moving my DNS services off of the Firewalla, which really defeats the whole purpose of this purchasing/using this device.
I hope the team addresses this with priority. I used to recommend this family of devices to anyone who would listen, but I definitely feel a bit betrayed that filtering is advertised as supported yet this limitation is present without being communicated to the user...
Please sign in to leave a comment.
Comments
10 comments