2

Current environment: Two Windows Server 2003 servers, not joined to our domain (These are here to handle our outside DNS requests).

Plan: Stand up Windows Server 2012 R2 server, do not join to our domain. Give IP and install DNS role on server. Mark server as slave to our master DNS server which is Windows Server 2003. Once replication is complete, mark 2012 R2 DNS server as master. Build secondary DNS server on 2012 R2 platform, join as slave to 2012 R2 master. Then decommission 2003 DNS servers.

My question is, are there any "gotchas" or issue with this plan? Will there be compatibility issues between the 2003 server and the 2012 R2 server? Is our plan viable? I have been searching around and have not found anything about doing this either from Microsoft or from one of their partners.

Improve this question

4 Answers 4

Reset to default
2

Edit:

Please note the below only transfers A records and no other so you would still need to manually input remaining.

I've never done the above, but another alternative would be to:

  1. export your A records and zones from 2003. Save it - c:\dnsrecords.txt
  2. re-importing into Server 2012.
  3. Replicate other 2003 settings on 2012 that covers external lookups.
  4. Assign one PC with the new DNS servers and monitor the effects.

Exporting the DNS entries can be done on 2003 server. You should have a text file similar to the below.

User-PC Host (A)    10.24.2.48
Fileserver  Host (A)    10.25.2.49

  • Get the file into XLS and turn Host & (A) into columns so you are only left with.

    User-PC 10.24.2.48

    Fileserver 10.25.2.49

You can then use for & dnscmd to import the entries into your server 2012. Below is the dnscmd syntax and below that an example, which will run the command multiple times using the .txt you created as the input. It will replace %i with the hostname and %j with the IP address.

dnscmd ServerName /RecordAdd DNSZoneName HostName RecordType IPAddress

DNScmd syntax:

for /f "tokens=1-2" %i in (c:dnsrecords.txt) do dnscmd Server2012 /RecordAdd test.local %i A %j
Improve this answer
2

I've replicated this way before. It's just a zone transfer, really.

I had to do it as part of a migration to new 2008 DC's in preparation for raising the functional level and replacing old hardware. The issue I had with 2003 was ad-integrated DNS not playing nicely. May have simply been because this domain had been an upgrade from NT 4.0 -> win2k -> win2k3 and then to win2k8. Only 2k12 member servers... that being said:

https://support.microsoft.com/en-us/kb/323383

https://technet.microsoft.com/en-us/library/cc739904(v=ws.10).aspx

Biggest issue that I had was with internal servers having DHCP addresses but manually configured DNS servers ( I know this makes no sense ). My advice would be to keep the old servers live and change your outside NS records to point to new servers before decommissioning the old ones ( external DNS should still accept SOA for secondaries ). That will keep you alive during DNS zone propagation on the outside. It will also let you roll back with less pain.

Improve this answer
1
0

we have upgraded our DNS server as Slave in 2003 Domain server environment. I know you mentioned about not being in domain environment but I don't think that would be an issue as long as you have access/admin rights to Master DNS server. Once the new 2012 server is configured with DNS role, you will get an option at one stage to replicate from Master DNS server. As stuart mentioned, it would be mainly zone transfer and should not cause any issues having both running at the same time but you ideally want to demote/stop using 2003 server.

Improve this answer
0

@Ankh2054 - Great answer! Make certain that you clarify that you're only transferring A records with your script. ( my apologies for not commenting directly, I can't comment on posts yet )

While in windows in an inside environment using AD you usually have the SRV records created by AD, MX records are commonplace. NS records are pretty big as well, even internally with NS IP's provided by DHCP. Don't forget reverse zones for convenience ( PTR records ) and some mail servers will complain if there is not an external PTR for sanity checks.

Original Poster didn't specify whether or not they were using SPF,Google Apps, or some other Federated services which often require adding TXT records with a fingerprint, verification key, or something similar. External CNAME records are common and a great way to provide the ability to manually fail over to backup servers and to segregate services from the IP they're running on.

Still, your script is a very elegant solution. I've used something close ( but not as clean ) to bulk add missing PTR records.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .