no
CoreDNS is glitchy, nothing we can do about it.
The only workaround I’ve found is to install the AdGuard addon.
Luckily I found this thread, so I’m not the only one getting crazy with HA’s DNS lookups.
The strange thing is that it happened all of the sudden, everything was working fine, I had updated more than 1 week ago to latest version, no issues.
Yesterday it started throwing a bunch of errors on a lot of integrations and after some debugging I found out it was the DNS. I tried several configurations reading several posts of people with the same issue. They seem to work for a while, then another ha dns restart is needed, I was thinking to schedule the restart every 10 minutes as a temporary workaround.
In 20 years of system/network administration, I never seen an nslookup like this, it made me smile (to avoid crying):
(I use HassOS on a NUC, axel.dom is my LAN domain, nuki-bridge is the device I was having issues with in HA, this is an SSH from HA container, 10.1.10.1 is my LAN OPNsense router/firewall with unbound as DNS server)
# nslookup nuki-bridge.axel.dom
Server: 10.1.10.1
Address: 10.1.10.1:53
Non-authoritative answer:
*** Can't find nuki-bridge.axel.dom: No answer # (no answer??? WTF? who's not answering?)
Non-authoritative answer: # (it does a second query, to the correct DNS (opnsense)?)
Name: nuki-bridge.axel.dom
Address: 10.1.10.117
# ha dns info
host: 172.30.32.3
locals:
- dns://10.1.10.1
servers:
- dns://10.1.10.1
update_available: false
version: 2021.06.0
version_latest: 2021.06.0
#
Did you really install AdGuard on HA just to forward all the queries to the same DNS already configured via DHCP? 
any special configuration of adguard to solve this internal dns nightmare? I also noticed there’s dnsmasq as addon, lighter and reliable, did someone try it to bypass the problem?
I can do it…but it’s really ridiculous…I wonder why it’s so hard to fix the problem, from what I read, a lot of people are having these issues, and from what I debugged, the design of this is really awful (two queries for a simple lookup). Really a bad thing for a powerful home automation solution like HA. No good.
yup… it worked…until the latest HAOS release. Then, even that twisted workaround stopped working.
For now, I’m using a modified coredns.json - which isn’t a decent solution, because my edits to the file will get wiped when HAOS updates. At least - until update- DNS works.
If only @balloob & @pvizeli would step out of their ivory tower & reconsider their DNS-related decisions… 
My coredns.json looks fine, nonetheless the problem is still there: every once in a while (sometimes 30 minutes, sometimes 10 minutes, looks random), HA won’t resolve hostnames. If I restart with ha dns restart it works, temporarily…it’s incredible that a fundamental service like DNS is being overlooked, with so many people having issues. Even stranger that on github I didn’t find open issues…do they close them immediately?
{
"servers": [
"dns://10.1.10.1"
],
"locals": [
"dns://10.1.10.1"
],
"debug": false
}
Maybe you didn’t look at the correct github. There are issues opened about this: Issues · home-assistant/plugin-dns · GitHub
I looked in core and supervisor. Didn’t even think about the plugin.
Thanks a lot.
I’m sorry, I meant to say that I’m working with an edited /usr/share/tempio/corefile.
Not coredns.json.
I’m running Home Assistant OS, so that file is located inside the hassio_dns docker container.
No problem. Is it too hard to access it? I might do the same if it works, because right now I was almost thinking to scratch the Intel NUC and reinstall HA from zero. 
Thanks for any help.
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.
This is based off of @McGiverGim 's suggestion in this git issue : Not resolving local host names · Issue #20 · home-assistant/plugin-dns (github.com)
Also know that my edit will break DoT (DNS over TLS). I’m not (yet) bothered by that.
1 Like
Hi Tom,
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.
Thanks,
Alessandro
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.
I’ll take a look at coredns documentation to see what’s the appropriate configuration for this use case.
incredible that someone says everything’s (NOT) working as designed…
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.
1 Like
Why nobody ever thinks of using the local dns server from within their own router??
I’m running it like this now from the beginning (almost 2 years), and never fails me.
There is only one downside, for internal i have to use https://home.assistant.url:8123
(since I don’t use hairpin nat)
1 Like
because that doesn’t work… the cloudflare DNS is hardcoded in the HA / CoreDNS configuration :
forward . tls://1.1.1.1 tls://1.0.0.1 {
tls_servername cloudflare-dns.com
except local.hass.io
health_check 5m
}
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.
Tom, probably there’s light at the end of the tunnel: https://github.com/home-assistant/plugin-dns/issues/20#issuecomment-926125086
1 Like
thx for pointing it out !
Fingers crossed.
1 Like
well…those PR’s died a swift death.
1 Like
How is this still an issue?
At the bottom of that PR is a comment by @balloob - Remove hardcoded DNS servers by fenichelar · Pull Request #56 · home-assistant/plugin-dns · GitHub
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.
4 Likes