New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not resolving local host names #20
Comments
|
Was doing a bit more poking around in hassio-dns - I tried killing the coredns process (which caused a new one to be started) - it then started to work: But then after a few minutes it stops working again. So seems like something odd going on with coredns. |
|
/etc/corefile |
|
Similar to #6 ? |
|
It didn't feel the same when I raised the issue, but now I can see it could be the same issue. In my case local names do not seem to resolve at all - when Hass starts, all hostname entries in configuration.yaml fail to load with resolve errors. But perhaps something else fails to resolve and it flips to the fallback before processing configuration.yaml? Coredns shouldn't flip to permanently use the fallback - that is plainly broken behaviour. #6 says it was fixed some time ago - but as you said and I see it appears it isn't. I don't understand this comment under this ticket: It doesn't seem like too much to ask to for HA to use the specified local dns resolver and it seems like a lot of people have been affected by this for a long time. Also having hardcoded fallback server IPs that can't be changed doesn't seem right. Perhaps a better solution would at least allow the default fallback server to be overridden in HA and ideally, optionally disabled completely. |
|
I'm also using the default HAOS. TLDR : HAOS is the only service that has recurring dns issues in my multi-VM home setup. coreDNS is broken, dev can't/won't fix. |
|
I don't see the point of even having the option to set the name server in HA, if it doesn't work and it doesn't use it. It's also very misleading to instead use another entirely different, undocumented name server and I don't really want another random company to see my (supposedly internal to my network) dns lookups. |
|
I think I have found something; |
|
So I tried removing dns://127.0.0.1:5553 from the first forward line in /etc/corefile and restarted coredns. I then changed all my IP addresses to hostnames in configuration.yaml and then restarted home assistant and success - all the hostnames now resolve fine. However if I restart the host my changes will get overwritten again. So seems like the /usr/share/corefile.tempio file in plugin-dns would need changing to implement this properly: |
|
Just chiming in here to say that I'm running in to the same problems on my home network, and I found this issue once I got down in to the coredns container's config (I didn't know exactly where to look for issues before getting that deep in). I agree with everything posted here so far, and am surprised there isn't more activity here - I imagine lots of HA users have their setup communicating with local devices via internal hostnames. My local network uses a subdomain from a real internet zone, not a fake TLD or the mDNS .local zone (e.g. lan.example.com) I have not yet looked in to how the main HA config makes its way into the coredns config, but if we could have an option to entirely disable the use of 3rd party DoT that really seems desirable. One of the reasons I use HA vs. another system is that I thought it left me in control of my data, and now this update has started sending DNS requests for my local resources to a third party DoT server without my knowing or wanting that to occur. I run my own local recursors and authoritative DNS for those resources, and would prefer HA use those systems which I control. @ssummer and @Zixim I'm happy to help debug or provide more info for my setup, and dig into making some test PRs and the like (but I haven't done any dev/contribution to the HA codebases in the past). Edit: Changed DoH references to DoT, as the coredns config is using |
|
I found another problem which I think may actually be the root cause of this issue. I noticed that I still actually see all the requests for my local resources hitting my local DNS server, but all responses are coming back SERVFAIL (DNS level failure) - it seem that coredns is requiring DNSSEC signed records from local resolvers. I performed a packet capture while running the following queries for my local PurpleAir device, from the HassIO host (via the HACP ssh/terminal addon) to demonstrate.
This causes a query to hit my local DNS server like so, as decoded with Wireshark: And the corresponding response, which in my case is a SERVFAIL because my local DNS server does have DNSSEc signed records available for my local zone (which I suspect is the case for most users with local DNS from their home routers/etc!) Note near the bottom within the OPT record, the
I can stimulate the same response if I force the DO flag to be set with dig(1) and specify my local DNS server explicitly:
The same request/response is observed in this case. I'll show the dig output here (the wireshark decoded results are essentially the same): Now, I can verify the same request works without the
From what I can tell, the CoreDNS configuration as currently defined will cause any local queries which return SERVFAIL to immediately retry at the external DNS over TLS server (e.g. Cloudflare) due to this bit of configuration in the
This is probably a violation of the EDNS0 RFC (a SHOULD statement in it, at least) (https://tools.ietf.org/html/rfc2671#section-5.3):
It is not clear to me how one configured CoreDNS to not set the To further verify this, I suppose I'll setup DNSSec for my internal zones and see if that "fixes" it, too. |
|
Once upgrading my local zones to support DNSSEC, this issue does go away for me, at least somewhat validating my analysis above. But I still want to emphasize this is important to fix, as most users will probably not have DNSSEC signed local DNS in their local home networks. New dig results after enabling DNSSSEC for my Direct query to my DNS server demonstrating new DNSSEC support ( Query to local DNS resolver (coredns / plugin-dns) with explicit dnssec requested, and returned properly ( Query to local DNS resolver (coredns / plugin-dns) without explicit dnssec requested (no |
I feel like I mis-explained : the bug-report I opened about this whole coreDNS mess was closed by the dev, after a kind of won't fix remark. Perhaps you could start from scratch with a new bug-report, we might get lucky, with 2020 being behind us now. I wrote "_it's open source, and you can always issue a pull request _" because that's a typical answer users get from devs, when the dev feels like the users are asking too much. It hasn't happened (yet) in this case, but the way in which the dev acknowledged the bug & told me to use another installation method sure did taste like that. |
|
@Zixim Agreed, I actually followed you there, but was trying to be an open minded as possible in my first post about this :D Is there a chat server folks hang out on we could discuss this further, without flooding GH issue threads? |
|
@maiko29 your issue absolutely does not sound like any kind of DNS issue. |
|
Sorry, I don't understand exactly all of this (my knowledge about networking or linux is limited) but I think I have the same problem commented here. My local device names are not being resolved. They were some weeks ago, but I don't know when this changed. My router acts as DNS, and is assigned by DHCP to all the devices, including the raspberry pi with Home Assistant, and things like Something I can do/help with to fix this? |
|
If it helps... the nslookup resolves the name, but it throws an error: As you can see, the address is finding the correct IP (192.168.100.20 in this case), but it throws an NXDOMAIN error later that produces that this IP is not used. |
|
My understanding of this problem is HA requires a DNSSEC lookup. My router does not support that so I had to add & configure the AdGuard Home addon for HA to use for its secure DNS lookups. I could not find any other way... |
Don't think so. No developer wants to fix this glaring security bug, so we should try to get the feature request voted up : |
|
I’ve found a workaround modifying the coredns template… I don’t know if this can have some drawbacks, but it seems to work and I have not found any problem until now. In the plugin-dns/rootfs/usr/share/tempio/corefile Lines 11 to 13 in b3827bb
adding my local domain (piminet) at the end: In this way it returns If this solution is ok, maybe some real Home Assistant developer can add a new option to the |
|
on next update, your edits will get wiped out |
|
I know. This is the reason why I ask to include it in the base by a real Home Assistant developer, if the solution is acceptable and does not break other things. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
not solved. Need developer input. |
|
Bumping so this doesn't go stale. Surprised this isn't getting more traction! |
|
It's very likely because the queries are being incorrectly forwarded onto Cloudflare by coredns. I tried to repro the behaviour you're seeing but failed (I added a record to my local server for If you query against Cloudflare, you get an Sounds like you've already got it, but if you install the privileged SSH addon (https://github.com/hassio-addons/addon-ssh) that'll give you access to I would say, though, that I'm using my workaround (and I blocked supervisor auto-updates) so it's quite possible there's a new "base" coredns configuration file floating about. If you want to send me yours I'll try find time to test against that.
In the output there you've got two servers - docker's built in one, and the hassio_dns container, the latter fails.
You'll like this, not a lot, but you'll like this. The Either there's something nuts in the coredns config, or something's changed in |
|
Actually, going back over your screenshots, I think there's two issues being conflated here. You've got DNSSEC turned on for When you first tested, you were getting NXDOMAINs (like me). That'll likely be because your queries were going to CF. Now, they're probably going to your local recursor but responses for Does work from within the homeassistant container? |
|
bash-5.1# cat /etc/corefile |
|
Config looks normal enough. Unfortunately the console log doesn't tell us much. I don't think it'll be this, but just to be safe, can you do on the The fairly wild variation in query response times in the logs suggest the result probably isn't being generated locally. From within that container, if you do does it work? I think we're probably getting into packet capture territory here though - need to try and identify whether it's receiving the SERVFAIL from upstream (based on the response timings, I suspect so) or generating locally. |
|
bash-5.1# cat /config/hosts |
|
OK, so, that tells us it's either In the Then in another terminal run your query (lets do it from the home assistant container). You should see the counter increase in tcpdump. Ctrl-c it If you can copy the capture down and attach it, it's easiest, but failing that Will dump a load of info |
|
Here's the pcap after nslookup windows-11.brunt.limited; nslookup windows-11.brunt.ca from homeassistant: |
|
Unfortunately can't read it from a Or do To get a text dump. |
|
|
Ah-hah! So, what we can see here is
So, we know the Do to confirm that. Looking at the packets themselves: If we decode your query we can see flags etc Looks pretty bog standard. How's the upstream query look? It's added an EDNS record - again, doesn't look too objectionable. So, response packet Nothing really telling there, other than that it's a Flag wise, they're basically identical to my working queries. What's your upstream DNS - is it actually pdns or is that just a coincidental name? Either way, you'll need to check the logs there. If it is |
|
I am running pdns-recursor on port 53 and pdns on port 5300 for my local zones. |
|
Yes. The primary difference between your direct query and the one via Have you ever had DNSSEC enabled for that domain? If so, pdns will have cached the RRs. If you do You could also edit the |
|
I just came back here after troubleshooting numerous pdns options and internet googling. Last article I read was |
|
Excellent! I think to flush the DNSSEC meta cache you want |
|
No, that did not work. I have changed dnssec=off to dnssec=process-no-validate and homeassistant is still able to resolve. |
|
Awesome! |
|
What did you use to obtain this? |
The hex comes from the Take the hex section and trim the indexes off And stick that in the text-area. It'll whinge about lack of ethernet header, but you can then tell it to treat it as an IPv4 packet and the dissectors will kick in. |
|
Thanks! Filing for future reference! |
|
can confirm issue on my side. HA stops using my internal DNS for whatever reasons and try to resolve local hostnames to the hardcoded cloudflare DNS. Unfortunately it does not fall back until i restart HA / dns |
|
Fixed by #82 |
|
Also note that there is a new option to disable the fallback dns added here: home-assistant/supervisor#3586 as I would guess a number of users on here would be interested in that. |
|
Thank you so much Mike. Glad someone in the team finally acknowledged how many issues the old implementation created to many users. I'm not able to test it because I switched to Core, but I'm pretty sure many others will test it and report back. |


















In home assistant, if I use hostnames in configuration.yaml they fail to resolve (eg using platform snmp ). Using the corresponding IP addresses works, but is far from ideal and means I have to use fixed IP addresses and configuration becomes less unreadable and requires more maintenance.
Trying to work out what is the root issue is, has led me to hassio-dns seemingly not working as I would expect. The homeassistant docker container appears to be using 172.30.32.3 for dns which is the hassio-dns container. From within the homeassistant container this local hostname fails to resolve:
dig pdu3.netality.co.uk
and I can see from the dig output it is going out to the Internet to do the DNS lookup.
But
dig pdu3.netality.co.uk @192.168.66.1
from home assistant does work (not surprisingly).
The strange thing is from within the hassio-dns container, fully qualified and unqualified local hostname lookups do work:
dig pdu3.netality.co.uk
dig pdu3
But
dig pdu3.netality.co.uk @172.30.32.3
does not work (unsurprisingly).
What I would expect is that fully qualified and unqualified hostnames should resolve as I have set the search domain to netality.co.uk and dns server to 192.168.66.1 in HassOS.
I don't think this has ever worked with hassio-dns.
Versions:
armhf-hassio-dns:2020.11.0
raspberrypi2-homeassistant:2020.12.1
armhf-hassio-supervisor:latest (2020.12.7)
HassOS: 5.9
The text was updated successfully, but these errors were encountered: