Update Primary DNS Server IP on a 2008 R2 Domain Controller - Is Reboot Needed?

Of course you could reboot the server which will allow the updated IP settings to take hold.  But, I recommend doing the following on all Domain Controllers:

1. ipconfig /flushdns
2. ipconfig /registerdns“
3. restart DNS server
4. NETLOGON

Dan

Thanks, Dan.  

Why do all these additional commands on every DC in the organization?  

Also, do you mean restart Netlogon service in #4?  

Finally, are you suggesting all these commands on each server instead of simply rebooting the west coast box that we did the DNS setting change on?

You don't have to reboot the server just to make a change like this.  TCP/IP setting changes happen (in general) on the fly now (this has actually been in place since server 2000).

No reboots
 Unlike previous versions of Windows NT (and Windows), you won't need to reboot your computer when you change a network configuration.
(...)
No reboots?
 Well, this is one of those "works in theory" things. Most of the time, you should be able to change network settings without rebooting (though Windows 2000 will tell you if you absolutely need to reboot). However, sometimes you'll change network settings and nothing works. If this is the case, just reboot the machine. Nine times out of ten, all will be well.

Source

You may be thinking of changes to the hosts file, which prior to WinVista/Server 2008, *did* require a reboot for the changes to take affect.

-saige-

Thanks, @IT_Saige:

I realize the TCP/IP settings already took place immediately.  

The concern on this end is are there are Active Directory / DNS tie-ins or functionality that would require a reboot to recognize the new Primary DNS setting of the server in TCP/IP config?

For example, does the File Replication Service service "read" the primary and secondary DNS setting when service starts, and then does not look at what is in TCP/IP config until next time service restarts.

The commands do the following:

1. this purges the local DNS cache of all records.  helpful when pointing to a new DNS server or having name resolution issues.  Since you are using a different DNS Server as primary, its a good practice to do this.
2. this makes sure that the DC can register its DNS records correctly.  This will go against the new DNS settings.  If this were to fail, you would start having DNS and AD issues.
3. restarting the DNS Server makes sure that the local DNS server service can load AD Integrated zones from other DCs on the network.  If the DC's DNS client settings were incorrectly configured, you'd start having DNS and AD issues.
4. restarting the Netlogon server ensures that the necessary Domain Controller specific DNS records are correctly registered (for example the DC's SRV records)... again, if things are incorrectly configured you'd start having DNS and AD issues.

As a reference, the following links to the defacto recommendation for DNS client setting configuration for DC and servers.  You will find it referenced to all over the place where AD, DNS, DNS Client settings are being discussed:

link:  https://abhijitw.wordpress.com/2012/03/03/best-practices-for-dns-client-settings-on-domain-controller/

Dan

@Dan...

Thanks for all this great info.  

Just to confirm....

1.  Are you suggesting we do these change on ALL DC's or just the DC on which we made the Primary DNS server IP setting change?

2.  Are you suggesting these changes INSTEAD of rebooting the DC who's DNS config we updated? (or in addition to?)

We're just not clear on why we'd have to touch every DC in the org if we only made a Primary DNS Server TCP/IP setting change on one DC.

Active Directory related services (and other programs/services) on the DC don't care about the DNS settings on the NIC.  The DNS settings on the NIC allow for tcp/ip packets to be routed to their intended target.  A cache of DNS queries (or lookups) is stored on the local system so that DNS queries don't always go to the DNS server, if a computer has visited a site or address before, and the cached entries TTL has not expired, then the packet is sent to the intended target.  So to answer your question directly, FRS couldn't care less what your DNS address is.

This is contrary to when you are changing the IP address on a DC.

-saige-

I caution you against using a different DC as the primary DNS server on a DC.  This is not recommended and what is recommended is that each DC should point to itself for primary DNS.  This is done for the sole reason that in an event of restarting your DC and you do not have any connectivity to other DCs, your DC should work fine and be able to update its own records in DNS (as well as faster logon to console and start of other services as they are not waiting to successfully contact DNS server).

All local systems (servers, workstations, etc.) should use the local (or the closest) DC as its DNS server.

@Mohammed - The info you provided above is contrary to many, many, many technical articles we have read along the way.  Most resources recommend primary DNS of a DC pointing to another domain controller and secondary pointing to itself.

@Dan - thanks again for your insightful info and clear explanation.  We are leaning toward doing what you said on the server where we changed the primary DNS setting.  However, we're still not convinced this change needs to be made on all the other DCs in the organization (2 on the east coast).  because we are not changing anything here.

If we ONLY do your suggested list of steps on the single west coast DC where we made the simple DNS setting change, do you think we'll be OK?  It sounds like it would essentially be the same as simply rebooting that DC on the west coast.

@IT_Saige, thanks for your info too.  What do you think about Dan's feedback?

Thanks a lot!

Then I highly recommend at least doing an ipconfig /flushdns on all DCs so that their caches are cleared and the initial DNS hits result in a refresh of the local caches.

I still recommend going thru the 4 command on all DCs.  But you know your operational environment better than I do.

I'll suggest that if any unusual warnings or errors begin showing their ugly heads, that you proceed with the commands.

Dan

@Dan, thanks again - you've been great and are convincing us.  The reason we are floundering about this is because we are in a critical production environment.  Any issues doing these service restarts during the day or should we wait until after hours/maintenance window?

@IT_Saige:

Very interesting.  You do make some very good points.  Indeed, we have not changed the landscape of our organization or the IP address of the West Coast DC.  

We ONLY changed what DNS server it is pointing to in it's Primary DNS server setting.  That's it.

At this point, the change is already done and all is fine.  We just weren't sure if there was more to do.

Replication seems to be working fine too based on repadmin /replsummary  

At what point could we be 100% sure this worked out fine with no additional changes or a reboot?  A full replication cycle?  A day or two?  I suppose we could run a DCDiag at end of day too.

Overall, I think Dan's feedback has been very educational - just not 100% sure it applies for the change we made today.

Please provide me proof.  If you are still unsure, perform a search for "dns island" and you can see MS recommendations.  Just for your information, I went through a RAP with Microsoft (RAPs are risk assessment and planning sessions for customers with valid Enterprise Support agreement) which is provided by PFEs (Premier Field Engineers who are subject matter experts).

If you change dns settings from one server to another except its own IP, then no need to reboot the server
Just dnscmd /clearcache and ipconfig /flushdns are enough

If you are pointing dns server to itself, then you do need to restart netlogon service and dns server service as well to ensure all records are registered

Also I am wondering when your local server has DNS server role (AD integrated) installed, why you would point it to another DNS server
I assume all dns zones are similar on both servers
Moreover in case of Domain controller name resolution if you have entered another DNS server IP as primary, for unresolved queries it will try to communicate with primary dns server which is also DC in same domain and do not have answer for that query because both servers are identical and then again query will get routed to forwarders \ conditional forwarders \ root hint servers etc

However if server pointing to itself as primary dns, for unresolved queries, it will directly look for appropriate options such as forwarders \ conditional forwarders \ root hint servers etc

According to my understanding, when you install DNS role on server, it should point to itself as primary dns (not 127.0.0.1) because he is authoritative for copy of all AD integrated zones he hosts and only he can refresh / register its own record

I am not going too back, but if you deploy parent -child domain pair, in that case all child domain dns entries will not get populated on child DC unless you point it to its own IP as primary dns and restart dns and netlogon server service.

@Mohammed:

It seems the question of primary and secondary DNS settings on a DC has been argued back and forth for ages.  Here is an exceprt from a TechNet article.  

Source:  http://blogs.technet.com/b/askds/archive/2010/07/17/friday-mail-sack-saturday-edition.aspx#dnsbest

It depends on who you ask. :-) We in MS have been arguing this amongst ourselves for 11 years now. Here are the general guidelines that the Microsoft AD and Networking Support teams give to customers, based on our not inconsiderable experience with customers and their CritSits:

