Hello, QQ on the 100./8 CIDR block that TailScale allocates. Why this public /8 instead of RFC1918 space? Or making this a configurable item? I’m concerned about data leakage should someone get crafty with static DNS names.
Thanks, Brian
Tailscale support: See https://tailscale.com/kb/1015/100.x-addresses
We’ll be adding support for letting you customize the range in the future. (Or even to use IPv6)
Could you elaborate on your DNS concerns?
Tailscale user: My concern is I don’t really have any option right now to deal with DNS names other than to use public resolvers for my “internal” IPs.
I have Macs, so no beta build with Magic DNS (really looking forward to this btw). I can set a DNS server in Tailscale, 8.8.8.8 for example, but then I need to have a public A record pointing “hostname --> 100.1.2.3.”
This will resolve and route traffic regardless of whether I’m actually connected to Tailscale. If a host drops the VPN connection for any reason the DNS pointer is still valid.
There may be a slight disconnect delay, perhaps another DNS lookup etc, but eventually I’d be routing traffic over the Internet to whomever happens to own the 100.x IP my DNS record points to (assuming the vpn didn’t reconnect). This is where using 1918 space saves the day as nothing will (shouldn’t anyhow…) route 1918 over the Internet.
Tailscale support: In practice, the CGNAT range is as dead routing-wise as the 1918 range. A few mobile carriers in Europe use it for their users. But the only way it’d route is if the machine initiating the connection were, say, tethered to Vodaphone or whoever.
But if you’re only connecting to, say, RDP or SSH or HTTPS servers on your 100.x.y.z CGNAT IPs, then there’s little harm if the packets go to, say, a random other Vodaphone subscriber, as they wouldn’t be able to prove they were the right server.
But for unencrypted HTTP, etc, then that’s a valid concern. Just pretty unlikely. But that’s why we’d like to add IPv6 support too, and grab a ULA prefix that you can use instead of the 100.x.y.z.