Hi team, I’m newish to #tailscale but I think there is a race/bug in the logic that configures DNS for tailscale on the AXT-18000 as I get random configuration when I cycle tailscale enable/disable from the Gl-Inet console interface - /usr/bin/gl_tailscale
The symptom is that sometimes the DNS domain is just ‘ts.net’ and at other times it is the proper MagicDNS tailnet name (tailXXXXX.ts.net).
This is ok for split DNS, but it also drives the search domains, for which plain ts.net is not useful for me.
I believe this is a race condition caused by that script calling
/etc/init.d/tailscale restart # this takes some time to restart
timeout 10 tailscale up –timeout 3 # sometimes the –timeout is triggered,
tailscale status … | grep MagicDNSSuffix # then results is blank if tailscale is not up, and falls back to ‘ts.net’
(My hack workaround is just to make the –timeout 8 instead of 3, which seems to work reliably enough)
Hi
This appears to be a tailscale related issue, as both --timeout 3 and tailscale status --json are handled by the tailscale application.
You might consider installing jq and using tailscale status --json | jq -r '.MagicDNSSuffix | select(.!="ts.net")' to retrieve the result instead of grep.
Hi Will, thanks for replying
I did some more testing
Line 226 of /usr/bin/gl_tailscale (this is the GL inet script that drives the tailcale application)
timeout 10 /usr/sbin/tailscale up --reset --accept-routes $param --timeout 3s --accept-dns=false > /dev/null
tailscale is properly abandoning after 3 seconds and continues coming up in the background.
But it is not enough time, because lline 91 of the gl script is called immediately afterwards to extract the suffix (and yes does use jsonfilter)
dns_suffix=$(timeout 2 tailscale status -json | jsonfilter -e '@.MagicDNSSuffix')
If tailscale has not finished coming up when that is called we get the unwanted ts.net fallback
Changing the --timeout 3s to --timeout 8s resolves it by just giving tailscale more time to come up.
You might want to consider making this change in a future update, it should be safe since that tailscale up statement is called within the timeout 10anyway .
Thank you for your report.
Could you let us know what issues will arise when using ts.net as a fallback instead of the full MagicDNS tailaxxxxx.ts.net?
We tested this locally and it appears both can correctly resolve DNS names for devices in the Tailscale network.
tailaxxxxx.ts.net:
ts.net as a fallback:
Yes, the fallback for the ‘server’ entry is fine.
However the fallback suffix is also used for the ‘domain’ entry in DNSmasq - which is passed on to clients of the router via DHCP as the search domains for unqualified host names. If you are on a client of the router (rather than the router itself)
nslookup gl-be9300 should be trying to look for gl-be9300.tail*****.ts.net but instead will look for gl-b3930.ts.net which does not exist.
Unfortunately there is no good fallback for the domain entry. The domain being wrong is no different to it not being there at all.
I still think the simple resolution is to give tailscale more time to come up.
Thank you for your clarification.
We have forwarded this issue to our R&D team for consideration in future version updates.
1 Like
