Last week I encountered a briefly puzzling situation that’s worth noting as a tip when replacing a server on the network and needing to keep the same hostname. We’re a Microsoft shop, so this speaks to Microsoft DNS and VMs running Windows Server (2008 R2 and 2012 R2), but DNS being what it is, this is likely to apply to BIND, Linux, and the rest.
In this case, we were following a very simple server replacement process with these short steps, much as one would back in the 1990’s.
Rename the old server (i.e. svrsyslog –> svrsyslogold)
Build the new server with the original name (svrsyslog)
Set the new static IP
The relevant difference between the 90’s and now, though, is IPv6 (among many other things). Thus, in DNS, we have two records resembling those of a standard syslog server below.
dns-ipv6-1
What doesn’t stand out in those records, however, is the IPv4 portion of the IPv6-encapsulating address. So when we changed the server name to “…old”, everything looks fine, because the “Host (A)” record updates to the new name and a corresponding “IPv6 Host (AAAA)” record follows right below.
The key here is that the IPv6 record below the updated “svrsyslog” IPv4 record may not match. In our case, the old IPv6 record never updated; only the IPv4 did. This creates problems when connecting to the new server in a dual-stacked IPv4/IPv6 environment. IPv6-aware systems attempt to resolve the new “svrsyslog” with DNS and get the old IPv6 address (because the rebuilt server didn’t update the v6 record). IPv4 points one place, while IPv6 points to another.
The solution is as simple as it is in IPv4; obscurity and unfamiliarity with IPv6 is all that makes it elusive. Open the IPv6 record of the new/original server name (in this example, SVRSYSLOG) and edit the decimal portion of the IP address. Microsoft is kind enough to translate it from hex for us is the dialog box. Make that last chunk match, and you’re good to go.