FR: custom domains for magic DNS

[fairplaymvv]

What are you trying to do?

As a user, I'd like to point to a custom domain instead of <domain>.beta.tailscale.net, e.g. foobar.network, where foobar.network is in my or my org's possession.

How should we solve this?

No response

What is the impact of not solving this?

I use the more cludgy domain than the one and I'm going to have to probably figure out my ssh config strategy all over again ¯_(ツ)_/¯

Anything else?

No response

[mayakacz]

Duplicate of https://github.com/tailscale/tailscale/issues/1543

[bradfitz]

I don't think those are quite the same, @mayakacz. #1543 is about adding custom records. This is about BYO MagicDNS domain suffix I think?

[joshuataylor]

Sorry for the necro, but I would love this as well! Tailscale MagicDNS is 🔥 and actually 🪄, but would love to BYO domain for this part: https://tailscale.com/kb/1081/magicdns/#full-domain-names-vs-machine-names

So we replace domain + suffix with say: monitoring.example.com, where example.com would be the host. Probably wise to have third level (monitoring.foobar.example.com, similar to existing?).

My custom domain is shorter, it's not a deal breaker, more of a "this would be nice to have". Love the random name generator tailscale provides. :-)

[dsymonds]

Yes, could this issue be reopened? With MagicDNS going GA today this would make it even more attractive.

[DentonGentry]

In retrospect, not a duplicate of https://github.com/tailscale/tailscale/issues/1543

[viperfx]

Would really love to see this feature. Have a custom domain and would love to use it with sub sub domain support with https for my NAS box.

[talwat]

I would also like this quite a lot.

[hazelement]

+1 on this. I'd like to use the same domain while I'm on tailscale vs on my physical network.

[DentonGentry]

We understand the interest and we use the emoji reactions on the original issue as part of prioritization of what to work on. To express interest, please add a reaction.

I'm going to close the issue for further discussion, as comments expressing concurrence don't get counted so easily (we cannot generate a report of counts from GitHub, for example).

[chrishas35]

To add to the request, when enabling this, I would like to be able to delegate a portion of my existing domain to Tailscale DNS for management. For example, sending *.ts.example.com to 100.100.100.100 (this might need to be a named record, so tailscale may need to publish a public A record for 100.100.100.100?)

[ghost]

Would add to this, as a new potential user to tailscale, this would greatly help us on-board an existing non-tailscale network9s)/domain into tailscale, as with a large organization of nodes and users I need to move things in pieces. Having a .ts.example.com, or even a completely hidden domain name matching my network name like .secured which I can re-direct to the magicDNS from my traditional DNS servers offers a way I can move server/service-by-service into the "secure" domain in a very clean way.

Am surprised this isn't higher priority - ZeroTier offers this and I feel with large organization this is tablestakes - thanks!

[lloydjatkinson]

I also wanted to add that I think neither the randomly generated default name or the selectable “fun” names are great for branding/name recognition/basic security especially for non-technical users (who, don't forget, are at some companies routinely bombarded with "don't click suspicious links" training). Both types of name could be perceived to be suspicious. A well known name, such as organisation name etc would be easier to remember.

wiki.<myorganisation>.ts.net looks better than wiki.tail3fda32.ts.net or wiki.funny-porcupine.ts.net.

[evilhamsterman]

At least for paying companies it would be good to support company.ts.net as a start.

[chrishas35]

While not the first-party solution being asked for here, I did recently see this blog post from @willnorris that sets this up with an external solution. Linking here for other who may be interested in doing a workaround while waiting for this to be supported.

https://willnorris.com/2023/tailscale-custom-domain/

[joshuataylor]

For us, we have a small number of servers (machines) that we want to access over Tailscale, and need to access them with a consistent name.

As IPs are dynamically assigned, the only real way we could do this for our domain was using:

a. The static domain name Tailscale provides, or the silly name that companies love to use (horse-radish.ts.tailscale.com etc). b. Assign a CNAME for foo.example.com to the TS name

However with Machines now being able to be assigned a Static IP, we can just create a A Record for the machines we want to be be able to access with the IP we set in the 100.64.0.0/10 range (you can change this range if you want).

Hopefully this is added to the tailscale CLI at some point so this can be done during tailscale up etc.

[cpressland]

One thing we'd like some conceptual feedback on from Tailscale is what implications building a feature like this would have on customers that have already enabled HTTPS Certificates.

I'm keen to enable HTTPS Certificates so we can use Kubernetes Ingress via the Tailscale Kube Operator, however, if this feature ends up landing thing.bink.ts.net would be far preferable to thing.fun-name.ts.net. The documentation clearly states that once HTTPS Certificates are enabled the tailnet name cannot be changed. So either exceptions would need to be granted by the support team on a request by request basis or this policy would need to be relaxed.

@DentonGentry - could you offer any feedback on if I should just stop worrying and enable HTTPS Certificates or if I'm potentially better to hold off and wait for this feature as this policy would not be relaxed?

[DentonGentry]

could you offer any feedback on if I should just stop worrying and enable HTTPS Certificates or if I'm potentially better to hold off and wait for this feature as this policy would not be relaxed?

This feature is not imminent. Holding off on use of HTTPS certificates would mean holding off for an unknown amount of time. If HTTPS certificates as they exist today solve a problem, I'd suggest using them.

I cannot speak to exactly what the policy regarding would be regarding tailnets which began using HTTP certificates prior to the existence of a feature such as this. The "exceptions would need to be granted by the support team" path would exist.