sharing: warn users when sharing from a Magic DNS network to a non-Magic DNS network

[rosszurowski]

@apenwarr ran into this in #988, where he tried to share a node with someone and gave them the Magic DNS name rather than the IP address. They tried to access it and it wasn't there, because they didn't have Magic DNS enabled. Missing devices are really hard to debug because you can't tell if Tailscale isn't working, or you just don't have access to the device.

Users should be able to know and understand how to access a device when it is shared with them. We can:

• Warn users when they don't have Magic DNS enabled
• Prompt users to enable Magic DNS
• Show them the IP or hostname at which they can access this device

[crawshaw]

Given our first pass at node sharing doesn't do magicdns names, I'm not sure what there is to do here for v1. Should we warn on the invite accept page that magicdns names won't be available?

[DentonGentry]

Since this bug was filed, though we don't do anything new for sharing from a MagicDNS network to a non-MagicDNS network, we did make sharing between two MagicDNS networks work well. The other tailnet's FQDN appears, "example.com" in this case:

# tailscale status
100.77.226.18   myhost           denny@       linux   -
100.120.55.47   ts-dns.example.com.beta.tailscale.net dgentry@     linux   offline
100.97.254.71   win10            denny@       windows offline

---

I think I'd argue that we don't need to implement special handling for sharing from a MagicDNS tailnet to a non-MagicDNS tailnet. The non-MagicDNS tailnet will be used to using IP addresses, and the IP address of the shared node will work.

[nyghtowl]

Followup with @rosszurowski confirmed its not blocking and may no longer be needed:

"I don’t feel as strongly about it as I did when filing the issue. The situation I wanted to avoid was someone saying “ok, accept this invite and then type my-server/ in your browser” which wouldn’t work because MagicDNS wasn’t turned on. It was around the time where we were talking a lot about Minecraft servers and non-technical users, but I don’t think that’s as important to us these days. And even if it was, there may be better ways of solving that problem. So no, it’s not blocking."

[apenwarr]

For what it's worth, I ran into this myself recently when onboarding some contractors. I feel like I know what I'm doing, but it still take me way too many email back-and-forths to finally remember we needed them to enable MagicDNS on their recipient network. This is especially bad with the new support for LetsEncrypt certs, because without working ts.net MagicDNS lookups, the recipient can't access the https server at all.

It's more of a speedbump than a fatal error, since of course the workaround (enable MagicDNS) is pretty easy.

On Mon, Aug 8, 2022 at 4:16 PM Melanie Warrick @.***> wrote:

Followup with @rosszurowski https://github.com/rosszurowski confirmed its not blocking and may no longer be needed:

"I don’t feel as strongly about it as I did when filing the issue. The situation I wanted to avoid was someone saying “ok, accept this invite and then type my-server/ in your browser” which wouldn’t work because MagicDNS wasn’t turned on. It was around the time where we were talking a lot about Minecraft servers and non-technical users, but I don’t think that’s as important to us these days. And even if it was, there may be better ways of solving that problem. So no, it’s not blocking."

— Reply to this email directly, view it on GitHub https://github.com/tailscale/tailscale/issues/996#issuecomment-1208566815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAFA4CSPTAHLB73GULTM2LVYFTKJANCNFSM4UQZY7FA . You are receiving this because you were mentioned.Message ID: @.***>

-- Avery Pennarun // CEO @ Tailscale

[DentonGentry]

Since the last update to this issue, MagicDNS is now generally available and on by default for new tailnets.

[DentonGentry]

MagicDNS has been generally available and turned on by default for new tailnets since 10/2022. To set expectations: at this point I don't expect to implement features for MagicDNS being off.

Barring further comment, we'll expect to close this during the next regular bug scrub.