[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 694
  • Last Modified:

Dns server failover failed to fail over during a demotion process ????

Hi all,

So in short I crippled the network today for 20mins during a 2003 to 2008 migration.

The scenario
We have a 2003 server that was our primary dc this had DNs and acted as our primary  DNs. We also have a deticacted 2003 secondary dns. all workstation and servers had the prime dns set for the 03 server and the secondary server set for the secondary dedicated dns server. I figured when I migrate to 2008 the secondary dns server would take over like it was ment to and I would use psexec to script a change over later on all the servers and work stations. Only issue is the secondary dns never kicked in so all internal resource came to a screeching hult we are a 24 hour shop so we don't get down time... Anyways my ? Is why aren't my workstations failing over like they should. These are the tests iv tried. Changed my primary dns field on my WS to just my secondary dns address works like a champ. Use a bogus primary dns ip on on the primary DNs field and my secondary address on my WS secondary field and it fails to resolve any thing even after flushing dns. I also have dns on the new dc which also resolves  perfect only if it's primary. So where am I going wrong what can I do to make sure I don't make this noob mistake in the future.  

Ps. The migration still went well I did an ntbackup on the server state before demoting the server. So when I had to revert back, it brought back our dns but is no longer a dc. I'm pretty sure ntbackup saved my job. haha thanks ahead of time.

Pss. This is a static environment with no dhcp on WS vlans
0
mattlast
Asked:
mattlast
1 Solution
 
Krzysztof PytkoActive Directory EngineerCommented:
Is this mentioned problem about the Internet name resolution or internal DNS name resolution ?

In the meantime, please visit my blog and check these articles which might be helpful to you
http://kpytko.wordpress.com/2011/08/29/decommissioning-the-old-domain-controller/
http://kpytko.wordpress.com/2011/08/30/decommissioning-broken-domain-controller/

Regards,
Krzysztof
0
 
Leon FesterCommented:
You don't mention which clients you have, but here is link for XP clients.
I've not seen anything for Windows 7 but I'd imagine it probably still works the same.

This behavior occurs because the Windows XP DNS Client service (Dnscache) follows a certain algorithm when it decides the order in which it uses the DNS servers configured in the TCP/IP properties. If the DNS server list is reprioritized, the Windows XP DNS Client service resets the server priority at periodic intervals. By default, the server priorities are reset every 15 minutes.

http://support.microsoft.com/kb/320760/en-us

I almost forgot to mention (from the article):
This behavior is by design.
0
 
mattlastAuthor Commented:
This issue is for both internal and external the DNS server is setup to resolve outside addresses. so if it doesn't failover the inside and outside resources stop.
0
 
Leon FesterCommented:
This behavior is by design, applies to how the DNS client works on your local machine.
So irrespective of whether your DNS servers are internal or external the same behaviour will occur on your workstations.

This answers your question:
Anyways my ? Is why aren't my workstations failing over like they should.

The other question:
So where am I going wrong what can I do to make sure I don't make this noob mistake in the future.  

Don't make DNS server changes during production hours.

The DNS client keeps a local cache of DNS lookups that have already been resolved.
Only if the DNS record does not exist in the local cache with the DNS server be queried.
Local cache expires after 1 hour so then the lookups are performed again.

During after hours operations there are typically not as many new DNS lookups as there would be during production hours with many users on the LAN. So the impact would not be as great.

Unfortunately, you've made the assumption that DNS lookups are seamless failovers.
So the noob mistake was not your execution but rather your understanding.

Another "best practise" recommendation...don't get rid of the old server until you've tested the new one.

The more correct way to migrate would have been:
1. setup new domain controller with DNS role
2. Change DNS server IP's on workstations and Clients
3. Test DNS lookups on old server/new server by monitoring the DNS logs
4. Decomission the old server
0
 
ChiefITCommented:
Also, make sure you go into DHCP scope options and make sure the retired server doesn't exist.

Don't put any servers IP addresses that don't exist on that LAN as a secondary. If you have ONE server, set that as primary and the secondary server should be BLANK. Don't put a bogus IP in there either.

The failure is not the server, but the clients and member servers. It is a client responsibility to seek out the server.

It does this in one of two ways. DHCP passes down DNS servers you set in DHCP scope options. Or, it's manually configured when you configure a static IP on the client.

Please read this and you will get a better understanding:
http://www.experts-exchange.com/Networking/Protocols/DNS/A_323-DNS-Troubleshooting-made-easy.html
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now