New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of CloudFlare DNS, Privacy Breach #22
Comments
|
Fully agree and...
I'm having that exact same issue as well. |
|
I discovered this today, and was promptly blown off by some of the "moderators" in the Discord channel for things "working as intended". However, this is a huge violation against the very philosophy of privacy and control that the entire Home Assistant project is built around. The following screenshot is taken from my local Splunk instance, where I am logging a firewall rule blocking all outbound DNS from my network, as to force DNS requests through my ad-filtering DNS server. As you can see, this is an absolutely unacceptable amount of requests to be made in a mere 4 hour span, and is practically a request every second. The only way I have found to get it to stop is to restart the We can see that the CloudFlare DNS server are hardcoded in the following files: While I understand the desire to have reliable DNS accessibility within your code, this has to be mitigated. From both an ethical and security standpoint. The locally provided DNS settings by the network should be honored, and this implementation of DNS-over-TLS should be opt-in only. Additionally, while not included in the IEEE specification for DNS-over-HTTPS or DNS-over-TLS, Mozilla has implemented means of allowing a user or administrator to disable the use of DNS-over-HTTPS through the use of what they have called a Canary domain. The implementation of this check may require additional overhead of the CoreDNS service used by the hassio_dns container, but is well worth the cost of honoring the core philosophy of privacy and control that Home Assistant is built upon. |
|
I have a feature request for this on the community forum: https://community.home-assistant.io/t/improve-privacy-stop-using-hardcoded-dns/273496 |
Looks like I was working on incorrect info. What's stopping you from updating |
|
Well, not entirely true. If you look at my "dns info" I see: Which would imply it's using my local pihole. But "dns logs" shows this: So it's definitely trying to access Cloudflare 1.1.1.1. The errors are expected since I blocked port 853 on my firewall unless it comes from my pihole. |
Unfortunately, the It works based on a template that you can see here: You can clearly see that the Cloudflare DNS is being hard-coded (and used as forwarder) and there is no way for the Also, it would be more healthy for the community if you could be less condescending and more understanding. |
|
Isn't this all kind of pointless giving the oncoming onslaught of DNS over HTTPS? The real "privacy breach" is allowing networks to inspect and mess with requests en route. |
|
I mean don't get me wrong, I think we should be able to switch from CloudFare to another provider like NextDNS, but overall it seems like it would be far worse for HA to not use DNS over HTTPS by default, and I certainly wouldn't describe this as a "huge breach" or "fundamental problem". The vast majority of users are not doing network DNS shenanigans and this just protects them from their ISPs. |
|
I think the real issue here is hard-coding a configuration that we might not need and that can't be changed. For the original poster that translates in a privacy breach that he doesn't want.
Both of these issues wouldn't be issues if we could control using or not Cloudflare as backup forwarder instead of hard-coding (forcing) it. Not everyone needs a fallback forwarder and as someone already mentioned, our home networking (i.e. given by our routers via DHCP) should be honored over any fallback setting. |
|
I wouldn't really describe properly encrypting DNS traffic as a "configuration that we might not need". It's fundamentally problematic to code your application that ever sends traffic unencrypted across the network, including DNS. In a zero trust model, you never trust any middlemen, including the local network, and you certainly don't defer to it. Again, we should be able to change which DNS over HTTPS resolver we're using, but I don't think we should be able to disable DNS over HTTPS entirely. |
This setting is not 'configurable' via the command line, or by any other method. Why don't you take the time to read the issue properly, and less time trying to level up your Troll score by making Please don't loose sight of the issue here, the CoreDNS module is using a hardcoded IP address (CloudFlare) to use DNS-over-TLS as an apparent 'fallback' if the users network configuration fails. That would be all well and good, but when there are no issues with the users DNS, this module still constantly calls out to this IP. I just want to retain a level control, and not have the devs hard code in a catch all because some users cannot configure there networks correctly. |
|
Supervisor enabled systems are here to take away part of the maintenance and offers lots of fallbacks to get people lacking the technical knowledge to get out of problems. This is exactly what is in place here. It is the sole goal of this platform, making things more accessible.
There is no private data send. Simple as that. Additionally, if you are worried about data send, you can always review the policies of CloudFlare.
Besides all things in the above. If you are looking for that level of control; you are running the wrong Home Assistant installation method. Consider using the Home Assistant Core or Container installation methods instead. All that said, I think it would be fine to create an option to disable this. This would need a setting in the CoreDNS Plugin, Supervisor, the Supervisor API and the CLI would need to be adjusted. Feel free to jump into the development of this Closing this issue, as this is not a bug. |
In my supervisor-enabled system, this configuration is actually causing me a connectivity problem that I have to workaround by manually setting DNS servers using The problem for me is this (again):
In my particular home network, IPv6 doesn't work correctly and I have no control to be able to fix it. This is why I disabled IPv6 in the supervisor but still the DNS plugin is trying to go IPv6. I can't use the DuckDNS add-on unless I apply the workaround I mentioned. At the very minimum the DNS plugin should respect that IPv6 is disabled in the supervisor network configuration. This can be easily classifed as a bug. This of course completely apart from the privacy issue of the original poster. @frenck do you want me to open an issue to track this particular issue? |
|
@hhromic It is most certainly not related to the subject raised here; so yes. |
I spent half an hour investigating further here for you: https://www.reddit.com/r/homeassistant/comments/l7f66r/breach_of_privacy_in_home_assistants/glcbk1c/ I will admit that I haven't spent a massive amount of time on this, and am relatively new to hassos, but it seems to me like 4 steps to achieve your goal. I could be mistaken, but I stand by my original statement - this seems like a trivial feature request, as opposed to the drama it's been made out to be in this thread. |
I agree - I was responding to what I saw was an excessive amount of drama for an edge-case feature request, which is similarly unhealthy for the community. This ticket would be fine as a feature request. You could even champion the security benefits of it as a feature request. But to raise a bug as "privacy breach" and talk about "third party exfiltration of data" via a "covert channel" - tell me that's honestly healthy for the community. The devs used a more secure form of DNS by default, and everyone's jumping down their throats like they're Facebook - Not Helpful. |
|
There is 1 feature request here and 2 bugs:
@peter-dolkens This is a privacy breach and data is being exfilled to a 3rd party. Secure DNS-over-TLS is being used in this context to circumvent local DNS policy on a users network, not for illicit reasons, but because the devs have problems with users that have misconfigured DNS. So, from one perspective this is increasing functionality and using a best practice secure method of doing so, and from another perspective this is a system which is designed to specifically bypass local network policys and contact a service that the users network has not authorised. Also, yet again with troll levelling band wagon by trying to alter the context. i.e. no one mentioned "covert channel" apart from you in your last comment. |
This issue has gained more traction elsewhere with further inflammatory verbage - e.g. https://www.reddit.com/r/homeassistant/comments/l7f66r/breach_of_privacy_in_home_assistants/gl6cjtw/
Your 1/2/3 list looks perfectly fine to me - but no data is being "exfilled" to a third party.
Again, this is deliberately inflammatory verbage that evokes thoughts of Cambridge Analytica type stealing of your secrets, as opposed to "used a secured, privacy-conscious third party DNS that protects against ISP/Government metadata collection as a backup DNS". It is being sent - yes. But they're not trying to hide it from you - or this fallback would be carefully hidden inside compiled binaries instead of template file. |
|
Let me be clear, nobody is forcing anything. We are open to contributions that adds features to improve this (as said before, even outlined a high-level view of work that needs to be done for it). I'm locking down this topic for now as this has became more of a "demand a feature" thing. |

The CoreDNS module is Home assistant is using CloudFlare DNS-over-TLS by default. This is basically exfilling my private data to a commercial 3rd party without my permission. There is no currently no way to disable this functionality.
The CoreDNS module also attempts to lookup IPv6 AAAA records using CloudFlare when IPv6 is disabled in the supervisor network configuration.
Hardcoded DNS is a breach of privacy and trust, either remove it completely, or provide an option to disable it.
The text was updated successfully, but these errors were encountered: