Add AAAA records to MagicDNS

[danderson]

Part of #19.

Once we can configure IPv6 on the overlay network, MagicDNS should have AAAA records for nodes. There is one minor complication, which is that we should not generate AAAA records for nodes that cannot configure IPv6 (due to lack of OS support), because that'll rely on Happy Eyeballs to make stuff work, and that'll suck.

For that, each node needs to report in its HostInfo whether local v6 configuration is feasible, so that control has enough information to generate MagicDNS entries that match the host's actual capabilities.

The switch shouldn't influence whether we send v6 config to nodes, since we do still want Tailscale itself to be aware of v6 traffic for default route stuff. It should only influence the generation of MagicDNS records.

Not a blocker for base IPv6 support and default routing, but is a blocker for enabling AAAA records in MagicDNS.

[tavianator]

In the meantime is there a convenient way to get the IPv6 address of a peer? It's not listed in tailscale status, https://login.tailscale.com/admin/machines, etc.

[bradfitz]

@tavianator, you could do something like:

$ tailscale status -json | \
     jq -r '.Peer[] | .DNSName + "\t" + .TailAddr' | \
     perl -npe 's/100\.(\d+)\.(\d+)\.(\d+)/sprintf("fd7a:115c:a1e0:ab12:4843:cd96:62%02x:%02x%02x",int($1),int($2),int($3))/e' 

[tavianator]

Thanks! I didn't notice the IPv6 addresses were related to the v4 ones, that makes it easy. Are the v4 addresses unique across all of Tailscale?

[bradfitz]

Currently, yes, but I wouldn't rely on that long term.

[DentonGentry]

Not addressed yet in 1.8.

$ dig -t AAAA node.example.com.beta.tailscale.net @100.100.100.100

; <<>> DiG 9.16.1-Ubuntu <<>> -t AAAA node.example.com.beta.tailscale.net @100.100.100.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40529
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;node.example.com.beta.tailscale.net. IN AAAA

;; Query time: 0 msec
;; SERVER: 100.100.100.100#53(100.100.100.100)
;; WHEN: Thu May 20 14:33:29 PDT 2021
;; MSG SIZE  rcvd: 58

[MDrollette]

Would adding AAAA records only for ephemeral nodes be a feasible intermediate step? Since they only have an ipv6 address, they don't resolve to anything with Magic DNS currently.

[DentonGentry]

Only supporting ephemeral doesn't really simplify things, but there is a way to resolve hostnames to IPv6 Tailnet addresses: tailscale ip -6 hostname

[tavianator]

Would adding AAAA records only for ephemeral nodes be a feasible intermediate step? Since they only have an ipv6 address, they don't resolve to anything with Magic DNS currently.

Looks like 7fe6ecf did this

[bradfitz]

And 22a1a5d for Tailscale 1.16.0 did it more: if a node only has an IPv6 address (as a ephemeral node will), then it note always adds AAAA records for the peers.

[JayWStapleton]

Seeing reports of this in the support queue. HS1735

[DentonGentry]

I think the next step is to begin returning both A and AAAA records to MagicDNS queries.

[bradfitz]

@danderson recently added some host IPv6 probing in c1cb3ef.

If we wanted, we could only conditionally provide AAAA records in MagicDNS if it looks like the host would support it.

[DentonGentry]

I agree that in 1.30 we'll have better information about whether to include AAAA records in the DNS response.

I'd propose to remove this from the blocking list for turning MagicDNS on for new tailnets. I don't think it breaks things for users, it would just be nice to let them use IPv6 in more cases.

---

We handle Tailnets which have set "DisableIPv4": true now, we do return AAAA records for hosts which have no IPv4 Tailscale address.

For example I just set "DisableIPv4": true on a personal tailnet, and MagicDNS now returns AAAA records for all hosts:

root@mc-survival:~# ping mc-creative
PING mc-creative(mc-creative.geekhold.com.beta.tailscale.net (fd7a:115c:a1e0:ab12:4843:cd96:627b:7e36)) 56 data bytes
64 bytes from mc-creative.geekhold.com.beta.tailscale.net (fd7a:115c:a1e0:ab12:4843:cd96:627b:7e36): icmp_seq=1 ttl=64 time=25.4 ms
64 bytes from mc-creative.geekhold.com.beta.tailscale.net (fd7a:115c:a1e0:ab12:4843:cd96:627b:7e36): icmp_seq=2 ttl=64 time=2.03 ms

