Name resolution problem since 0.97.2

Hi Frenck, just a heads up, once the local dns server is setup, at the moment the local hostnames must be fully qualified.

My router is setup with the domaine name: home

Before in my configuration i had short hostnames, like cam-living, but that doesn’t work with the custom DNS in hassio.
I changed it to FQDN: cam-living.home and it works.

It’s ok to change the config, i don’t have much hosts, but IMHO it should work with short names too (like everything else on my network).

Thanks for the quick fix anyway !

2 Likes

This might be down to the fact that the machine calls itself local.hass.io so it will assume everything is in that domain. My DHCP server sets up every device to have the correct public domain .house, I use split horizon DNS on my network. This works for even the simplest device such as my Tradfri gateway which can be pinged by the simple name tradfri from any device with a command line except HA :wink:

The fact that esphome devices need to be told which domain to use and ignore the DHCP settings is an interesting theme…

Possible to add a search directive to coredns?

Hmm, interesting.

I use .home too and go out of my way to kill off avahi / bonjour and it’s persistence of .local

Taking a look at my configuration.yaml, and (by luck?) everything uses my .home prefix, so all is well.

I’d like to raise a feature request to capture some of the views expressed here… but I’m not sure how that’s done around here… forum? Github?

Wow, what a rabbit hole I’ve been down in the last 24 hours. I started to see DNS failures after I installed AppDaemon, saw the core-dns addon and blamed AppDaemon for installing this.

After posting about my experiences, I was referred to this thread, and the solution in #43.

It’s annoying, and I share the frustrations of others, but luckily we have some pretty smart people contributing to this project. Sadly, however, there seems to be some bleed between the beta channel and the stable channel. This should have been caught in the beta. However, I guess there aren’t enough folks running the beta.

I’m still a newbie getting to grips with HA’s architecture, but once I have, I promise to switch to the beta channel to help out where I can.

Gareth

1 Like

I’ll throw my vote into this thread for changing the auto-update of the supervisor to a manual only update.

I really despise auto-updates on anything. And for exactly the reasons that this thread (and even more pointedly, especially the other one referenced by @Guff666 above) exists.

I guess I don’t have any idea why it was decided that the supervisor needed to be auto-updated when nothing else in HA is?

Maybe if that question could be answered it would at least help people understand why it was done. If there is no good answer then maybe that wasn’t the correct decision to make.

Whatever the reason, picking a random TLD and using that, is really a bad idea in general.
There are RFC’s for that.

Yes, internally Hass.io started to use *.local.hass.io, to not interfere with your own local setup, stick to RFC’s and following up recommendations from e.g., Microsoft.

As a result of that, fqdn’s must be used (which you should actually always do… .:man_shrugging:) .

It has been answered a lot of times. For the future it might change, but it takes quite a bit to ensure that works correctly.

Basically, the supervisor needs to be in the future compared to other system parts at this point. (really sort simple version, but yeah).

Sorry, I guess I’ve never seen those lots of times.

However, since the supervisor is what people use to update their hassio couldn’t there be a notification that in order to update hassio/add-ons that the supervisor has to be updated first? Then the “update” button(s) could be disabled until the supervisor has been updated.

At least then people wouldn’t have to deal with potentially broken things without knowing why because of an auto-update.

I for one am not using a random TLD, I bought a .house domain and I use split horizon DNS so that hassio.mydomin.house resolves to an internal address when devices are inside and a public IP when elsewhere, it’s simple and RFC compliant to the best of my knowledge. Microsoft do not recommend using .local for Active Directory, it should be for example ad.mycompany.com, no user of this system owns or has access to hass.io, you shouldn’t be forcing the system to be using it in my opinion, it should use our own preferred local domains set via DHCP or manually - even if that is a .local one :wink:

2 Likes

@finity I personally agree, as said, that requires work, so maybe in the future. Feel free to help out on that.

@bucksbass Yep! I was commenting on the use of .home there.

As said before, the 180 release was to get rid of initial and unrecoverable issues. We hope to start work on getting information from the host NetworkManager via DBus soon, so we can get DHCP information to enrich the DNS configuration.

1 Like

I would if I knew how to do that kind of coding. Alas, I’m not knowledgeable at all in that.

And honestly I’m not even sure what “that” even is… :laughing:

I assume it’s python?

Hi,
for any reasons my issues still exists. I’m on Supervisor Visor 180. I already downgraded to 173 and everything works again for a few minutes, until the Autoupdate to 180.

the CLI shows me this.

24

I’m confused. Should the first DNS not 9.9.9.9 because of Quad9?!?!

Did the update went correct?
Please help

FYI: In case anyone else runs into it, Home assistant started to fail to connect to MariaDB on bootup, since the host values were set to homeassistant for me and for some reason Maria was receiving the hostname as core-samba.local.hass.io, so I got a bunch of errors similar to:

2019-08-18 16:41:11 ERROR (Recorder) [homeassistant.components.recorder] Error during connection setup: (MySQLdb._exceptions.OperationalError) (1130, "Host 'core-samba.local.hass.io' is not allowed to connect to this MariaDB server")
(Background on this error at: http://sqlalche.me/e/e3q8) (retrying in 3 seconds)

I switched the host to % to resolve it for now since I would assume the hostname will change with the fixes/changes that are happening related to DNS (don’t know why it’s showing up as the samba container and not homeassistant).

//TB

Version 181 fixed the IP connection issue. Thanks a lot.
MariaDB still not working with old settings. I will try @docBliny changes

With 181 my installation off hass.io on raspi does work again including all my addons:
Log Viewer
Node-RED
SSH & Web Terminal
TasmoAdmin
zigbee2mqtt

Thanks a lot!

But no logs or anything else useful. This is not a place to simply say it doesn’t work.

I am on .97.2 181 with this same issue where hassio doesn’t resolve any local DNS addresses. I tried the "hassio dns options --servers dns://<local_dns_ip> and it set but didn’t make a difference

I do see this in the System Log:

19-08-19 01:17:06 WARNING (MainThread) [hassio.dns] Can't write local resolv: [Errno 13] Permission denied: '/etc/resolv.conf'

Any other suggestions?

It doesn’t seem to be able to ping short names now, you have to ping FQDN after adding your local dns server and restarting the dns service. More info here https://github.com/home-assistant/hassio/issues/1231

–nevermind- reverted back to plain HA