This one will be nice and short. I was working on a DNZ zone migration, from one domain to another. Since the zone wasn’t the parent zone of the AD domain it was in I had two options.
One make the new domain authorative for the zone, once trust is established they would take over for the zone.
Or in this case since there were only a few records and the new AD domain was already created with the same domain anem as the zone I was attempting to migrate, I figured I’d simply recreate the records manually.
Basically setup your conditional forwarders to the new domain DC’s which will be authorative for the new zone. Generally allow UDP (TCP as well if you want to be extra safe) on port 53 through the firewall, and records should resolve just fine.
In this case you’ll clearly notice that resolving the record for the transferred zone from the orginal domain now replies with non-authorative answer.
This is to be expected as the domain’s DC that you are associated with (and generally your DNS settings configured to via DHCP of course) are no longer controlling the zone (adding/removing/editing records).
Again as to be expecting these are now managed via the new domain which teh zone was transferred to.
So low and behold I messed u one of the records IP addresses. So sure it’s super fast to adjust and force replication, however replication would be domain/forest wide. Which even though I did on both domains i found my previous DC’s would update the non-authorative answer.
I tripple checked all systems in teh new domain could get the proper reply from the DC/DNS servers. So what gives why were the old DC’s DNS servers replying with the old IP address, when the conditional forwarders were setup to query the proper DNS servers and they were 100% holding the correct IP address?
The answer? Cache? yup the lovely blessing and nightmare that is cache. so what does any regular workstation admin try… yeah you guessed it “ipconfig /flushdns” (cmon were talking AD here which is Microsoft specific AFAIK). Do a query from your old domain DC’s and yet the record is still the old IP adress?!?!
What gives? Well… in this case ipconfig /flushdns is only used for clients. You maybe wondering isn’t the old DC a client in this case? Yes/No It’s still a DNS server, and it still needs to answer queries it recieves, the command provided would help if simply doing a query (yes we are doing a query but for a record it needs to hold a record for to reply with).
Just to stop beating around the bush, as a DNS server it needs to clear its own cache, the records to retains to provide to requesting clients. this is a different command. in this case it’s dnscmd /clearcache.
That’s it, do another lookup and find your old DC DNS servers showing a non-authorative answer of the new IP address. Of course you could have also simply waited for cache to clear and replication to occur naturally… but ain’t no body got time for that!
1) To Clear Dns from a client system (Windows): ipconfig /flushdns 2) To clear non-authoritative DNS servers cache: dnscmd /clearcache
