supervisor: Name resolution problem since 0.97.2

Re-opening / unlocking.

ℹ️ Supervisor 180 has been released

This release addresses a couple of issues & comments:

• Google DNS has been replaced by the privacy-aware Quad9
• Random hostnames no longer resolve to AWS.
• localhost should now work, independent of add-on state.
• Custom DNS is now preferred correctly, CloudFlare & Quad9 are secondary
• Ability added to restart Hass.io DNS to apply settings

ℹ️ All add-ons providing the hassio CLI have been updated with CLI v3.1.0

This version of the CLI adds the hassio dns restart command, connecting to the restarting endpoint added in Supervisor 180.

ℹ️ Setting your own DNS server

This requires both supervisor 180 and the latest add-ons with CLI v3.1.0

• hassio dns options --servers dns://IP_ADDRESS
• hassio dns restart

Thank you all for the feedback, sorry for the trouble 👍

7 hours on a major breakage and no developers?

Be fair. This is an open source project and most users will probably not even notice this change. This might be a “major breakdown” for you, but not generally for the whole HA community. It’s a friday night… give them a chance to look at it. I mean in the end you can still revert to an older snapshot (if you have one). You probably got lots of great shit from this project - for free… that also brings with it, that you don’t have a “3 business hours support” contract. I’m pretty sure, the fact that this has 18 comments already will point the DEVs to this bug and that there will be a fix soon. Just don’t expect it in like 5 minutes after an issue is filed.

@frenck, on behalf of us all, thank you very much for your efforts and quick response on this issue.

7 hours on a major breakage and no developers?

FYI for those running Hass.IO on Ubuntu:

vi /usr/share/hassio/dns/corefile

Change the DNS entries in there. Then do:

docker restart hassio_dns

And then restart HA from the UI. It should come back but will likely be overwritten if the container updates without this being corrected. Thanks to the instructions above for the pointer.

This just nuked the majority of my local devices connected to Home Assistant. It will not resolve anything using a local DNS name, e.g. nodemcu.mynetwork.local. I understand mistakes happen, but this was a horrible idea and implementation.

Ugh. Please put this back. It is breaking my PiHole/local dns.

A future change on that backend is, that we can read the host DNS settings over dbus from NetworkManager and add the local DNS as first server with fallback to others.

You can set a custom DNS server using hassio dns options --server dns://IP_ADDRESS The bug right now, it doesn’t process that request properly, as a workaround a system reboot force the update of the DNS. We are looking into fixing this asap.

And please stop editing generated files manually, that is just bad practice and really not needed.

But why is it ignoring dns servers pushed by DHCP in the first place?

Why is the hassio-supervisor automatically upgraded? I did not request the update to version 181, now my whole system is junk. Half the pages don’t work, system is now super slow. Please ask before auto upgrading. Once again…this is the kind of stuff that made me leave OpenHAB behind and now it seems HA is going to do that same types of things.

mwild 1 - try using a fully qualified domain name rather than just hostnames. Fixed most of mine by doing that.

Shouldn’t be necessary on a properly configured network. All my devices respond to hostname only from a command line apart from within HA.

Initially received a 502 gateway error upon manual attempt to update supervisor via webUI. Rebooted host for good measure and observed update occurred without further intervention. Local name resolution working consistently and as expected since specified name servers are honored sequentially and not randomly.

Thanks for resolving this issue!

I fixed my issue by adding the following automation:

- id: '1578321747819'
  alias: Patch resolv.conf on startup
  description: ''
  trigger:
  - event: start
    platform: homeassistant
  condition: []
  action:
  - service: shell_command.patch_resolv_conf

and by adding the following code to configuration.yaml:

shell_command:
  patch_resolv_conf: 'echo "options ndots:0" >> /etc/resolv.conf'

I’ve locked further comments on this issue right now. A lot of comments have been made, solutions (workarounds) offered. We are aware and working on it. Thanks all for participating 👍

