MagicDNS is generally available
tailscale.com
tailscale.com
Some advantages that this doesn't look like this would replicate, (1) I can have multiple domains for the same device, say gitea.mytsnetwork.com and netxcloud.mytsnetwork.com can go to the same device (2) I can get real HTTPS certificates for those domains which I consider necessary nowadays if only just to prevent errors (3) it's "real" DNS so when my browser decides to ignore my system settings and use DNS-over-HTTPS instead everything still works.
EDIT: It looks like (2) is solved by the tailscale cert command. I'd replace that point by saying owning the domain is important to controlling the certificate for me. All that said, the more I read into this, this looks like a really well thought-out feature.
I tried setting up caddy on a machine and then using caddy to reverse-proxy requests to each service i.e. `grafana.my-machine.tail-hex.ts.net` and `controller.my-machine.tail-hex.ts`
Obviously, `caddy` has no problem with the reverse proxy bit, but I did fail at being able to point multiple routes or subnet routes at the same machine via tailscle / magic-dns.
I'm sharing because it feels like something I should be able to do, and feel dumb not being able to figure it out.
I have a mix of bare machines and load-balanced workloads behind an nginx-ingress, all with names specified in the dnsmasq config, and because everything on the tailnet resolves names through dnsmasq (and routes through tailscale), everything works beautifully.
I'm still looking forward to this caddy integration, though.
An alternative is to issue wildcard certificates with LE, so that the subdomains names are kept private.
[1] https://crt.sh/
They'll still show up on crt.sh, though, won't they? All my LE subdomains are visible (non-wildcard) but also my non-LE paid-for 1-year wildcard ones are also showing up with all the subdomains.
Edit: Actually, nevermind, those are Cloudflare. My paid-for wildcard doesn't show up. Well, that's a good reason to pay up I guess.
Conversely, if a domain shows up in the CT logs, then there have been certificates issued for those domains, even if there exists a wildcard certificate that is valid for that domain. If that happens, check your settings, because there's probably something requesting certificates you're not aware of.
It's easy enough to set up pi-hole.net on a machine on your LAN and configure your home router to hand out DHCP records that will instruct LAN machines to use it, but if I wanted to have DNS-based ad-blocking at the coffee shop or library or elsewhere I previously had my pi-hole listening on a public IPv4's port 53 and deal with resolve.conf etc... and boy howdy does running an internet-accessible DNS resolver suck! My server would receive millions of requests, weird reflection attacks like [1], probes, the whole nine, it made the dashboarding useless for personal tracking.
But now my pi-hole only listens on my LAN network and its tailnet address, and any machine connected to the tailnet including my phone will use the pi-hole without configuration on any network via MagicDNS.
[1]: https://www.linuxquestions.org/questions/linux-newbie-8/ther...
Very useful and I use it all the time on my mobile devices including my laptop when I'm using guest wifis.
I have been using Tailscale for about two weeks now and I am SOO happy with it. It's genuinely joyful software like I haven't used in years. A modern version of the old Hamachi.
Tailscale feels as magical as Hamachi did.
Just wish they offered more subnet routers. I’m as much hobby as hobby can be, and already hit the limit (one on my mini k8s cluster, one at home, that’s it. They don’t allow you to have more). Been stuffing the sidecar awkwardly into everything to get around it
If someone from tailscale is reading this - please consider upping the limit of subnet routers. I’ll have to switch to ZeroTier once I want another one which doesn’t have those restrictions.
Even paying for the hobby pro plan is just upping it from 1 -> 2
To xena's point, we're not currently enforcing the limits :) We've been very cautious about that since, as I mentioned in a comment elsewhere, the limits have always been an experiment.
Dang now I know what I’ll be doing tonight
We're definitely considering it. We introduced the limits a while back as an experiment. In most cases, I believe the current limits don't make a lot of sense. Fundamentally, we were hoping to encourage the deployment of Tailscale to end devices (partially to increase users' security, partially to get a better idea of how widely Tailscale is actually being used). Unfortunately, the limits introduce the kinds of headaches that you're describing (and for IoT it can be a showstopper). The net effect across all users could be to actually discourage people from having fun and tinkering with Tailscale, which is the last thing we want.
Would you mind describing some of the other use cases you have for subnet routers? Do you have other mini k8s clusters you want to use them for? Other things? I'd love to learn more.
> Fundamentally, we were hoping to encourage the deployment of Tailscale to end devices (partially to increase users' security, partially to get a better idea of how widely Tailscale is actually being used).
that makes sense, I also got the feeling that's the recommended way to run tailscale, and it's nice to be able to address services directly by their dns name
> Would you mind describing some of the other use cases you have for subnet routers? Do you have other mini k8s clusters you want to use them for? Other things? I'd love to learn more.
Yes that's mainly it. I am probably an edge case because I have mini k8s clusters for different things. I have 2 main networks: My network at home, then my main k8s for my personal cloud stuff, those 2 are pretty constant (but want to spin up a separate IoT network soon that may or may not need a router). Then depending on what I work on, I might spin up other k8s clusters
(I'm one of those odballs that really enjoys working with k8s for personal stuff)
I think for me it's mainly to have piece of mind to not run into limitations later on, after I'm already locked in and need to rip-out tailscale to replace with ZeroTier
It's brilliant, and worth paying for.
If you're on Linux, you want systemd-resolved, as it's the only Linux DNS resolver that's really any good, regardless of your opinions on systemd overall (See https://tailscale.com/blog/sisyphean-dns-client-linux/)
In any case, file a bug with details and we'll fix it up if there are still issues.
I want to be prepared if it happens, spent too much time figuring out weird Docker - DNS/network interactions on hotel wifis and the like...
You say "the MagicDNS server" like it's a quad-8 thing out on the internet. That server lives in the tailscale process on localhost. In some configurations on some OSes, we do have to route requests through that in order to polyfill missing OS features (usually, implementing split-DNS policies that the OS cannot represent natively, or transparently upgrading to DoH for upstreams that support it). You can inspect the logic that decides how to implement DNS policy depending on the policy and OS in https://github.com/tailscale/tailscale/tree/main/net/dns, as well as inspect what the in-process DNS forwarder does (extremely boring: match query suffix in configuration, forward packet to appropriate upstreams).
(Personally, have not felt the need to change something that has a great free tier, self hosting controllers, etc, and has been working reliably for years... Tailscale looks cool though)
[1]https://www.zerotier.com/2022/04/11/the-zerotier-dns-story/
Furthermore, you've got ACLs + Tailscale SSH. That means you can start day 1 and do ssh root@rpi1 and it just works. It's amazing and worth so much money.
Edit: I just really wish they would allow more than being tied to Google SSO. I want to invite people outside of my domain easily :o)
It's not just a DNS server, it's everything _around_ the DNS server.
Tailscale value prop as I understand it - they can manage this whole thing for you.
In larger environments we never have any kind of internal web site or service running on one host so we can't really have MagicDNS short names for things. It would be nice for users to just be able to type `https://deploy` to get to our deployment tool for example. But that web interface runs across many nodes behind a load balancer so there is no way to use MagicDNS here.
I wonder if some day we can register duplicate hostnames and have it do DNS load balancing? I'm not sure how that would work with the tailscale cert command either. Each node would need the private key.
Anyway, we'll probably start using it but the only real use cases I see right now are for ssh and for users accessing their remote dev boxes.
That phrasing is a little off. It implies there are situations where your location will affect whether or not you get an IP address. Reading the link makes it clear: it assigns IP addresses that are independent of the device's location. The same device will keep the same IP address even when it moves to another network location, which is not surprising when you are familiar with wireguard configuration.
I don't like the world where every time someone launches a feature on their product they get to top of HN by calling it "generally available".
This is awesome stuff.
It replaces default search domain with its own.
Also it does't keep your DNS servers in your resolv.conf nor tries to forward your query to them when it fails to resolve it.
So, you may experience a loss of connectivity for short hostnames w/o tailscale (host instead of host.my.domain) or get unnecessary overhead for TS-enabled hosts within your local network.
(Some of us have had luck on beatiful DNS notations early)
1. We want you to be able to get HTTPS certs for these too without having to manage multiple names, but HTTPS cert names go on the CT log. See https://tailscale.com/blog/tls-certs/ and https://tailscale.com/kb/1153/enabling-https/ . So having your email address in your DNS name (and thus the CT log) from the old beta.tailscale.net forms isn't great.
2. We want you to be able to have multiple separate tailnets per org/account in the future.
Zerotier has had all of that figured out for years, in the meantime Tailscale just locked the thread requesting multiple connection support as "too heated" (after >2 years of no progress).
And putting access to our corporate networks in the hands of Google & Co. and their trigger-happy account-blocking algos means that TS gets an automatic thumbs down from compliance officers at several of our clients. We can read stories on HN every week why such authentication systems are a bad idea, and steadfastly refusing to roll your own account system (all the while justifying it with handwavy security concerns) just seems lazy to me.
I can follow their arguments to some extent, I just don't understand why the TS people insist on exclusionary features rather than letting the user choose. You believe multiple simultaneous connections are somewhat insecure and that's why you won't implement it? Okay, slap a warning sign on it if you want, by all means, but who cares about this if all I want is to connect to 5 branch offices at the same time.
You believe forcing users to use their private, everyday Google or Github accounts for authentication is safer than using a special account registered on TS with safe, unique credentials not used for any other purpose to minimze collateral damage (if the Google or Github credentials get compromised you'd get their emails or a bit of source code, but not access to the WHOLE corporate network)? How about letting the user choose and show some flexibility to use-cases that exist even if you can't imagine them?
Sorry for the rant, again, I want to love TS, it's UX is pretty neat, but something about their supercilious attitude with which they justify their (non-)features just rubs me the wrong way, I guess.
At the risk of downvotes (because I know TS has - rightfully - many fans), if anyone from TS is reading this, I do implore you to be more open-minded and give your users a choice rather than patronising them on multiple fronts when using your product. Feel free to recommend a "best practice" but understand that many users who might love your product will want and have to use it in a slightly different way than you intended - and that should be okay.
To take the contrarian stance though: SSO not being paid is kinda nice, and not having yet another password for something is nice. —- double and: then not being able to leak a password or handle 2FA, instead focusing on their actual product.
Might mean a little more work to help reimplement GH features in the platform of choice. Not everyone will leave.
But it'll be great for the diversity of the internet.
There are two other options - MS and GitHub (does that only count as one?) - for free users.
I eventually gave up and used Github and it's definitely been worth it for my personal use (a personal laptop accessing a Mac Mini in SF while on vacation, as well as setting up exit nodes on VPSs for getting around geo-restrictions).
I'm a Tailscale customer very reluctantly using their social/SSO login mechanism but to your point, I've already lost access to an earlier Tailscale account due to a screw up (long story) with some changes to the MS corporate account that it was linked to.
I really really dislike forced usage of social/SSO logins and it's one of a couple of reasons I may move away from Tailscale at some point.
Edit: Agree re. fast user switching and connections to multiple networks too - those would be extremely useful
Typically you start some consulting work for an organization, and they hand you an identity to use for the work. They won't use the one you have already or grant access via an ACL. They give you a new id (yes, a new Gmail address even for an 8 week contract, and you're supposed to check it).
So you're consulting for 3 organizations this Q4, and you've been given 3 identities to use for VPN access.
To actually be useful to them in your consultancy work, you need to connect to your own servers during the day as well. Being able to use those is key to what makes you valuable.
Fast user-switching or even simultaneous login would be handy, and having to agree special arrangements with various IT departments is usually a lot of friction. Slow user-switching is what you end up having to do in practice, and that's a pain. I've had this with other VPNs when doing consulting jobs. Re-logging in via slow dialogs to their VPN 20 times a day, due to switching.
I didn't know Tailscale had this restriction until the GP comment, as I have been avoiding Tailscale due to the social-SSO constraint. I was considering, reluctantly, trying it out with my GitHub credential, the one that I think I'm least likely to lose access to. (But consider that all Russian accounts were suspended abruptly this year.) But I do use multiple VPNs to servers under the control of different organizations through the day, so the switching constraint seems relevant too.
It's an order of magnitude less effort and risk to defer auth to third parties via SAML/OAuth/etc. versus owning it yourself with email-based (or whatever) logins. That's it. Nothing more.
For the developer, yeah, not for the user though. But "least-effort development" is not generally that meritorious, especially in this area, and arguably a large part of TS's value proposition is about "less effort and less risk" for the user!
For the user this means more effort and more risk if you consider that you've just multiplied your attack surface by combining internal, privileged access to your network (often without any firewalls or per-device authentication) with whatever other skimpy services you use the credentials for. I know we're all supposed to expect zero trust these days and have all these well-designed enterprise IdP systems in place but the reality is starkly different, especially in the SMB space.
I know that there are a lot of things you can do wrong with auth but a company capable of developing something as complex as a zero-config modern mesh VPN should be able to handle rolling their own auth, come on.
And by the way, it's not like they get the third-party SSO right either: Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data...").
In short, they could really throw some developer hours at this and polish it a bit, roll their own auth (again, can be a tertiary beta option with warning labels at first) etc. This would also leave a good first impression with first time and trial users, and, most importantly, give users an informed choice to leverage the solution that they consider the least effort and least risk for their use case.
Disclaimer, I do work on the project so take me with a pinch of salt.
Development effort is the dominant variable in engineering cost/benefit analysis. What do you think is the cost of what you're asking for? What do you think is the value?
I'd guess the effort is 50-100% relative to all of the auth schemes currently supported combined, and I'd guess the value is maybe one or two orders of magnitude less than the value delivered by those features.
> Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data...").
If this were a common problem, don't you think they would have addressed it? I don't have this experience, for the record.
> they could really throw some developer hours at this and polish it a bit, roll their own auth
I don't think you have a realistic understanding of what you're asking for.
(Side note: setting image.animation_mode = none in Firefox stops the animation.)
https://en.m.wikipedia.org/wiki/Right_of_passage
edit: fixed