-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
|
I would love to see as well support for an internal |
|
This feature will easily customize the DNS of the home server , just use tailscale 😀
|
|
0debb99 added client support for a new ExtraRecords field. It's not yet supported server-side. |
|
Sorry to be this person, but: Any news on this @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:
We're leaning towards shipping this soon but with a bunch of limitations to start like:
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. |
|
@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. |
|
|
Thanks, I didn't mean to push, merely hoping to learn of your plans with this feature. |
|
@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: |
|
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 |
|
I'm currently have jobs on my machine's that get my If tailscale's dns supported arbitrary records, I could cut out the ddns middle man since tailscale already has records pointing to my nodes. |
…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>
|
My use case: 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. |
|
My use case would be that I have multiple services running on a server that is in my Tailscale network, and then I can make aliases to them that are only internally accessible like for example the tailscale IP of my server is 100.86.67.57, and I have a website running on port 3001 now it this scenario I want it to be accessible through h.lan from any device in my tailnet, so I would need an SRV record and an A record or a mixture of them like with Cloudflare zero trust tunnels. |
|
This recent blog post might be of interest for those wanting to add specific docker services directly to a tailnet (complete with their own MagicDNS names): |
|
I have a specific use case for this: I have some machines that are on a local Preferably we could do this without running an additional service on the user's machine to provide DNS. So it would be useful if I can give a 'hosts file' to the Tailscale API that is then cached and resolved locally over MagicDNS |
|
My case is simple, I want to use the custom DNS settings to configure my SMTP server to use the MagicDNS domain. |
|
From our perspective, we have apps running on these servers that have a certain domain for SSL (e.g.,
Sorry if this use case was mentioned already |
|
my use case is: my friend and I are developing an open source project and we have local k8s clusters running inside our machines via kind. we have manually set some A DNS records inside /etc/hosts in our machines to access each other's clusters through my personal tailnet using domains. i'd like to have a private DNS zone inside my tailnet to automatically set those records in our machines (and keep them in sync as a source of truth) |
This helps with the fact that I can't specify custom DNS records inside of my Tailnet ([ref](tailscale/tailscale#1543)), allowing me to access "local" services without sending all my DNS traffic through the Tailnet.
|
Use case: Easy access to SSL-enabled Synology DiskStation without opening ports or configuring a subnet router. This is a viable alternative to the Synology QuickConnect solution.
|
This comment has been minimized.
This comment has been minimized.
|
I would love this. My use case is simple: I only want all subdomains of |
|
+1. Reverse proxy on Unraid, I would love to use tailnet URLs and completely get rid of public DNS records with custom domain. Tailscale is awesome and so close to completely solving this problem, missing this one feature. Thanks! |
|
+1. I would like Tailscale MagicDNS to enable something like having |
|
+1 would like to run a reverse proxy with service names instead of using port numbers. Some services also insist on being behind https and is the missing link which would allow that natively in tailscale |
|
For anyone who is looking for a solution right now, here is a docker compose stack which I'm using to run an adguard home DNS instance in my tailnet. I run this stack on the same physical device as my main server (a different docker compose stack), which is also running a tailscale container in sidecar mode - despite being on the same hardware, these appear as two distinct devices with their own IP address in the tailnet. I give my dns device the IP address services:
adguardhome:
container_name: adguardhome
image: adguard/adguardhome
network_mode: service:tailscale-dns
restart: unless-stopped
volumes:
- ../../data/dns/adguardhome/conf:/opt/adguardhome/conf
- ../../data/dns/adguardhome/work:/opt/adguardhome/work
profiles:
- dns
depends_on:
- tailscale-dns
tailscale-dns:
container_name: tailscale-dns
image: tailscale/tailscale:stable
volumes:
- ../../data/dns/tailscale:/var/lib
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
env_file:
- .env
- .env.local
command: tailscaled
privileged: true
restart: unless-stopped
profiles:
- dns
networks:
- dns
networks:
dns:
name: dnsIn the .env file, I only have these variables set: |
Caddy proxy approachMy currently solution for those DNS is setup a local proxy that forward **.fbi.com into correct machine and localservices. And access local network services by Example
a example Caddyfile for reference: (same config for every hosts) {
servers {
trusted_proxies static 0.0.0.0/0
}
}
# route fbi internal
https://127.0.0.1, https://localhost {
tls internal
redir https://fbi.com
}
https://fbi.com {
tls internal
reverse_proxy http://fbi.com {
header_up Host fbi.com
}
}
# forward HTTPS -> HTTP
https://*.fbi.com {
tls internal
@proxyhostport header_regexp subdomains Host (.+?).fbi.com
reverse_proxy @proxyhostport http://fbi.com {
header_up Host {re.subdomains.1}.fbi.com
}
}
http://*.fbi.com {
respond 502
}
# ====================================================
# hosts
# route to hosts
https://*.host1.fbi.com {
tls internal
@proxyhostport header_regexp service Host (.+?).host1.fbi.com
reverse_proxy @proxyhostport http://host1 {
header_up Host {re.service.1}.fbi.com
}
}
https://*.host2.fbi.com {
tls internal
@proxyhostport header_regexp service Host (.+?).host2.fbi.com
reverse_proxy @proxyhostport http://host2 {
header_up Host {re.service.1}.fbi.com
}
}
https://*.host3.fbi.com {
tls internal
@proxyhostport header_regexp service Host (.+?).host3.fbi.com
reverse_proxy @proxyhostport http://host3 {
header_up Host {re.service.1}.fbi.com
}
}
# ==================================================
# services
# route to services
http://vscode.fbi.com {
# hack: fix xfh for code
@xfh header_regexp xfh X-Forwarded-Host (.*)
reverse_proxy @xfh :8000 {
header_up X-Forwarded-Host {re.xfh.1}
}
reverse_proxy :8000
}
# activitywatch
http://activitywatch.fbi.com {
reverse_proxy :5600
}
# alias
http://aw.fbi.com {
reverse_proxy :5600 {
header_up Host localhost
}
}
# everything
http://everything.fbi.com {
reverse_proxy :2489
}
# alias
http://et.fbi.com {
reverse_proxy :2489
}
activitywatch on localhost activitywatch on host1 activitywatch on host2
extendBtw you could also expose this network into public by forwarding into Hopefully someone could enjoy this (bad) idea. references |
|
Guys, those are really nice WORKAROUNDS, but the idea here is to request Tailscale to implement a solution that would not require from us to make such a workarounds and greatly simplify the process. |
The fact that whoever owns fbi.com directed it at 127.0.0.1 is funny, but it is a really bad idea to rely on a domain you don’t control and which you can’t issue anything more than locally-trusted certificates for. That will not give you HTTPS worth the name and is not a setup I’d recommend to anyone, especially someone setting up Tailscale and so presumably interested in a solid security posture. This setup is just begging for the admin to not actually distribute that locally-trusted Caddy root to the hosts that will access these services and instead have users just regularly click through the HTTPS not trusted prompts, intentionally or otherwise, which in turn is just asking for whoever owns fbi.com to change their A record and MitM you. Don’t try to get clever with security unless you are really sure about what you’re doing. It is so easy to get wrong. Tailscale team: If you needed more justification for why this feature is important than the hundreds of votes here, this should be it. This is complex enough that people are going to get it wrong in subtle but important ways and end up with insecure setups, and we’re well past the “people copying configurations around without fully understanding them” stage here. |
|
is there any fundamental blocker to this? i noticed the TODO here: tailscale/ipn/ipnlocal/local.go Line 2994 in 6edf357
My two cents is this: |
|
The use case for resolving tags is tracked in #4324. |
|
This would be great short even for workarounds. Because tailscale uses ULA addressing for IPv6, validating resolvers will not resolve domains because of potential dns rebinding attacks. Short of migrating the entire tailscale addressing scheme, it would be ideal to have this. |
|
For anyone needing these custom record, wouldn't TSDProxy solve the issue? It was advertised in Tailscale November newsletter. @almeidapaulopt , what do you think ? |
|
Your link points to the wrong page https://almeidapaulopt.github.io/tsdproxy/ Also from what I understand tsdproxy only works for containers. It does help somewhat since I won't need to create a seperate tailscale container for each service. |
this will change soon. you'll be able to add services that aren't running in docker |
|
I need custom SRV and TXT records for my use case. As far as I can see tsdproxy won't be able to help with that? |
|
@madscientist16 thanks for the flag on the link, fixed! |
It would be much better to handle this outside of a specific niche project, and allow for more flexible domaining and analytics |
|
Sure. I'm mostly flagging a community-based workaround until Tailscale
supports it :) A few useful aspects of tailscale started that way -- for
example the Synology packages were a third party work originally, until
Tailscale had the bandwidth to handle it and take it over.
|


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.
The text was updated successfully, but these errors were encountered: