FR: Support custom records in MagicDNS

[darshinimashar]

Also, for DNS, the Customer would really like to make DNS aliases such as example.ourdomain.beta.tailscale.net always point to a machine name staging-1 or something like that.

This way, they can easily access the machines.

Front conversations

[guidoiaquinti]

I would love to see as well support for an internal .tailscale domain name (example: nas.tailscale, pi.tailscale) and maybe even subzones (example: nas.home.tailscale VS nas.office.tailscale) without the need of a dedicated/external DNS server.

[MingSpace]

This feature will easily customize the DNS of the home server , just use tailscale 😀

I would love to see as well support for an internal .tailscale domain name (example: nas.tailscale, pi.tailscale) and maybe even subzones (example: nas.home.tailscale VS nas.office.tailscale) without the need of a dedicated/external DNS server.

[bradfitz]

0debb99 added client support for a new ExtraRecords field. It's not yet supported server-side.

[awoimbee]

Sorry to be this person, but: Any news on this @bradfitz ? It's awkward that it has been partially implemented for 7 months.
This would simplify the process described here #1748 (comment) quite a bit by removing the need to host a DNS server.

[bradfitz]

It's awkward that it has been partially implemented for 7 months.

Well, it was "partially implemented" because we needed the part we implemented (and now use) for the LetsEncrypt support.

Exposing more of it for this has a ton of product & security considerations and interacts often surprisingly with various DNS stacks on different platforms, which will increase our support burden if we ship something that seems to work sometimes but not on all platforms in all configs.

Example of problems:

• if you add a foo.net record, we need to make sure your OS queries the 100.100.100.100 resolver for that record. But some OSes only let us route *.foo.net to us, which means what do we do with bar.foo.net? We'd have to forward that on upstream, but some OSes don't make it easy or possible for us to figure out what the system's underlying/native DNS servers are. So then we'd require you specify an upstream DNS server in your Tailnet config, which we're trying to move away from so we can enable MagicDNS on by default.
• if you add a foo.tailnet-name.ts.net record, what if foo already exists as a machine name on the tailnet? what if foo comes into existence later? does that reserve foo for you? do we permit ACME challenges for foo? what if its IP is changed later? which node can then do the ACME challenge?
• if you add a record pointing at the IP of a node and share that node, does the extra record get shared to other tailnets? (not for now, but that's a possible use case people might want later)

We're leaning towards shipping this soon but with a bunch of limitations to start like:

• no *.ts.net
• no *.tailscale.net
• must have DNS servers set with force override (unfortunate for now, but makes things consistent)

Then we probably won't box ourselves into a corner and have to remove functionality later and can add more of this when other parts are ready.

The real problem here is that this feature means a number of things to different people and we have to make sure we don't try to do all of it at once, poorly.

[Tener]

@bradfitz any news about the release date for the limited version of this feature? Having Tailscale-integrated DNS is a great feature, but a little bit of flexibility would be very welcome.

[DentonGentry]

• I promise we will update this bug when something is close to being ready
• polling for updates is not useful

[Tener]

Thanks, I didn't mean to push, merely hoping to learn of your plans with this feature.

[mpl]

@DentonGentry Hello. I understand the meaning of the P2 and T0 labels, but I'm not sure I get the L1 one. Does it describe the likelihood of the issue to get fixed? oh, or does it give an indication of the number of other issues similar to this one?

And I have a question about the feature itself that would address this issue:
Do you envision that there will be a public API for adding DNS entries (which means it could be done with the CLI maybe), or will the feature be limited to the admin web interface?

[DentonGentry]

It is an estimate of the number of sites which would use this feature request. Given the number of 👍 since the label was applied, I changed the assessment.

I expect an initial way to make the functionality available will be a new field in the policy JSON in https://login.tailscale.com/admin/acls. There is an API for that: https://github.com/tailscale/tailscale/blob/main/api.md#tailnet-acl-post

[hybras]

I'm currently have jobs on my machine's that get my tailscale ip and set dns records with my dynamic dns provider. I then have CNAMEs to these records. I get https certificates using let's encrypt's DNS challenge because these services are only available from my network / tailscale. This works beautifully though it was a pain to figure out.

If tailscale's dns supported arbitrary records, I could cut out the ddns middle man since tailscale already has records pointing to my nodes.

[schmiman]

Following, this would really help our tailscale adoption.

[danjl1100]

Just thinking out loud for the "means many things to different people" aspect notes above, a possible minimal first step is to only allow subdomains for an existing host on the tailnet.

E.g.
For a host assigned: foo.tailnet-name.ts.net

You could configure specific subdomains underneath that host:

sub1.foo.tailnet-name.ts.net
sub2.foo.tailnet-name.ts.net

Unclear how big of a leap *.foo.tailnet-name.ts.net would be (technically/security-wise) but just a distinct list of subdomains per machine would be a good starting point.
To me, having higher level subdomains sub-higher.tailnet-name.ts.net doesn't need to be in the initial offering.

[FiloSottile]

As an interesting prior art to look at, there's dnscrypt_proxy's cloaking feature, which is what I am using at the moment and that I'd hope to replace with this. https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Cloaking

[kai-tub]

Sorry for piling on, but I tried to get my local server up and running with DNSCrypt + tailscale and failed miserably.
I felt the blog post from tailscale The Sisyphean Task Of DNS Client Config on Linux and fought so loooong with systemd-resolved/Networkmanager/DNScrypt etc. that I gave up and looked for an alternative.
One that is offically integrated with tailscale is NextDNS, which also supports this feature. There it is called "Rewrites" under the "Settings" menu.
That takes about 30min to set up and you are potentially saving yourself many frustrating evenings. 😅

The main drawback of this approach is: You cannot get proper HTTPS support for the tailscale subdomains, as MagicDNS will kill off trying to access any subdomains...
I would like to have at least the option to query the next DNS server in line (NextDNS) that would point right back to the original. But I am very new to DNS and automatic certificate generation, so maybe there is a good reason not to do it.

Hope it helps someone :)

