Skip to content
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

No SERVFAIL and no forwarding multicast names #86

Merged
merged 2 commits into from
Apr 25, 2022
Merged

Conversation

mdegat01
Copy link
Contributor

@mdegat01 mdegat01 commented Apr 21, 2022

Fixes #85 by responding with an NXDOMAIN if a local.hass.io name is not found in our hosts file. We are authoritative on that domain in networks with supervisor and so there's no reason to keep looking if we can't find it.

Additionally fixes #70. When reviewing the SERVFAILS that occurred when an LLMNR name was looked up (single name, no TLD) I realized that generally only bad things happen if we continue looking up multicast names past the MDNS plug-in. Since the MDNS plug-in asks the host for an answer it will get an answer for any multicast names as long as the host has one. And if the host doesn't its unlikely any of the other potential forwarding servers will either. But trying will likely leak private host names to external resolvers.

There is a risk with this. It is possible to add a dns rewrite entry for something like my-server.local in some DNS servers instead of properly using MDNS. This will no longer resolve after this change for users doing this because systemd-resolved also refuses to forward multicast names to other resolvers. But given what we are doing has caused a CVE and I think we should follow systemd-resolved example and stop at the MDNS plugin as well.

Note that if we cannot reach systemd-resolved (can occur only on an unsupported system) then the MDNS plugin continues to pass the request along as normal. It can't answer any queries in this situation so that is the best it can do.

@mdegat01 mdegat01 requested a review from pvizeli April 21, 2022 23:49
@mdegat01 mdegat01 added the bug Something isn't working label Apr 21, 2022
@mdegat01
Copy link
Contributor Author

FYI some more context in the discussion here

@KevinCathcart
Copy link

It is worth mentioning this only fixes #70 for dotless domains and .local domains.

If somebody types in a fully qualified local domain name, (such as my device.home.arpa, or device.attlocal.net, or device.mshome.net), and their local dns server is down, we could still leak those domains to cloudflare. But the only way to avoid that would be an option to disable fallback.
This is because other than home.arpa, none of those other suffixes are special, so they should not be handled specially by general purpose dns servers, so even running a recursive resolver would leak final hostnames, albeit only to the nameservers for those domains.

But again, it is the best we can possibly do, other than adding an option to disable fallback, or things like letting users specify a blacklist of domains not allowed to fallback.

@mdegat01
Copy link
Contributor Author

@KevinCathcart fair point. Fortunately I'm was already working on that 😄
home-assistant/supervisor#3586

@pvizeli pvizeli merged commit 8e0ea74 into master Apr 25, 2022
@delete-merged-branch delete-merged-branch bot deleted the nxdomain-not-servfail branch April 25, 2022 07:51
@agners
Copy link
Member

agners commented Apr 25, 2022

This is because other than home.arpa, none of those other suffixes are special, so they should not be handled specially by general purpose dns servers, so even running a recursive resolver would leak final hostnames, albeit only to the nameservers for those domains.

There is a list of reserved top-level domains in RFC2606. There have been attempts to extend the list with commonly used (currently not assigned) top level domains. Since those are invalid at the top level, I think it would be quite reasonable to add those to our list as well.

@mdegat01
Copy link
Contributor Author

mdegat01 commented Apr 25, 2022

@agners I see your point but that gets tricky. The problem with other reserved TLDs is they require a local DNS server. Like we do need to send those to some resolver its just ideally we should only be sending them to an internal resolver, not an external one.

And unfortunately with those I can't just make a statement like "if the host can't resolve them then no one can". Because the user has a way to add a DNS server just to HA and override the DHCP provided one. Which means it is entirely possible HA can resolve a name with one of those other special TLDs and the host's systemd-resolved can't.

In order to satisfy that request I believe we'd need to identify which resolvers were internal and which were external and only forward requests with those TLDs to internal ones. Which would be a lot more complicated because to my knowledge coredns has no way to do that, you just make a list of resolvers to forward to. Or we offload all DNS work to systemd-resolved (not just MDNS and LLMNR) but Pascal said that created other issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cla-signed
Projects
None yet
5 participants