I’ve tried upgrading to 0.112.3 three times, every time I do when the device reboots all of the devices are inoperable. I suspect the latest version tries to get around DNS blocking by connecting directly to something like 8.8.8.8 or 1.1.1.1. This is a problem because I block devices from being able to do that.
How can I confirm or rule this out as a possibility?
ha dns options --servers dns://8.8.8.8 --servers dns://1.1.1.1
replace 8.8.8.8 and 1.1.1.1 with servers of your choice.
how do I do this if I can’t ssh in
Why can’t you ssh in?
I’m concerned about this as well, I redirect / reject all packets trying to access any kind of dns outside my local network unless they originate from router1. I’m using latest HA installed in python virtual environment on a raspberry pi 3b+ and the command ha is non-existent. How would I go about checking the dns settings in this kind of installation?
Apologies if the issue does not apply to “manual” install, although hardcoding dns (especially google dns) is a bad practice regardless imho.
Thanks!
Depending on your router, you can redirect DNS queries to the server of your choice. On my USG, I have this NAT rule that silently redirects traffic to any outside DNS server (running on 53) to its internal relay of my OpenDNS servers.
"service": {
"nat": {
"rule": {
"1": {
"description": "DNS Redirect",
"destination": {
"address": "!192.168.1.1",
"port": "53"
},
"inbound-interface": "eth1",
"inside-address": {
"address": "192.168.1.1"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
}
}
}
},
I don’t remember the specifics but the way I installed Home Assistant prevented from being able to SSH into the device. I spent far too much time trying to get around it and got nowhere.
If it is HA trying to get around my DNS blocking by going directly to the IP of a Public DNS Server that’s a problem, because I am going out of my way to make that as close to impossible as I can. Google set a bad precedent others are following with this.
Why do you even think it is a possibility? Seems like guess work to me. What do your logs say?
OK that is more informative 
What sort of install are you running? Adding a keyboard and monitor may be the way forward.
Sorry to hear that. As someone who has lived in a disaster zone (earthquakes) I fully sympathise.
What sort of install are you running? Still not answered that one!
Can you borrow a monitor/keyboard? - perhaps all your friends and neighbours are in the same position.
When you say you can’t SSH in, do you mean to the actual machine or to HA? Because it looks like you have supervisor running so if you install either the official SSH add-on or the community one you should be able to SSH into HA.
Assuming you can get one of those add-ons installed, try running the command ha dns info. That should tell you the DNS servers that HA is using. If you don’t like what you see you can change it by doing this:
ha dns options --servers dns://IP_ADDRESS
ha dns restart
[EDIT] I haven’t tried it but if for some reason SSH absolutely isn’t an option, all the HA CLI matches up with a REST interface. So there should be a way to make calls into supervisor’s REST API and take the same actions. Would just require a bit more digging
Please don’t redirect DNS requests.
You will break things that have signed DNS.
Block external DNS by all means - but don’t transparently redirect.
It is likely the address within docker.
By the way, I have a supervised install and this works perfectly:
ha dns info
host: 172.30.32.3
locals: []
servers:
- dns://192.168.20.126
version: "9"
version_latest: "9"
192.168.20.126 is my pihole machine.
Glad to see some noise about this again. My DNS config is pointing to my internal DNS server (confirmed via ha dns info and DNS server log activity), but something is reaching out to Cloudflare DNS servers via TLS, even on a clean install.
I’m sure it isn’t malicious, but would love to know which component isn’t honoring my DNS settings.
So what is generating those packets? Something on the machine homeassistant.lan, but the logs don’t reveal what program is actually generating the packets.
On the home assistant machine
watch netstat -tanp
may give a clue.
That’s the weird part, I haven’t been able to find any matches in netstat on the console.
FYI, just checked every container for this, and besides the multicast container reaching out to some Kubernetes Ingress endpoint (which is yet another issue I need to check out - https://205.234.31.120/), I didn’t see any references to 853 or 1.0.0.1 in /etc and netstat.
I finally spent some time digging into this, and I think I’ve figured it out. It looks like the hassio-dns container, running CoreDNS and the coredns-fallback plugin is forwarding all types of failing DNS lookups to Cloudflare:
bash-5.0# more /config/corefile
.:53 {
log
errors
loop
hosts /config/hosts {
fallthrough
}
template ANY AAAA local.hass.io hassio {
rcode NOERROR
}
mdns
forward . dns://my.internal.dns.server dns://127.0.0.1:5553 {
except local.hass.io
policy sequential
health_check 5s
}
fallback REFUSED . dns://127.0.0.1:5553
fallback SERVFAIL . dns://127.0.0.1:5553
fallback NXDOMAIN . dns://127.0.0.1:5553
cache 10
}
.:5553 {
log
errors
forward . tls://1.1.1.1 tls://1.0.0.1 {
tls_servername cloudflare-dns.com
except local.hass.io
health_check 10s
}
cache 30
}
So as expected, it isn’t malicious, but I’m very much against this behavior. If I have custom DNS servers defined, that means I want to stay in control of my DNS. The whole point of Home Assistant is to protect our privacy and not depend on the cloud, right?
On to digging into the multicast/kubernetes phoning home behavior. I’ll start a new thread if I find anything.
If you want any traction on this I suggest you post an issue on github… Speaking generally, the devs do not respond to issues like this on the forum. Good luck