[artis3n]

Hope it is not obnoxious to specify a use case for this I don't really see yet described in the comments - I'd love to register subdomains of a host in my tailnet as @danjl1100 describes above to basically solve https://caddy.community/t/the-subfolder-problem-or-why-cant-i-reverse-proxy-my-app-into-a-subfolder/8575 when following the pattern from https://tailscale.com/kb/1166/vscode-ipad/ for other purposes (in my case, making HashiCorp Vault run inside a tailnet with more than one thing running on that host).

I want magicdns cert generation to fail unless I have a host configured at some domain - but be able to add at least a few subdomain aliases to each host.

[casidiablo]

I also tried using NextDNS integration to solve the subdomain issue, and failed miserably.

In the nextdns context: why can't we use that as the resolver for everything and then fall back to use 100.100.100.100 for tailnet domains?

[trollybusman]

Here is how I solved a similar issue using a service kind of like NextDNS, it required additional software but it runs seamlessly in the background.

1. Get Control D's proxy daemon: https://github.com/Control-D-Inc/ctrld
2. Use a config like this:

[upstream.0]
    bootstrap_ip = "76.76.2.11"
    endpoint = "https://dns.controld.com/REDACTED"
    name = "Control D - Main org"
    timeout = 2000
    type = "doh"

[upstream.1]
    endpoint = "100.100.100.100"
    name = "Tailscale"
    timeout = 2000
    type = "legacy"

[network.0]
    cidrs = ["0.0.0.0/0"]
    name = "Network 0"
	
[listener.0]
    ip = "127.0.0.1"
    port = 53
    restricted = false

[listener.0.policy]
    name = "Internal domains"
    rules = [
		{"*.int.company.com" = ["upstream.1"]},
		{"*.ts.net" = ["upstream.1"]},
    ]

3. Start the above in service mode: ctrld start --config /path/to/config

All internal domains get routed to Tailscale DNS, while everything else uses my Control D resolver. If issue #7946 gets done, can probably skip using the software.

[nhumrich]

Just adding my two cents in case it helps. I would like this feature. My use case is I want multiple dns records to point to a single machine, basically, aliases for machines. The reason is, I have a single machine that is hosting multiple things. I can use a reverse proxy such as caddy to proxy to different apps based on domain. Without this feature, I have to use public cnames, or host my own internal dns server.

[ndlarsen]

Just adding my two cents in case it helps. I would like this feature. My use case is I want multiple dns records to point to a single machine, basically, aliases for machines. The reason is, I have a single machine that is hosting multiple things. I can use a reverse proxy such as caddy to proxy to different apps based on domain. Without this feature, I have to use public cnames, or host my own internal dns server.

My usecase is similar. Running an nginx based reverse proxy with SSL termination in front of multiple containerized applications including vaultwarden. I would like to be able to reach e.g. the vaultwarden instance via the reverse proxy on the same domain regardless of being connected to the tailscale based network or the actual network containing the proxy.

I guess alternatively one could set up subnet routing allowing access to a DNS on the physical network, disable MagicDNS and add the local DNS as as custom DNS under nameservers configuration. The only two downsides of this I currently see, while there might be more, is that one would be loosing the functionality MagicDNS provides as well as allowing access to the physical network which one may or may not want. As an upside, one would not need to maintain the DNS entries manually in the tailscale config, though.

So, yeah, +1 for this feature. A simple list of dnsmasq style entries would probably solve it from my perspective.

[pw-64]

