Hass.io cannot use local DNS names in place of IP addresses in configuration.yaml

I searched through the forum and found this post which sounds very similar to mine but it seems to be specific to the philips hue.

I am re-configuring my network trying to be as “IP-less” as possible – using my local DNS (pihole) servers to resolve all the devices in and around the house and writing rules on my router which are abstracted to use the local DNS names instead of hardcoded IPs. I’d like to do the same thing with Hassio but I’ve realized quickly that nearly all the components configuration.yaml entries require hardcoded IP addresses if you’re not going to use discovery (which I cannot because VLANs).

Recorder - When using DNS in the engine string it fails
“(MySQLdb._exceptions.OperationalError) (2005, “Unknown MySQL server host ‘logger-box’ (-3)”)
(Background on this error at: http://sqlalche.me/e/e3q8)”

Sonos - when I supply the hostnames, I get these warnings and no devices are found. When I use the IP addresses of the devices it works. The autodiscovery doesn’t work, even when I specify the interface_addr option with the hostname of the IP on hass.io that I want it to use. Everything must be IP addresses for it to work on my setup.
image
Chromecast - I’m unable to get the autodiscovery to find my device and I cannot supply a hostname, only a host’s IP address.
image
AsusWrt - using a hostname causes an “invalid config” error.
image
Pi-hole - config docs say it will default to pi.hole but that doesn’t work for me, nor can I force it to the pihole name that I actually use.
image
ZoneMinder - using a hostname here causes an “invalid config” error.
image
Envoy - It states that you can leave the ip_address option off and it’ll default to the envoy hostname which appers to be true but it still cannot find my envoy device (even though I can ping it from my hassio device’s ssh).

I’ve tried names in all the configuration “host” fields and they fail. I’m running hassio on a raspberry pi so it’s dockerized and I wonder if this is the problem. I can ssh into the device and resolve all my local hostnames to IPs (using ping and nslookup) so it seems like it should work but everything gives me errors when I try to use the names instead of IPs.

Thoughts?

I’ve been futzing around with the hassio dns options and I discovered that mine was configured like this:

~ $ hassio dns info
host: 172.30.32.3
latest_version: "1"
locals:
- dns://192.168.0.8
- dns://1.1.1.1
servers:
- dns://8.8.8.8
- dns://1.1.1.1
version: "1"
~ $

The 192.168.0.8 is my pihole server and it should be coming from the DHCP assignment but I wondered if for reason HassOS/hass.io was using hardcoded dns://8.8.8.8 and dns://1.1.1.1 for name resolution. I tried manually setting the values to my pihole server like this:

~ $ hassio dns options --servers dns://192.168.0.8
Command completed successfully.
~ $ hassio dns info
host: 172.30.32.3
latest_version: "1"
locals:
- dns://192.168.0.8
- dns://1.1.1.1
servers:
- dns://192.168.0.8
version: "1"
~ $ hassio dns restart
Processing... Done.

Command completed successfully.
~ $ hassio dns info
host: 172.30.32.3
latest_version: "1"
locals:
- dns://192.168.0.8
- dns://1.1.1.1
servers:
- dns://192.168.0.8
version: "1"
~ $

but that still didn’t solve the problem, removing the IP from envoy and restarting hassio yields this:

I can easily see my envoy device by using its hostname in the hassio ssh window:

~ $ ping envoy
PING envoy (192.168.1.37): 56 data bytes
64 bytes from 192.168.1.37: seq=0 ttl=63 time=1005.991 ms
64 bytes from 192.168.1.37: seq=1 ttl=63 time=7.220 ms
64 bytes from 192.168.1.37: seq=2 ttl=63 time=4.584 ms
^C
--- envoy ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.584/339.265/1005.991 ms
~ $ nslookup envoy
Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   envoy
Address: 192.168.1.37

~ $ nslookup envoy pihole
Server:         pihole
Address:        192.168.0.8#53

Name:   envoy
Address: 192.168.1.37

~ $

What is the meaning of locals vs. servers in the HassOS CLI hassio dns info output?

1 Like

I tried all sorts of terrible hacks in order to try and work around this issue, editing the hosts file does work, as long as your IP addresses stay the same. I wasn’t happy with this solution.

I could never get a proper fix, but if you work out how, let me know. I’ve now had to move over to a Raspbian + VENV and local DNS resolve now, even if the IP addresses change

I have some hostnames configured, but I don’t run hassio. My docker container resolves DNS correctly because it’s something I control.

I use my home router as the DNS server and maintain IP address/host names there. Everything seems to work okay on the HA stuff using host names.
Note: to do that in my router I had to assign static IP addresses to all my computers that HA talks to (including the HA server). On a side note, that is kinda good practice to have static IP addresses for “static” devices anyway.

@Codec303, thank you for the info – it’s annoying that I can’t figure out how to make this work but at least there’s someone else who shares my misery. :slight_smile:

@flamingm0e, good to know you were able to get it solved by creating your own docker container. I’d like to try to stay in the HassOS/hass.io ecosystem, if possible – other than this host name resolution blip it has very good fit and finish and seems like a very good way to easily redeploy if something goes wrong.

@Dixey, I’m currently using Sophos XG Firewall which does not have a very good DNS setup built into it. I’m eventually moving to OPNsense which does. I am using DHCP with static entries so the devices all get the IPs I set for them but the problem, I think, lies with how hass.io/HassOS is configured. With a custom Home Assistant setup you can configure the system behind the scenes to resolve the hosts correctly but using HassOS I’m at the mercy of the way they set up the name resolution and I can’t seem to find any good documentation on what the servers/locals stuff means – not that it seems to matter.

I had the same problem, local DNS names did not resolve in Home Assistant but did from the SSH plugin.

When running the ha dns logs command some errors popped up:

[ERROR] plugins/errors: 2 <device>.local.hass.io. A: plugin/forward: no next plugin found

This leads me to believe that Home Assistant appends its own local domain to DNS queries (pretty normal), but then doesn’t forward the query to the upstream DNS server when it fails.

You could try either of the following to fix this, in case the same thing is happening to you:

  1. Adding a . (single dot) to the DNS name in the configuration.yaml, e.g. “envoy.” instead of “envoy”.
  2. Or, using the full DNS name, this depends on the domain of your network, for me this was .home, so “envoy” would become “envoy.home”.
4 Likes

@SvenDub that was the trick! Thank you so much!!

Hi,

I have the same issue. hostname does not work, hostname. and hostname.fritz.box do work in the terminal addon.

I also see that hostname is translated to hostname.local.hass.io and then fails. Which is not acceptable in my opinion. This works from any other host in my LAN.

Ever since migrating hassio to using my local hostnames instead of fixed IP addresses it appears that hassio doesn’t cache any of the DNS queries. Because of this, my pihole registers roughly 3000 queries per 10 minutes from hassio. My database log is on a network machine and I used the local DNS name in the sql link. Anyway, this makes hassio the most DNS aggressive unit on my network by far. The router is second inline with between 100 and 200 DNS requests per 10 minutes.

Anyone else seeing this behavior?

EDIT: just stumbled across a thread describing very similar results.

EDIT#2 (3/1/2020): by trial and error I determined that the excess traffic was caused by the ZoneMinder integration – for some reason this integration doesn’t cache the IP so it queries the DNS for the name about 4-5 times a second. I’ve flipped that one back to an IP address.

This still seems to be an issue - certainly for me - I did some digging around and found that the issue seems to lie in the hassio-dns docker container which has the IP address 172.30.32.3. This container uses coredns to implement a name resolver and in the config for this it uses cloudflare servers as a fallback, unfortunately the fallback seems to get used in preference to the one specified for HA in many cases.
There was an issue raised in hassio-dns which was supposedly fixed (an issue in coredns) but seems like there is still a problem. I raised a new issue in hassio-dns, perhaps we can get some weight behind this and try and get it resolved:


Stephen
1 Like

see my solution using AdGuard here