-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Local DNS resolution doeesn't work on macOS with MagicDNS enabled #660
Comments
I encountered some dns issue in Linux and OpenBSD machine, have not dive into these issues, but I think it may be same as yours. |
After read some code, I think I do not have a official tailscale account, maybe someone with official tailscale account could look into the log see how dns config looks like(keyword: If anyone confirm my guess is correct, I'm happy to implement the fix :) |
Oh cool, that you have a hunch so quickly! @huskyii I just checked on a different Linux machine, that should work as well, right? In there I have the following line in the log:
Is that what you are looking for? |
Hi @felixscheinost which version of tailscale r u using? Here's my log, note: no
|
Isn't this related to #280 ? My understanding is that an option for deciding if you want to override the DNS servers, or just use "split-dns" as in adding an extra DNS server to your current network configuration is missing on the headscale side vs tailscale. In some cases you might want to force the DNS servers in the configuration to be the only ones (i.e if you are using another node as an exit node and the node has a DNS server configured and you don't want to leak DNS requests to the outside world), and in other cases you only want to add an extra DNS server to your configuration so that you can resolve the internal tailscale/headscale names. I am not sure of which mode it is the default right now, for example in one of my Ubuntu systems I see:
This system was joined with the following command: tailscale up --exit-node=100.64.0.1 --exit-node-allow-lan-access --login-server=https://vpn.my-private.domain I guess the parameters you use to join the overlay network do also effect the resulting DNS servers in your system, as someone new to tailscale/headscale it would be great to get more details on how this is supposed to work in the documentation. I also have configured 100.64.0.1 as my default DNS server in the headscale config with:
And I am running my own DNS server on that system. systemd-resolve --status is showing 100.100.100.100 as the default DNS server for ~* , but the queries are still being forwarded to 100.64.0.1 (I see them in the log), and as you see it is still keeping 10.83.0.1 as my local dns server for ".local" for my lan. |
@huskyii I think I was using @vquicksilver Yeah, its probably a duplicate of that issue. I tried working around the issuee right now by using the Go |
Okay, I just ran I turned override local DNS on, then off again and watched the log:
|
I don't think headscale has a override_local_DNS option now, maybe we should add one, what confused me is that offical Tailscale KB for maigic DNS stated that
I think it's basically says that to use magic DNS, you need override local DNS. @felixscheinost does magic DNS work if you turn off And could you please also take a look at |
This is incorrect, at least when using MagicDNS sets Override local DNS enabled sets The two settings are independent - however I have no idea how this works in systems pre-resolved. |
@mlincett @huskyii @felixscheinost I think I have added support for this correctly in #905, can you please help me test it? |
Sorry, I just got around to try out the new version. BTW: Awesome that you have a @kradalby If I set |
My config looks like this
|
Output of
So now it seems as if the Tailscale client isn't configuring any DNS settings at all. |
same problem here |
I'm trying out headscale this week and just ran into this problem myself. It seems like the only working options using the official macOS Tailscale client are:
I guess maybe most users are intentionally routing DNS through the overlay network for added security so this is an uncommon issue? My long-term plans for this do involve DNS so if there's not a workaround it's probably fine but was wondering if anyone had discovered anything new on this issue? |
I am currently having the issue that MagicDNS breaks when override_local_dns is set to false (on Linux, Tailscale client v1.48.1). I am not sure if this is exactly the same issue, but at least it seems to be somehow related (and I did not want to open yet another issue for this). MagicDNS only works with override_local_dns=true, but then all DNS queries are obviously sent through the resolvers configured in Headscale, which might not be what you want. A manual Someone also seems to have the same issue since #905 (#905 (comment)). |
Same here. Might have to stop using MagicDNS. |
I am not currently using |
This issue is stale because it has been open for 90 days with no activity. |
This issue was closed because it has been inactive for 14 days since being marked as stale. |
Just tried this and I can also confirm that apparently you really have only two choices with MacOS official tailscale client + headscale currently: You either run ALL your DNS through there or none of it. override_local_dns doesn't seem to be respected, resolver will always try to route through headscale first if you're connected. |
Bug description
When connected to a Headscale server where MagicDNS is enabled, local name resolution doesn't work anymore on macOS.
For example without Tailscale enabled my machine receives DNS configuration via DHCP from my home router.
The home router runs its own DNS server and resolves <router_name> to its own IP address.
Once connected to the Headscale Tailnet, <router_name> can no longer be resolved.
With the official Tailscale coordination server on the other hand there is an explicit option whether local DNS resolution should be overriden or not. If the toggle to override local DNS resolution is turned off, the router name can still be resolved.
So this seems like a bug in how Headscale configures the Tailscale client.
Context info
config.yaml
Output of
scutil --dns
The output of
scutil --dns
looks different when connected to Tailscale vs Headscale.Tailscale
Headscale
=> So it seems with Tailscale my resolver number 1 stays my router, even for the Tailscale namespaces, while with Headscale resolver number 1 is
100.100.100.100
The text was updated successfully, but these errors were encountered: