I was getting a bunch of whitescreens and slow response from various side panel stuff like the hass.io side panel. This fixed it for me too. Didn’t realise there was a new container hassio_dns.
I don’t know what problem they were trying to fix by introducing it like this but I’m sure they didn’t intend to cause this and will fix it when everyone wakes up…
Howdy,
Just chiming in to report it looks like something in the hassio supervisor.
Running 0.96.5 hassio with HassOS from a OVA.
I was playing with other things when HassOS updated itself. fun times. From what I gather HassOS updates itself and a lot of the file system is read-only preventing you from making other changes to bandaid this problem. i.e. cannot change /usr/share/hassio/dns/corefile. I also tried adding a daemon.json file in /etc/docker on HassOS with dns servers in but this has no effect.
I ended up restoring a few versions from veeam but realised that HassOS will update itself on boot each time 
so there’s not much point doing anything in my situation except wait for an updated release…As HassOS is appears somewhat unmodifiable…
It has broken everything that requires any sort of name resolution outside the HassOS environment and even though I can manually add servers in to the hass.io containers /etc/resolv.conf this borks hass.io as it needs to resolve from the supervisor. For whatever reason hassio/docker? wont look at more than 1 dns server in resolv.conf ??
Before it looked like there was socat running a redirect to from 127/8:53 to hassos on 172.30.32.3:53 but a netstat -ulanp shows nothing listening on 172.30.32.3:53. I guess this is replaced by the coredns container now. I don’t know enough about docker though.
Beers tonight then.
First, docker has had its own DNS issues. Then there’s been the unending stream of users breaking DNS when installing pihole or adguard and not setting static ip/dns on the device running hassio. I’m assuming the intent was to address these. From what I understand CoreDNS is supposed to respect the custom DNS choice. This needs more attention, obviously.
@boojew It is called the “supervisor”, after all… It is the core of hassio and is neither new or a new direction.
Glad I found this thread, I’d already wasted an hour this morning wondering why my system was not resolving to internal addresses having woken up to lights that wouldn’t turn on and other odd issues.
I hope this gets fixed soon.
@HypnoToad : Chromecasts use hardcoded google dns. In order to use the new “cast” fonction by HomeAssistant, the chromecast needs access to my url xxxx.synology.me:8123 and to loopback to my own network, but my router can’t handle this loopback fonction. So i redirected (on my routeur with static routes) 8.8.8.8 & 8.8.4.4 to my server where hassio & pihole are running; Pihole then resolves my outside url xxxx.synology.me:8123 to my local ip adress. Chromecasts, when they can’t reach google dns, then use dhcp dns.
Thanks for this solution. I changed some basic configuration this morning, restarted HASS and suddenly a lot (mqtt, influxdb) was not working anymore in home assistant.
Changing dns settings back to my local dns servers fixed my issue.
Using Home assistant 0.97.2 on Ubuntu 18.04.3 LTS
Installing Dnsmasq and pointing it at my local DNS server seems to have fixed things for me.
Scrub that, just rebooted and that’s broken as well.
Someone mentioned that it’ll overwrite it on a reboot. You’ll have to do the step again until there’s a permanent fix.
The fix hassio dns options --servers dns:// doesn’t work for me, it’s still resolving to an external address. I use a .house domain internally as well as externally, I’m not using .local
Ah so this is the culprit for my HA to load very slowly, to not load my UI, and give me http 500 errors?
I was going bonkers on my setup, it was loading very slow or I had to refresh the view a few times until it loaded up… It seems like the issue is quite intermittent from my side
Ahhhhh…now I understand what’s going on 
I’ve just started playing with some other unrelated addons, rebooted my system and it appeared to have lost all my DNS - of course, I thought it was something I’d done, but it appears:
Now I understand I need to wait for the devs to fix this, then I can go outside and do something more useful instead 
I got the same issue. I was testing Home Asistant for a few days, i works fine. Upgrade to the last version, and the I get DNS issue to join my MQTT server. And I still have the issue with a fresh install of Home Assistant in a VM.
Yes it works. But, overwritten on reboot.
Thanks, I do have a chromecast but haven’t got around to trying the new fancy “cast” feature in HA yet.
I’ve bookmarked this post now so if I ever do give it a try I’ll remember to do the lookback thing to they use the PiHole DNS.
Someone said it but I believe that’s not true. It’s in persistent storage, not in the container. It WILL be re-created if it doesn’t exist though. (with the default settings)
EDIT:
Ok it is most definitely in persistent storage.
From the locked thread on github, as advised by @frenck don’t go editing that file in the dns folder but instead issue this command:
hassio dns options --servers dns://x.x.x.x
Where x.x.x.x is the ipaddress of a DNS server you want to add. Then reboot the device.
That command will add x.x.x.x as a dns server in front of google/cloudflare ones.
One issue this caused for me, because I use Caddy (Reverse Proxy) and my caddy was set to forward to localhost… well none of the dns resolvers have localhost and thus couldn’t be resolved. So I edited caddy to use the ip-address of the NUC instead of localhost and all is now well again.
The fix many have mentioned worked for me until a reboot. What I did was a combination of multiple fixes.
First, issue this command:
hassio dns options --servers dns://x.x.x.x
Then I downgraded the supervisor to the previous working version with this command:
hassio supervisor update --version=173
To prevent the supervisor from auto-updating on reboot, I went into my router and blocked outbound internet traffic for the device’s mac address.
That caused my internet based integrations to fail, so I added firewall rules to allow those particular IP addresses to work.
Everything is working wonderfully now, but it’s only a bandaid.
I’ve done 3 full reboots now and my corefile with the dns server I added via the command has been retained. No idea why you are losing yours. It’s stored in a persistent area of the disk…
That response is genius! Thank you, I just resolved an issue because of this little piece of text. Thanks!
Would the supervisor make use of a hosts file if it existed? (I know, dark-ages networking )
In a normal system, I’d know where to create one and test it, but I just don’t know how to approach this in the Hass IO system