IMHO, the general theme from most people here is:

1. Manual updates - or at least a big neon sign saying the supervisor has changed
2. Manual control. It appears that a lot of people control their DNS, so let’s have a Web GUI place to configure these things.

Seriously I spent several hours trying to figure out what happened. I never even updated hassio and still somehow got the update. Please fix this.

Yeah I assumed that it will be overwritten, its more meant as a temporary a work around. I hope that this gets fixed rather soon.

This is poor behaviour. hassio should honour the DHCP delivered DNS server.

You have rebooted hassio or restarted the dns? and your are on Hypervisor >=181? what is your local prefix? hassio dns info returns? have you tried from the ssh-addon >host xxx.yyy your_router_or_dns_ip

Thanks for helping.

Yes I rebooted hassio multiple times, and I’m on Hypervisor 181.

~ hassio dns info
host: 172.30.32.3
latest_version: "1"
servers:
- dns://192.168.0.1
version: "1"

Now some tests:

~ host ampli
Host ampli.local.hass.io not found: 2(SERVFAIL)
~ host ampli.my.domain
ampli.my.domain has address 192.168.0.24
~ host ampli 192.168.0.1
Using domain server:
Name: 192.168.0.1
Address: 192.168.0.1#53
Aliases:

ampli.local.hass.io has address 172.30.32.1
~ host core-mariadb
core-mariadb.local.hass.io has adderss 172.30.33.0
Host core-mariadb.local.hass.io not found: 2(SERVFAIL)

I’m not quite able to make sense of what’s wrong…

The only search domain (‘search’ in /etc/resolv.conf) defined is local.hass.io. If the host you’re trying to reach is in a different domain, then specifying the FQDN is needed. I’m not certain if this has always been practice (as far as the resolver setup in home-assistant is concerned), but I use FQDNs in practice and not PQDN or simple hostnames, therefore I would not have noticed an issue (in my setup). This issue seems only peripherally connected to what caused this issue’s creation to begin with.

It is curious however that manually adding another domain to /etc/resolv.conf still results in Host hostname.local.hass.io not found: 2(SERVFAIL) and doesn’t seem to be traversing the list of search domains.

👍 Same here. Fixed using hassio dns options --servers dns://x.x.x.x

Doesn’t solve the non FQDN hostnames from my network nor the local resolution of Hassio MariaDB addon for me…

Any hint?

You have rebooted hassio or restarted the dns? and your are on Hypervisor >=181? what is your local prefix? hassio dns info returns? have you tried from the ssh-addon >host xxx.yyy your_router_or_dns_ip

Thanks for the update. Please consider not adding quad9 and cloudflare to the DNS list if we don’t specify them. I understand local DNS is preferred, but after this issue I’ve blocked access on my firewall as my HA is as good as broken without access to my local DNS server.

All I can say is that even though it doesn’t fix resolution from containers it DOES fix esphome devices if you follow the instructions to set the dns using the hassio cli and then restarting the host.

For me that’s a significant win and I can now wait for a more comprehensive solution.

@frenck

Ha, I somehow never noticed the option for a terminal in VSS. Thanks.

@NearlCrews

I get your comment about not manually editing configuration files, but it’s not like there’s a ton of documentation on this or how to correct the issue, especially for the generic host installs. The change was to get it up and running again until the issue is fixed and we’ve got instructions to make it permanent.

The Hass.io CLI is available in the SSH, SSH & Web Terminal, Visual Studio Code and IDE add-ons.

+1 This is awful. I just came across this issue after spending the better part of the last few hours troubleshooting every level of my infrastructure. Please fix / revert. Supplying internal DNS via hassio dns and then rebooting the node does not result in a fix and DNS resolution is intermittent at best.

Editing hassio/dns/corefile manually, deleting the superfluous servers and restart using docker restart hassio_dns solves the issue here, at least for now.