1.  If a DC is hosting DNS, it should point to itself at least somewhere in the client list of DNS servers.
2.  If at all possible on a DC, client DNS should point to another DNS server as primary and itself as secondary or tertiary. It should not point to self as primary due to various DNS islanding and performance issues that can occur. (This is where the arguments usually start)

Overall, this Active Directory has been around for over 10 years without issue.  We are running in 2003 Mode and have 3 2008 R2 DCs.  Just haven't made the switch to 2008 Functional Mode (yet).

This is a great thread with some healthy debate.  I just don't see us going around and changing the primary and secondary DNS settings on all DCs in our organization since they are working 100% fine and have been for years.

Here is our setup in case you are wondering:

DC01 - East Coast DC with all FSMO roles
ADS - East Coast DC
CA01 - West Coast DC

Here are the primary and secondary DNS settings as of right now:

DC01:

Primary DNS is ADS
Secondary DNS is DC01

ADS:

Primary DNS is DC01
Secondary DNS is 127.0.0.1 (dcpromo did this automatically)

CA01:

Primary DNS is DC01
Secondary DNS is CA01

All working fine.

@Mohammed - You might want to take a look at this blog post on Technet.  The interesting part that struck me was this -

It depends on who you ask. :-) We in MS have been arguing this amongst ourselves for 11 years now.

Source

-saige-

@dpmoney - Wow, call me Johnny-come-lately...  LOL.  ;)

-saige-

I will agree that my recommendations may be considered a bit overkill but since there is limited info on the existing setup of AD, its hard to say if the change won't affect something else.

I mentioned that you know your infrastructure best and recommended that you act on your knowledge of the system. That is the best I can do... Share my experience and make the best recommendations based on limited info.

Hopefully your change worked.

Gotta put the kids in bed... Challenge number 2.

Dan

Dan...  That challenge may be more than even EE can assist with.  ;)

-saige-

I am going to award the points to both IT_Saige and Dan.  You have both been very insightful and helpful throughout the thread.

Ultimately, we are going to do IT_Saige's suggestion which is nothing else.  

We were going to do the IPConfig /FlushDNS at a minimum on the west coast DC, but that is just going to clear the local DNS resolver cache on that box.  Since we did not change ANY IP addresses of any hosts, it probably is not applicable.

If we do have issues, we will certainly reference Dan's great information and will carry out those commands.

Thanks to the both of you!

We ultimately did not reboot the domain controller after simply changing the primary DNS Server setting in TCP/IP.  This was due to a lot of back and forth between multiple parties and our own knowledge of the environment we have in our organization.  Everything seems fine so far.  We awarded points to IT_Saige (the advise we ultimately followed), but also gave points to Dan for a lot of great information in the event that problems surface unexpectedly.  Thanks to everyone who contributed!