[nyghtowl]

Follow-up with Dave, the outstanding bug / use case to confirm doesn't exist or needs to be resolved is sending the wrong records when a user disables IPv4 and also has a machine where IPv6 is broken/not working. Potentially a unique enough configuration that hopefully no one will hit. Thus, not considered a blocker to set as default but needs to be address prior to Beta.

[mayakacz]

the outstanding bug / use case to confirm doesn't exist or needs to be resolved is sending the wrong records when a user disables IPv4 and also has a machine where IPv6 is broken/not working. Potentially a unique enough configuration that hopefully no one will hit.

Sounds like a combination of user config & bug

Thus, not considered a blocker to set as default but needs to be address prior to Beta.

Works for me.

[panda2134]

I wonder when will this be rolled out to users? I mean, there's already probing code available, so what's the reason for not turning it on in dualstack networks?

[DentonGentry]

what's the reason for not turning it on in dualstack networks?

Because it isn't finished. The probing code which exists isn't in a state just waiting to be turned on.

[mahtin]

Because it isn't finished. The probing code which exists isn't in a state just waiting to be turned on.

It looks like there's no working code presently; which at this point in the whole v6 lifecycle is amazingly sad. I just setup a R.Pi with v4 only (which is 100% against my religion). It's connected via Tailscale and I get the following (thanks @bradfitz for the jq hints):

$ tailscale status -json | jq -r '.Self,.Peer[] | .Relay + ": " + .LastSeen + " " + .TailscaleIPs[1] + "\t" + .TailscaleIPs[0] + "\t" + .HostName' 
sfo: 0001-01-01T00:00:00Z fd7a:115c:████:████:████:████:████:████	100.██.██.██	martins-air
sfo: 0001-01-01T00:00:00Z fd7a:115c:████:████:████:████:████:████	100.██.███.██	pi-other
lax: 0001-01-01T00:00:00Z fd7a:115c:████:████:████:████:████:████	100.██.██.██	crunch
sfo: 0001-01-01T00:00:00Z fd7a:115c:████:████:████:████:████:████	100.███.███.██	x400
$

There should not be a value in TailscaleIPs[1] for a host that's not running IPv6. My testing included host pi-other that is clearly only presently running IPv4:

$ ssh pi-other.local tail -6 /etc/sysctl.conf
#
# XXX/TODO - ADDED FOR tailscale TESTING
#
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
$

$ ssh pi-other.local /usr/sbin/ifconfig tailscale0
tailscale0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet 100.██.███.██  netmask 255.255.255.255  destination 100.██.███.██
...
$

$ ssh pi-other.local /usr/sbin/ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.47  netmask 255.255.255.0  broadcast 10.0.0.255
...
$ 

I would strongly recommend that this be a priority within Tailscale such that folks using the service on hosts have the correct DNS and/or IP connectivity going forward.

1. Finish the detection code - note that only the tailscale0 device is the one that you need to test for v6.
2. Propagate the v4/v6 status (yes - v4 also because v6 only hosts are important!).
3. Fix the Machines status page on the console so that v6 addressed are not provided for v4 only hosts.
4. Fix status -json (which I assume is actually what drives the console via an API) so the CLI is correct.
5. Then add the correct AAAA DNS records so we can proceed using Tailscale in a circa-2020 environment.
6. That 100.100.100.100 DNS server needs it's v6 equivalent. Something easy to remember and type.
7. Don't forget to upgrade ACL's to include v6.
8. Documentation - yeah - always do the documentation.

I know Tailscale wasn't around for World IPv6 Day; but to be honest, anything written past that date (June 2011) should be v6 native.

Thanks for listening to my soapbox; happy to help beta any of this!

[Sardonimous]

I guess for the time being, on some platforms, we can update /etc/hosts with the output from

tailscale status -json | jq -r '.Self,.Peer[] | .TailscaleIPs[1] + "\t" + .HostName + " " + .HostName + ".xxxxxxx-yyyyyyy.ts.net"'

[jimmybrancaccio]

This popped up in another ticket (33240) from a customer today.