Because DNS is so broken in HAOS that it isn’t even funny anymore & Pascal Vizeli has given up on trying to fix it.
1 Like
I appreciate the reply, can you point me to any open relevant GH issues or threads here? I’d love to contribute back if I can but am pretty new to this project beyond installing it 
unfortunately I can’t. The dev has been actively closing open issues so that he doesn’t have to fix it.
I’ve also been wondering what’s going on. Everything looks good with the OS (Debian in my case). All IP addresses are static and look correct in /etc/network/interfaces. I also have a local DNS resolver on my router and can see occasional traffic from the OS, but I can also see requests for Cloudflare (1.1.1.1) which I’ve never configured. Somehow, things are working well enough, so I haven’t yet written a PR .
When I initially looked at the Host System Network Setting, they’re not populated with OS values. Surprisingly, they’re disabled. This might’ve happened when I updated Supervisor to 2020.12.7. When I initially tried to set them, I get this:
Failed to change network settings
Error: GDBus.Error:org.freedesktop.NetworkManager.Settings.Connection.InvalidProperty: ipv6.method: property is invalid
Realize, I’m not using IPv6.
I tried a few more times and it populated. After a reload of the GUI page, it’s disabled again.
Network info in HA looks like this:
docker:
address: 172.30.32.0/23
dns: 172.30.32.3
gateway: 172.30.32.1
interface: hassio
host_internet: null
interfaces:
- connected: false
enabled: false
interface: enp2s0
ipv4:
address: []
gateway: null
method: disabled
nameservers: []
It looks like the Supervisor is running it’s own DNS resolver and gateway.
DNS info in HA looks like this:
host: 172.30.32.3
locals: []
servers:
- dns://192.168.0.1
update_available: false
version: 2020.11.0
version_latest: 2020.11.0
It looks like 172.30.32.3 is in fact the hassio-dns container which contains a coredns name server. I am also having local hostname resolution problems - with a standard HassOS/HA setup. When I try and use local hostnames in configuration.yaml they fail to resolve and I have to use IP addresses.
I did some digging around to try and see what is going on.
From within the homeassistant docker container the name server is set to 172.30.32.3 (the hassio-dns container) and local name resolution fails - eg dig pdu3.netality.co.uk doesn’t work and from the response I can see it is trying to resolve it in the Internet and not locally.
However from within the hassio-dns container the same local hostnames do resolve. So dig pdu3.netality.co.uk works, but dig pdu3.netality.co.uk @172.30.32.3 doesn’t.
I tried killing coredns within hassio-dns which causes a new one to start up and magically local names start to resolve in homeassistant container (and dig pdu3.netality.co.uk @172.30.32.3 within hassio-dns also works). However after a few minutes it stops working again - it looks to me like an issue with coredns/coredns config within hassio-dns - I raised an issue in that project: https://github.com/home-assistant/plugin-dns/issues/20
Incidently the config for coredns looks like this for me - 192.168.66.1 is my local router/dns, note: it is configured to use Cloudflare (presumably as a fallback, but that doesn’t seem to work properly):
cat /etc/corefile
.:53 {
log
errors
loop
hosts /config/hosts {
fallthrough
}
template ANY AAAA local.hass.io hassio {
rcode NOERROR
}
mdns
forward . dns://192.168.66.1 dns://192.168.66.1 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
}
What kind of router do you use?
In my case, I had a problem which seemed to be triggered by the inability to resolve the domain “updater.home-assistant.io”. This caused a cascade of errors which impeded DNS services for over 20 minutes. Somehow, it fixed itself over that amount of time.
Digging deeper, the domain resolves to two IP addresses: 151.101.1.195 and 151.101.65.195. It turns out the first server was in use and didn’t resolve because it was blacklisted in one of the feeds I use for my local firewall. Once whitelisted, I see no errors. The server is hosted by Fastly in San Francisco and I guess there are several domains on the same address; some are associated with fraudulent activity.
The biggest problem I see is just the lack of information on how to accommodate DNS services with the different configurations of HA. A close second is understanding the expected behavior in the Supervisor GUI. Certainly, knowing how the system is architected would help.
At the moment, I have Debian configured with a static IP using the DNS resolver in a software defined router (pfSense). The router is configured to use a Quad9 resolver for the local DNS resolver instance. The router is configured with the Avahi mDNS/DNS-SD daemon to discover local hosts.
I’ve recently used the Terminal add-on to configure the local DNS address for the HA DNS container using the ha dns command tree. Looking at the logs, everything seems to be working. That said, the assignments are not displayed in the Supervisor Host System GUI. Once again, that’s part of the problem.
I tried to resolve pdu3.netality.co.uk from my router. It doesn’t work; however, netalilty.co.uk does resolve. Is pdu3 on a local non-routable subnet? If so, I think it needs to be pdu3.local, or whatever you use for the local domain.
netality.co.uk is the domain I use locally and the local names resolve fine everywhere else they are used. Yes, the domain also resolves externally but with a much smaller subset of records defined - pdu3 is only resolvable internally.
I’m using a Draytek router which is also doing the internal dns. I tried using dhcp and static settings for ip/gateway/dns - made no difference. But I do see the correct settings everywhere - so setting in HassOS cli I see the settings in supervisor ui in HA, etc. Even the config looks ok in hassio-dns, but I’m not very familiar with coredns. It just doesn’t seem to work and ends up using cloudflare - I’d prefer a simpler setup not using cloudflare at all.
I’m no expert, but I think you might need to add an entry to /etc/hosts to resolve it locally from HA, unless your router has a discovery process for the LAN.
Here’s what the default configuration looks like on HA:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.30.32.2 hassio
172.30.32.2 supervisor
172.30.33.1 core-ssh.local.hass.io core-ssh
Edit: Your router might also have a way to enter local hosts into its DNS resolver. In mine, they’re called Host Overrides.
if you set the DNS server in HA, then HA/coreDNS should use that setting for any and all dns resolutions.
Fact of the matter is that this ain’t always the case.
If his router also handles local dns (quote : “a Draytek router which is also doing the internal dns”), and this is the server configured for name resolution in HA, which it would be given dhcp … then there is no reason what so ever for HA to be querying any other server, specially regarding local hosts.
I agree that’s preferred and it’s working with my system. Figuring out how to do it was the key. Using the GUI didn’t work as I expected. So far, there aren’t any errors in the DNS log, and even the printer and the Kodi host on my LAN have been recognized. Still, if there’s no discovery mechanism or way for a router to properly register and resolve the host name, editing the HA host file might be the only option short of getting a new router.
Enough folks are having DNS issues to be concerned, but I suspect some of the system behaviors we’re seeing are a fallout of trying to make HA more robust (I still see DNS-over-TLS requests to Cloudflare).
Setting your preferred dns is done with :
ha dns options --servers dns://IP_ADDRESS
ha dns restart
After this, things used to work just fine, then they brought in coreDNS.
Now things are bwoken.
What is coreDNS? My DNS in HA is not broken and I did add my own DNS with the command you referenced because HA didn’t seem to like my router doing DNS over TLS but that was months ago…
http://letmegooglethat.com/?q=coredns
Are you using local hostnames in your network or ip addressing ?
They added a new docker container called hassio-dns that is used as the dns resolver (IP 172.30.32.3), inside that it uses coredns to implement the resolver. It is supposed to use the dns server set for HA, but there are issues with this - in my case it doesn’t appear to work at all - all local hostnames referenced in configuration.yaml fail to resolve, so I’m, forced to use IP addresses. hassio-dns is configured to fallback to using cloudflare but in my case it seems to be always using cloudflare instead of my local dns server.
1 Like
Some things could be broken, e.g. I don’t know why the Host System GUI doesn’t show current IP assignments (it’s a Supervised installation). With the exception of the Cloudflare activity, the bits are flowing as expected. I can resolve and ping my iPhone and printer with their local hostnames using Terminal.
I do have other issues unrelated to DNS, but my system works.
I’m happy it works for you.
For me - dns used to always work, since the appearance of coreDNS it regularly doesn’t resolve local hostnames because coredns is falling back to some dns outside of my lan. (How the hek is that even a cool thing to implement ?!?)
Again: this is the only thing in my network that has local hostname resolution issues, yet everything is using the same dns.
I guess I should feel lucky not to be in @quad 's position, where local dns never works…
Anyway, devs know about it , and have explicitly told me to step away from HAOS if I don’t like the dns system. The Docker container was the advised installation method.
Can ya tell i’m slowly getting frustrated by this ?
Ah ok. I have that dns server as well. It seems to be working. You could add your router dns server in the options before cloudflare and then it should use that.