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

Home Assistant OS cannot resolve Tailscale hostnames #310

Closed
david-kalbermatten opened this issue Dec 26, 2023 · 9 comments
Closed

Home Assistant OS cannot resolve Tailscale hostnames #310

david-kalbermatten opened this issue Dec 26, 2023 · 9 comments
Labels
stale There has not been activity on this issue or PR for quite some time.

Comments

@david-kalbermatten
Copy link

david-kalbermatten commented Dec 26, 2023

Problem/Motivation

DNS lookup doesn't work for Tailcale hostnames like machine.weird-name.ts.net. This is inconvenient as I would like to use Tailscale's MagicDNS to reference a remote server for shares and other resources by its hostname which doesn't work with how the Add-On is setup currently.

Expected behavior

If MagicDNS is running, one would expect the Home Assistant OS to be able to resolve Tailscale's MagicDNS.

Actual behavior

When running nslookup machine.weird-name.ts.net in the SSH console of Home Assistant, it cannot resolve the name. However, running the same command after manually inserting the contents of /etc/resolv.conf from the tailscale container into the host's version, works just fine. Doesn't seem to work that way

Steps to reproduce

1. Fresh install of Home Assistant OS
2. Install Tailscale Add-On
3. Install SSH Add-On
4. Try to resolve the domain name from a Tailscale machine like machine.weird-name.ts.net => Doesn't work
5. Copy the contents of /etc/resolv.conf from the docker container of the Tailscale Add-On into the hosts version of the file
6. Try to run the command from step 5 again => Works now

This doesn't seems to have been the case, please refer to the comments further down

Proposed changes

I'm not 100% sure whether this can be done with just a simple config change as the map parameter seems rather restrictive. But ideally, you'd want the Tailscale version of /etc/resolv.conf to overwrite the host's version when running Tailscale in userspace_networking: false using a volume bind.

@david-kalbermatten
Copy link
Author

david-kalbermatten commented Dec 26, 2023

I missed the obvious. You can add 100.100.100.100 and your local DNS in the static IP config for the supervisor and have the DNS resolution work that way.

Still though, this should probably be mentioned in the docs somewhere as this usually isn't necessary on other platforms

@david-kalbermatten
Copy link
Author

Well, that doesn't fix it. Is DNS just fundamentally broken when running Supervised?
Even with everything seemingly correctly setup, the nslookup-requests are not being sent to the correct dns server 100.100.100.100.

~ # ha dns info

fallback: false
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.178.1
- dns://100.100.100.100
mdns: true
servers: []
update_available: false
version: 2023.06.2
version_latest: 2023.06.2

~ # docker exec -it hassio_dns cat /config/coredns.json

{
  "servers": [],
  "locals": [
    "dns://192.168.178.1",
    "dns://100.100.100.100"
  ],
  "fallback": false,
  "debug": false
}

And yet this is what I get when running the commands:

~ # nslookup tower.rhino-snares.ts.net

Server:         172.30.32.3
Address:        172.30.32.3#53

** server can't find tower.rhino-snares.ts.net: NXDOMAIN

~ # nslookup tower.rhino-snares.ts.net 100.100.100.100

Server:         100.100.100.100
Address:        100.100.100.100#53

Name:   tower.rhino-snares.ts.net
Address: 100.68.196.11

Honestly, I'm out of ideas here. In my limited understanding, the secondary DNS server should respond if the first one doesn't know the answer, the second one get's asked, and so on...

@david-kalbermatten
Copy link
Author

It would seem that CoreDNS takes the NXDOMAIN response from the first DNS server and goes "Job done!". So unless I set 100.100.100.100 as the primary DNS server, this setup won't work.

Luckily, Tailscale's MagicDNS can be used as the primary DNS. However, now I run into the problem that the supervisor needs to be restarted after a reboot for the DNS resolution to work correctly as the Tailscale Add-On is started later on in the startup chain. Also, I've only been able to get Tailscale hostname resolution working when using static ip address settings in Home Assistant where the DNS is setup as 100.100.100.100,192.168.178.1.

Trying to use DHCP and run ha dns options --servers=dns://100.100.100.100 and restart, didn't work even though the /usr/share/tempio/corefile seems to suggest that it inserts the servers first and then the locals.

Is there a more elegant way to have Tailscale DNS resolution work on Home Assistant OS?

@lwis
Copy link

lwis commented Feb 4, 2024

@david-kalbermatten did you find a solution to this? The current add-on version doesn't seem to preference MagicDNS in userspace or kernel mode.

@codyc1515
Copy link

Still though, this should probably be mentioned in the docs somewhere as this usually isn't necessary on other platforms

You'd strike the same issue if you were using Tailscale in a container (addon-tailscale) and then expecting it to work in another container (homeassistant / "core") - DNS config does not natively span across multiple containers. Plausibly you could also run two, or more, VPN's and strike the same issue of which to choose.

I agree that this should be mentioned in the documentation as, while it appears to be supported by virtue of it's inclusion in the config area, it does not work out of the box (which is probably preferable).

Copy link

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

@github-actions github-actions bot added the stale There has not been activity on this issue or PR for quite some time. label Mar 20, 2024
@2manyvcos
Copy link

I think this issue is still unresolved.

@david-kalbermatten
Copy link
Author

Yes, but since the Tailscale IPs are static from what I can tell, I have a workable solution at least :/

@github-actions github-actions bot removed the stale There has not been activity on this issue or PR for quite some time. label Mar 21, 2024
Copy link

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

@github-actions github-actions bot added the stale There has not been activity on this issue or PR for quite some time. label Apr 21, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 28, 2024
@github-actions github-actions bot locked and limited conversation to collaborators May 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
stale There has not been activity on this issue or PR for quite some time.
Projects
None yet
Development

No branches or pull requests

4 participants