My usecase:
Traefik container serves the other containers in the docker-compose through containerName.myserver.address. So this makes it really easy so I don't have to remember ports. I can just go to dashy.myserver.localhost and it works great (localhost while testing, going to have a pihole running soon so I can use a dns thing because it is not possible to do http://containerName.myserver.IP_address/). However, since I can only access http://tailscale_device_name/ from another device over tailscale, I cannot go to the subdomains such as http://dashy.tailscale_device_name/. I have a very basic understanding of networking but it is definitely my weakest area, although I have read this whole page and I think people are looking for something similar to this. Please correct me if I am wrong, as I would really like to understand how this all works and if it is possible with the current technology.

[aviadkray]

my use case:
I have an EKS cluster and I have created a TS_router pod in it. I want to make it so the cluster's API is only accessible from the internal network via the TS_router. I create the EKSs with unique CIDRs, but the "server" address in the kube config, are all under the same domain. For example:
cluster1: https://C991AD720C997160FC5F384158692152.gr7.ap-south-1.eks.amazonaws.com
cluster2: https://3896D0F8BB8331A0EDFE6618FCB19304.gr7.ap-south-1.eks.amazonaws.com
I would like to be able to set the resolver for the specific hosts in the domain, however I can only set one resolver for the entire domain. This makes no sense when there is more then one cluster in the same region.

Thank you.

[dcopso]

I would also like to see wildcard DNS support for tailnet hostnames.

My use case: I'm using Minio (S3-compatible server commonly used in dev environments) and without wildcard DNS support on the tailnet hostname it is very awkward to use the Minio API in a way that is compatible with S3 clients. We need the bucket name to be the leftmost component of the tailnet hostname, and it would be a real PITA to run our own DNS servers to do this. TLS termination on wildcard names is not important in this use case.

Thanks.

[9at8]

As an alternative/workaround, here's what I'm doing:

• VM on azure that I use to obtain certs. (you can use a cheap VM or forward port 80 to your machine to grab certs)
  • In order to perform ACME, you will need to add an A entry to this machine's public IP
• Install pi.hole on a machine that will act as a nameserver
  • Add this device to your tailnet
  • Add this device as your tailnet's nameserver (using the tailscale IP address)
• Use pi.hole to add local DNS records, pointing to whatever tailscale IP address you want to point to
• You can now use custom records!

However, this can get very tedious/error-prone to maintain in the long run, so having Tailscale do the magic would be nice.

My setup as an example:

• VM on azure is fetching certs for service1.home.9at8.dev, service2.home.9at8.dev, service3.home.9at8.dev using ACME/certbot.
• On my homeserver, I am grabbing certs from the VM.
• My homeserver is on the tailnet, let's say its IP address is 100.x.y.z.
• My homeserver also runs pi.hole and all the other services (service1, service2, service3) behind a reverse proxy.
• For my pihole config, I have created CNAME records from service1.home.9at8.dev, service2.home.9at8.dev, and service3.home.9at8.dev pointing to tailscale-ip.home.9at8.dev, along with an A record for tailscale-ip.home.9at8.dev pointing to 100.x.y.z.
• On the admin console in tailscale, under the DNS tab, I added a nameserver with the IP address 100.x.y.z (pihole) and split DNS with home.9at8.dev.
  • In other words, *.home.9at8.dev and home.9at8.dev will be resolved by my homeserver when on the tailnet. If not on tailnet, then it will be resolved by the domain name provider (pointing to the azure VM that does ACME and gets certs)

[jzila]

I wrote a detailed use case in the above duplicate, but this is a potentially valuable feature for the "progressive adoption" strategy that Tailscale recommends, where you start with a subnet router and then progressively install clients on more endpoints behind the subnet router. Since the Split DNS feature is a way to empower subnet routers, and it prevents resolving to tailnet IPs, a custom DNS solution would give a potential override hierarchy for such a progressive adoption approach.

[distantorigin]

My use case:
I would like to be able to alias certain machines with multiple names, so Caddy/Nginx can reverse proxy to them. For example, https://bitwarden, https://minio, etc, would all map back to the same Tailscale IP while on the tailnet. This functionality became of interest to me when trying to do a three-way split DNS--bitwarden.mydomain.com points to a public IP when not on my LAN. While connected to my LAN it points to the internal address at 192.168.xxx.xxx, and when connected to Tailscale it points to the Tailscale IP (otherwise users not on my LAN wouldn't be able to access it--I'm not interested in advertising the LAN IPs as routes).

I run Pi-Hole on the LAN for DNS. To address not being able to have custom records in MagicDNS, I'm currently using a Pi-Hole image in docker that is paired with the Tailscale docker image to host a TS-only Pi-Hole instance as a machine in my Tailnet. One might argue that I could easily use Dnsmasq and forward onto the LAN-based Pi-Hole as upstream, but that's beyond the scope of this comment.

I would love to see custom records for MagicDNS for this reason--it would remove overhead and a lot of friction from my personal infrastructure.