[BUG] Turning on Tailscale causes the DHCP domain become wrong and MagicDNS wouldn't work either

Routers
1

I waited for someone to report it but nobody seemed to care!

Before:

  • dhcp.@dnsmasq[0].domain='lan'

After turn on Tailscale:

  • dhcp.@dnsmasq[0].domain='tail000.ts.net lan' -or- 'ts.net lan'

On LuCI
On LuCI720×400 15.9 KB

On Windows

Result:

  • The router sends "tail000.ts.net lan" as option 15 but this option allows only a single domain.
  • This also applies if the client requested option 119 in option 55 of the request. And no matter whether option 119 is requested, option 15 must be a single domain.
    DHCP ACK
  • Therefore, DHCP clients make queries like "hostname.tail000.ts.net lan" which violates the spec
    Queries that violates the spec
  • Both domain query(like "hostname.lan") and MagicDNS would fail

Workaround:

  • To use somedomain for LAN and guestdomain for Guest network:
uci add_list dhcp.lan.dhcp_option='15,somedomain'
uci add_list dhcp.guest.dhcp_option='15,guestdomain'
uci commit

uci add_list dhcp.lan.dhcp_option='15,tail000.ts.net'
uci commit

Solutions:

(From short thoughts)

  1. Give a choice on tailscaleview to keep the domain as is or change to tail000.ts.net
    (Not the best but may an efficient and effective solution)

  2. Change the domain to tail000.ts.net unconditionally
    (May problematic for someone, and actually it's already being problematic due to unable to resolve "hostname.lan")

  3. Keep the domain as is and notify that MagicDNS won't work
    (May inconvenient for someone, but nothing is "more" inconvenient since it never worked anyway)

  4. Keep the domain as is and make the local resolver queries hostname.tail000.ts.net. when hostname.lan. is an NXDOMAIN
    (Doubt it's practically feasible enough)

  5. Send both "tail000.ts.net" and original one by option 119, but still one of 1-4 is needed as fallback
    (Doubt this is too)

2 Likes
2

I can verify this is an actual bug, I just reproduced it on GL-MT3000 4.7.0op24 using a Tailscale version updated by @admon 's script.

The ts.net does not get added to the field in question until the router is logged in to Tailscale. Or in my case, Headscale - I'm using tailscale login --login-server https://my.domain.here on the command line to log in, and connecting to my own Headscale server.

Prior mention: Script: Update Tailscale on (nearly) all devices - #212 by glinoob

1 Like
3

Oh, I didn't knew that someone mentioned it already.

I don't know whether it has been fixed or not, but it's shame that not even a single GL.iNet staff has responded to this very clear and specific bug report, even after your confirmation.

Still, I consider that the GL.iNet devs and suppports are relatively superior in the industry, but I realized that we have to create some own solutions to solve this kind of problems.

Fortunately the fact that we can solve by ourselves is definitely the greatest thing of GL.iNet routers. :sweat_smile:

4

I think (correct me if I'm wrong) @admon needs to fix this issue, since it's his third-party script - GLi support would not be the ones to handle it.

5

This happens in the default state of the stock firmware.

I don't run any unverified third-party scripts until I have inspected myself, and I didn't reviewed nor executed what you mentioned.