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

Posted on 2012-09-17
Last Modified: 2012-10-09
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
Question by:mattlast
    LVL 39

    Expert Comment

    by:Krzysztof Pytko
    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

    LVL 26

    Expert Comment

    by:Leon Fester
    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.

    I almost forgot to mention (from the article):
    This behavior is by design.

    Author Comment

    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.
    LVL 26

    Accepted Solution

    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
    LVL 38

    Expert Comment

    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:

    Featured Post

    Want to promote your upcoming event?

    Attending an event? Speaking at a conference? Or exhibiting at a tradeshow? Easily inform your contacts by using a promotional banner in your email signature. This will ensure your organization’s most important contacts are in the know.

    Join & Write a Comment

    Suggested Solutions

    A quick step-by-step overview of installing and configuring Carbonite Server Backup.
    You might have come across a situation when you have Exchange 2013 server in two different sites (Production and DR). After adding the Database copy in ECP console it displays Database copy status unknown for the DR exchange server. Issue is strange…
    This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database. Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
    This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…

    734 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now