Log in to your HAOS host,
issue a docker ps to list all containers,
verify that you have one named hassio_dns ,
log into that container : docker exec -it hassio_dns /bin/bash ,
the file is here : /usr/share/tempio/corefile
bash-5.1# cat /usr/share/tempio/corefile
.:53 {
log {{ if not .debug }}{
class error
}{{ end }}
errors
loop
{{ if .debug }}debug{{ end }}
hosts /config/hosts {
fallthrough
}
template ANY AAAA local.hass.io hassio {
rcode NOERROR
}
mdns
forward . {{ join " " .servers }} {{ if len .locals | eq 0 }}dns://127.0.0.11{{ else }}{{ join " " .locals }}{{ end }} dns://127.0.0.1:5553 {
except local.hass.io
policy sequential
health_check 1m
}
# fallback REFUSED,SERVFAIL,NXDOMAIN . dns://127.0.0.1:5553
cache 600
}
.:5553 {
log {{ if not .debug }}{
class error
}{{ end }}
errors
{{ if .debug }}debug{{ end }}
forward . tls://1.1.1.1 tls://1.0.0.1 {
tls_servername cloudflare-dns.com
except local.hass.io
health_check 5m
}
cache 600
}
That’s my edited corefile, I commented out the fallback line.
thank you so much for this. I read the thread you linked (I also replied to it), and in this post@McGiverGim suggests to add the local domain to this part:
template ANY AAAA local.hass.io hassio {
rcode NOERROR
}
You opted instead to comment the fallback. Is there a specific reason? Adding local domain didn’t work?
I applied both modifications: unfortunately, I noticed that on reboot of the host, the corefile gets reverted to its default configuration, so not only after an update.
I tried adding local …it didn’t work , there’s also excludes in the corefile …adding local to there didn’t work either.
Basically, i tested adding local where-ever it made sense to me, and waited a while (after doing `ha dns restart``) , it never solved the problem.
Finally, and out of frustration, I removed the fallback line, knowing this isn’t any kind of proper workaround - certainly it isn’t a solution. In fact this potentially breaks it even more than it already is…
But frustration won the battle, and I know DNS works for my usage case, until host is restarted. Which doesn’t happen very often.
Another round of updates and another round of fighting with CoreDNS to get thigns to load and run properly. And then, once I do get it load up using my local DNS entries, for 10 minutes every hour I lose DNS as it seems CoreDNS has decided to bypass my local DNS entries and go straight to CloudFlare. Which fills my logs with lovely connection and mysql errors.
The github issue that was opened for it has devolved into a mess where one guy spends his time yelling at the HA devs for not caring and not doing anything and the HA devs chiming in to suspend the yelling guy but no comment on the issue other than “if you know of a fix, please work on it” which doesn’t seem to be going anywhere. The temporary workarounds posted there either don’t always work or are at best temporary. Wiped out the next time you restart or reboot or update.
At this junction I’m still having trouble wrapping my head around what the CoreDNS module does that providing our own DNS via DHCP doesn’t. Whatever it does, there HAS to be a better method to accomplish it that doesn’t punish users for having local DNS entries.
Have a guess where requests to 1.1.1.1 or 1.0.0.1 will get routed to by your router.
Only thing you could do is add very specific forwarding rules, so that requests from HA to cloudflare DNS would get redirected to your own dns on your lan.
We just need a way to permanently disable/configure any fallback or forwarding for DNS.
One could wonder why any networking setting would be hardcoded…but hey, ours is not to reason why but to do and die.
I have had the same issue as many have described here. I’m quite amazed that the situation is like it is. To me it would be a basic assumption that any device would agree to use the set or DHCP provided DNS. This is maniac!
The local network integrations didn’t work with my local names. I was able to get them working by pointing to the IP address rather than the name. However, I would prefer names over IP addresses but that seems to be tricky.
We make the decisions we do because with Home Assistant OS we are offering a solutions to users that works, for users that want to focus on about home automation, not system administration.
…
If you’re interested in doing DNS stuff, probably Home Assistant OS is not for you. Consider using a Supervised or Container installation.
Except, if you use Supervised it’ll break your install periodically because there’s no way to stop it auto-updating, which is also apparently for the benefit of users, despite breaking things left-right-and-centre: How to stop supervisor auto-update? - #18 by john-arvid
The whole thing is a false dichotomoy anyway - you can have the “user friendly” default of using fallback DNS, and auto-updating and still have a config option to disable it.
I get that there are design decisions that have to be made, but it really is quite frustrating when your home automation won’t remain stable because of those decisions - bugs happen, but you expect they’ll be fixed at some point.
So, this is still broke, and apparently won’t get fixed. Heard that it is so that people who don’t do system administration can… checks notes… use a system that involves configuration and automation of several systems. Huh.
Well anyway, I would imagine if there are any people out there that are willing to do some network administration, you can probably make a rule in your firewall that redirects all port 53 (DNS) traffic to your chosen local DNS server and call it a day.
Edit: Even this doesn’t work. I have configured and tested NAT rules that intercept DNS, and DNSSEC (443 and 853). I have hardcoded the name into the hosts file. Nothing will allow me to use a local server for DNS resolution. HA wants to use 1.0.0.1:853 or 1.1.1.1:853 regardless, and won’t resolve local hostnames.
Wow, glad to hear that I’m not the only one with this ridiculous issue. I’ve tried both suggested edits to the corefile (followed by ha dns restart) but unfortunately neither worked. The dumb ways they often handle things at the container level will be the death of me. I can achieve short-name resolution at the host level (and throughout my entire network) but not in the container since it’s looking for a DNS suffix of “.local.hass.io” rather than my Edgerouter-4’s DNS of “.router.home” and doesn’t have the decency to ask my router. Specifying FQDN works at both levels with nslookup/ping but f that, I’m not using FQDNs in my config when it should be working properly with short names. The only way I could think to solve this based on what everyone’s tried so far is to set up a WINS Server in docker to auto-resolve with short names in another domain - but even if that’s possible and happens to work, that’s beyond stupid for a multitude of reasons. Hopefully the devs can wake up and fix this instead of defending such a mediocre implementation.
EDIT: I was able to change the line “fallback REFUSED,SERVFAIL,NXDOMAIN . dns://127.0.0.1:5553” and swapped out the “127.0.0.1:5553” with my router’s IP and specified Port 53 rather than 5553 and that seemed to give me full short name resolution across the board but of course that doesn’t survive a host reboot. If I can script this then it would suffice for a dirty workaround. - Nvm, that doesn’t work either. Resolves the name but still adds the .local.hass.io suffix. Ugh.
Hey all, I’m Mike Degatano. For anyone that watched the release party of 2022.3 you saw me on the stream, I was announced as Nabu Casa’s new hire focusing on supervisor. I have been working on this exact issue and was wondering if anyone facing this would be willing to try the beta channel. I have put in two changes that should help with this that are available there right now:
MDNS to Systemd Resolved - essentially the DNS plugin is no longer attempting to resolve MDNS and LLMNR names itself. Instead it simply asks the native systemd-resolved service to do that for us. This should ensure .local names work properly, as long as the host can resolve the name then we can too.
Cloudflare as a fallback only and no healthcheck - I changed up the corefile to remove Cloudflare from the list of forwarding servers. Instead it is only used as a fallback. This should keep it from getting “stuck” on cloudflare like a lot of you all have been seeing. Where it moves on from your listed local DNS servers after hitting issues and gets the idea that only the Cloudflare one works. It will always keep trying your local DNS servers first. And it no longer healthchecks Cloudflare at all to prevent runaway healthchecks when Cloudflare is blocked like some of you had reported in issues.
I’m not done here, there’s a few more changes to put in. But I thought those two might help you all from what I’ve been reading. So if any of you would be willing to give the beta a try and let me know if your experience is better or if there’s still issues to address I would really appreciate it.
Yes, that puts the whole install on the beta channel which means it will install the current supervisor beta. Sorry, there’s no way to only subscribe the one plugin to beta.