Skip to content

Posts tagged ‘dns’


DNS, Server Replacements, and IPv6

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.

  1. Rename the old server (i.e. svrsyslog –> svrsyslogold)
  2. Build the new server with the original name (svrsyslog)
  3. 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.



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.




By Chris Gurley, MCSE, CCNA
Last updated: June 3, 2014


Updated: DNS resolution issues in DFW area

Beginning around 0700 CST, we detected DNS resolution issues in the DFW area (north Texas), particularly on AT&T’s network (i.e. iPhones using 3G), but also with corporate DNS servers going to the root hint servers. Time Warner Cable seems to be unaffected and neither does Airband (a local microwave-based ISP).

As a stop-gap, we implemented forwarders (, and regained a significant amount of resolution. At this point (0826 CST), we’re seeing resolution starting to come back, but certain sites like fail to load content.

Are you seeing anything in your part of the world?

Update from our ISP:

At approximately 3:30 a.m., <DFW provider> began experiencing intermittent internet connectivity.  While troubleshooting we realized we could get to some networks and could not reach other networks.  We narrowed the issue to Level3 who is having a problem with a BGP router located here in Dallas.  We have a ticket open with them and they will inform us once they have resolved their issue.  In the mean time, we have shutdown our Level3 connectivity until this issue is resolved.  We will advise you when we have restored the link after Level 3 has resolved the their issue…

Thus, it appears we have our root cause for north Texas issues: Level3. This also coincides with the partially successful use of Level3 forwarders (, .3) for DNS because it kept resolution on their network (connectivity to other backbones may have been an issue).