# How to update DNS AAAA record when SLAAC clients appear

I have a routed /64 from my ISP and I am running radvd. My clients (Linux, Windows) are working well without any additional configuration when they get plugged into the router. They all assign themselves unique addresses with the ISPs /64 prefix via SLAAC for both temporary and permanent(1) address assignment.

I am not running DHCPv6 and I don't intend to. As I have learned here, it is quite useless for SLAAC clients unless they have special configuration to use the assigned DHCP address because they will most likely ignore it by default(2) which is fine and preferred anyway. I absolutely do not want to have to do any work on "stock" client machines that plug into the network.

So then, point (1) above: the SLAAC IPv6 addresses the the clients use are not really permanent. Putting these in Bind for DNS AAAA records works … for a while. This is the crux of my problem.

I am unable to figure out how to have the DNS server populate its records based on SLAAC IPs.

Question:

1) Can radvd run a script on an RA and then take this to step 2 …

2) I know from the previous step, that I have a new FE80 address for a new client. How can I get that client's global IPv6 address that it assigned itself using his FE80 address?

3) Then, I would like to update the Bind DNS record with his global IPv6 address obtained in step 2.

The above stuff that I am trying to accomplish seems like it should be plastered all over the Internet – I am struggling trying to figure out what I am doing wrong that makes my use-case so rare. Is there already a mechanism that automatically accomplishes this that I am missing (keeping in mind the DHCPv6 is out of the question)?

Regards and Thanks

(2) SLAAC Ubuntu clients definitely ignore DHCPv6 assignments even when radvd tells them about it. In fact, Ubuntu (and maybe more), even has an old bug when used in this configuration where it actually will not add a route thus rendering the connection useless without some manual intervention. I assume this bug is very low priority since DHCPv6 in conjunction with radvd is not really the recommended solution anyway and I am perfectly fine with that.

Radvd sends out multicast messages with network information, it doesn't get replies back from clients about what they do with that information. So (1) doesn't work.

Link-local addresses (the fe80: addresses) are not related to the global unicast addresses that a client uses. Step (2) is therefore also not possible.

The common solutions to what you want to do are:

• Use SLAAC and DHCPv6 in parallel. The DHCPv6 based addresses are put in DNS by the DHCPv6 server for connections towards the client, and the SLAAC addresses don't get put in DNS to maintain the privacy of outbound connections from the client.
• Use DHCPv6 without SLAAC (turn off the A flag in the RA) and let the DHCPv6 server put the addresses in DNS. Android based devices will not work in such an environment though, so not a good idea.
• Use SLAAC and let the client put its own addresses in DNS. In managed environments (I remember this from long ago in the Win2k and Win2k3 era) this can be configured automatically.

Besides this you can also script things on devices where you can see both the MAC address and the IPv6 addresses used on the network, for example on switches and the default gateway router. You could write a script that monitors which IPv6 addresses are being used, look at the MAC address to determine which physical device it is, look up the hostname for that device in a database and then update the DNS based on that. I don't think there is standard software that will do that for you though.