Skip to content
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

FR: Support custom records in MagicDNS #1543

Open
darshinimashar opened this issue Mar 18, 2021 · 27 comments
Open

FR: Support custom records in MagicDNS #1543

darshinimashar opened this issue Mar 18, 2021 · 27 comments
Labels
fr Feature request L3 Some users Likelihood P2 Aggravating Priority level T0 New feature Issue type

Comments

@darshinimashar
Copy link

darshinimashar commented Mar 18, 2021

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 logo Front conversations

@bradfitz bradfitz changed the title Renaming MagicDNS URLs to. machine name only. Allow adding custom DNS records, including CNAMEs Mar 18, 2021
@DentonGentry DentonGentry added L1 Very few Likelihood P2 Aggravating Priority level T0 New feature Issue type labels May 20, 2021
@guidoiaquinti
Copy link

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
Copy link

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.

@DentonGentry DentonGentry changed the title Allow adding custom DNS records, including CNAMEs Support custom records in MagicDNS Jul 21, 2021
@bradfitz
Copy link
Member

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

@awoimbee
Copy link

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
Copy link
Member

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
Copy link

Tener commented Mar 22, 2022

@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
Copy link
Contributor

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

@Tener
Copy link

Tener commented Mar 22, 2022

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

@mpl
Copy link

mpl commented Jul 1, 2022

@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 DentonGentry added L3 Some users Likelihood and removed L1 Very few Likelihood labels Jul 1, 2022
@DentonGentry
Copy link
Contributor

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
Copy link

hybras commented Jul 18, 2022

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.

@DentonGentry DentonGentry changed the title Support custom records in MagicDNS FR: Support custom records in MagicDNS Aug 5, 2022
@DentonGentry DentonGentry added the fr Feature request label Aug 5, 2022
bradfitz added a commit that referenced this issue Aug 30, 2022
…ap 41]

If ExtraRecords (Hosts) are specified without a corresponding split
DNS route and global DNS is specified, then program the host OS DNS to
use 100.100.100.100 so it can blend in those ExtraRecords.

Updates #1543

Change-Id: If49014a5ecc8e38978ff26e54d1f74fe8dbbb9bc
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz added a commit that referenced this issue Aug 30, 2022
…ap 41]

If ExtraRecords (Hosts) are specified without a corresponding split
DNS route and global DNS is specified, then program the host OS DNS to
use 100.100.100.100 so it can blend in those ExtraRecords.

Updates #1543

Change-Id: If49014a5ecc8e38978ff26e54d1f74fe8dbbb9bc
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz added a commit that referenced this issue Aug 30, 2022
…ap 41]

If ExtraRecords (Hosts) are specified without a corresponding split
DNS route and global DNS is specified, then program the host OS DNS to
use 100.100.100.100 so it can blend in those ExtraRecords.

Updates #1543

Change-Id: If49014a5ecc8e38978ff26e54d1f74fe8dbbb9bc
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
@schmiman
Copy link

Following, this would really help our tailscale adoption.

@danjl1100
Copy link

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
Copy link
Contributor

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
Copy link

kai-tub commented Jan 24, 2023

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
Copy link

artis3n commented Jan 27, 2023

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
Copy link

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
Copy link

trollybusman commented Jun 2, 2023

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"]},
    ]
  1. 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
Copy link

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
Copy link

ndlarsen commented Jun 20, 2023

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
Copy link

pw-64 commented Jun 27, 2023

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
Copy link

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
Copy link

dcopso commented Jul 29, 2023

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.

@nemani

This comment was marked as duplicate.

@9at8
Copy link

9at8 commented Sep 13, 2023

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
Copy link

jzila commented Sep 20, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fr Feature request L3 Some users Likelihood P2 Aggravating Priority level T0 New feature Issue type
Projects
None yet
Development

No branches or pull requests