RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
:) demists eyes The main thing I don't like is AD Integrated. There is something fundamentally wrong with having your directory replication completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system kick I like the idea of multiple masters, I am tepid on the security (I haven't seen nor heard of anyone who has been attacked this way in 6 years of asking around), I am outright against the replication model. Aside from that, I was tainted by seeing UNIX DNS products running great at large scales and seeing Microsoft DNS screwing up tono end at medium scales. I fully realize it could have been a function of the people running it but one key time I saw it was in a pretty large company that hadUNIX DNS in a complicated layout that worked great for hundreds of thousands of machines and a Microsoft DNS being used for the hundreds of DMZ machines in a very simple layout which had Microsoft resources helping with it and guess which DNS systemI was hearing issues about and that was constantly having AD failures because of DNS? Again I fully realize it very likely could have been the people involved but some of those people were MSFT people so it shouldn't have been that difficult to get it working right. Everytime they tried to pull me in to work on the AD issues I simply said, fix your DNS and get on the corporate standard and then I will look at what your problems are. If I had to work do ops in an environment where MSFT DNS was my only option it is quite likely that I would work to become an expert on it and it is also possible I would work on it and finally just say screw this and I am going tosit down at night and write my own version of DNS or use BIND.That way I can have full control of what is going on and not wonder what the hell is going on or what changed in the last rev such that now my AD can't work because DNS isn't working because my DC is flaking out because AD isn't working. Etc etc etc. I guess what I am saying, a string of dependencies no matter how long or how short really shouldn't loop back upon itself. You shouldn't have to be sitting there wondering if AD broke DNS or DNS broke AD and what you have to fix to make it all work again. If I am running DNS on another platform or at least on a Windows machine with no dependence on the domain and I see that DNS and AD are broken I know right where I need to start working without thinking very hard about it. The KISS philosphy is there for a reason, ops people especially in the middle of a blowup should not be required to think hard. The hard thinking needs to occur in the design and prior to things blowing up. When something blows up it should be a matter of putting it back together. Obviously it isn't always going to be that way but purposely putting something together that is going to require that hard thinking when it blows for sure doesn't make much sense to me. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 21, 2006 11:37 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Now don't go getting misty eyed and thinking that I'm coming over the joe-side of thinking when it comes to DNS and Microsoft. But aye, it has it's shortcomings and could be much better. Perhaps they need a real competitor vis a vis Firefox and IE to get things jumping? Hmm. :) On 7/21/06, joe [EMAIL PROTECTED] wrote: Hehe Bingo... keep playing and one day you may even think how nice it is to not have DNS on DCs at all or even on Microsoft Is that heresy here? If so I will say three Hail Kwan's and sprinkle some ground up Intel chip dust on myself... ;o) Dean wonders why I hate DNS. :) http://www.gilsblog.com/index.cfm?commentID=60 -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Al MulnickSent: Thursday, July 13, 2006 3:32 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but I detest the idea of a DNS
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Any poor implementation is going tohurt you but I would argue that you are better off with a poor BIND/QIP DNS implementation than a poor Windows DNS implementation just because of the whole dependency loop thing. If you can adequately state your needs to a UNIX DNS group they can usually fullfill those needs and things should work fine. I guess MSFT could help out with this and make it so there was a way to staticly specify the required records for replication in flat files on DCs in the event there is a failure. At least this gets you up and running to the point where replication is working again and you can start working on the original DNS issue that caused the mess. Once DNS is functioning properly again you turn off the side road with the static entries. Again for me the part that hurts is if AD and AD DNS running on a DC is down, you really don't have a clue what caused what and have to start looking at everything. Most people aren't equipped to look at everything and quickly narrow it down to the key components. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Saturday, July 22, 2006 10:24 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? The downside is that your logic on this one is very hard to argue with. At the heart of the matter you are saying (allow me to paraphrase) that the issue is the dependency of one system on another which is dependent on the former. Yep, that's hard to argue with because you are right. The part that gets me is that I've seen it the other way. A BIND, or QIP implementation that was done horribly and offered way less simplicity (aka troubleshooting "hand-holds" - digression: I firmly believe that IT systems should be designed like sewer systems - with maintance access points built in along the way. The results of not doing that are similar ;) and the results were a less stable system than with delegated ad-integrated zones that only the Windows environment relied on. Oddly, that Windows environment is the gateway to the rest of the environments for the users, but hey, that's not part of this conversation now is it? Anyhow, I see your point and that's an interesting point to consider and one that is certainly tough to argue with. My only counter at this point is that either DNS system is going to be dependent on those that design and deploy it and if you're like many companies of mid to large size, your DNS is distributed and managed by those of the platform it runs on. In many instances if you run *nix, it'll be on the *nix platform, if by Windows, then by Windows support. Worse to me is if it's done by the network (phys) folks. May as well give it to the guard shack. :) On 7/22/06, joe [EMAIL PROTECTED] wrote: :) demists eyes The main thing I don't like is AD Integrated. There is something fundamentally wrong with having your directory replication completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system that is completely dependent on the name resolution system that is completely dependent on the directory replication system kick I like the idea of multiple masters, I am tepid on the security (I haven't seen nor heard of anyone who has been attacked this way in 6 years of asking around), I am outright against the replication model. Aside from that, I was tainted by seeing UNIX DNS products running great at large scales and seeing Microsoft DNS screwing up tono end at medium scales. I fully realize it could have been a function of the people running it but one key time I saw it was in a pretty large company that hadUNIX DNS in a complicated layout that worked great for hundreds of thousands of machines and a Microsoft DNS being used for the hundreds of DMZ machines in a very simple layout which had Microsoft resources helping with it and guess which DNS systemI was hearing issues about and that was constantly having AD failures because of DNS? Again I fully realize it very likely could have been the people involved but some of those people were MSFT people so it shouldn't have been that difficult to get it working right. Everytime they tried to pull me in to work on the AD issues I simply said, fix your DNS and get on the corporate standard and then I will look at what your problems are. If I had to work do ops in an environment where MSFT DNS was my only option it is quite
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
If it should be, it should come from MSFT... They could easily configure that if they feel it is important. As a general thing, you really shouldn't be having to manipulate service startup order especially for critical services. I think I have done that maybe 5 or 10 times in 10 years and I am a complete hacker with this stuff. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji AkomolafeSent: Thursday, July 13, 2006 10:11 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Not unless you make Netlogon dependent on DNS in the startup order. That should be a standard practice. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /) (/ Microsoft MVP - Directory Serviceswww.readymaids.com - we know ITwww.akomolafe.com-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED]Sent: Thu 7/13/2006 1:20 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? One point that is nearly always overlooked is the following, if a DC points to itself for DNS name res: The DNS server service starts *after* NETLOGON, at startup The DNS server service stops *before* NETLOGON, at shutdown i.e. at startup netlogon cannot register DNS records on the local machine until the DNS server starts (record reg may fail or be stalled / time out). at shutdown or during a demotion netlogon cannot un-register DNS records on the local machine since DNS server has stopped (demotion will leave DC records in tact). For these reasons alone - I always recommend that a DC points to another (local) DNS server (not necessarily a DC) and then itself as secondary (or maybe even tertiary). my 2 penneth, neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: 13 July 2006 02:59To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server.That'd be the best practice. Before 2003 you could have an "island effect" where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Hehe Bingo... keep playing and one day you may even think how nice it is to not have DNS on DCs at all or even on Microsoft Is that heresy here? If so I will say three Hail Kwan's and sprinkle some ground up Intel chip dust on myself... ;o) Dean wonders why I hate DNS. :) http://www.gilsblog.com/index.cfm?commentID=60 -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Thursday, July 13, 2006 3:32 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but I detest the idea of a DNS server being a client to a peer name res server. I'm still inclined to continue to use the self-as-primary deployment. I understand that silliness (thanks for pointing out that situation James) can impact availability and that would normally indicate a bad design. I'm curious though, why in the situation described that the server couldn't replicate and begin serving records. I haven't looked lately, but how many replication partners does it have to talk to before it will serve DNS? "I'm looking for server x. Do you have it? Hello? Are you there? No? Let me check myself then." It also goes against the idea that each name res server should have as much of a complete picture of the environment as possible else there's no reason to have multiples. Hmm... On 7/13/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: note that DNS startup behavious changes with SP1, which is anotherreason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it hassuccessfully replicated with one of it's replication partners.This isto avoid false or duplicate registration of records (or even duplicate creation of the application partitions).As such, with SP1 it's better to point your DCs to a replication partneras a primary DNS and to self as a secondary./Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of[EMAIL PROTECTED]Sent: Donnerstag, 13. Juli 2006 17:02To: ActiveDir@mail.activedir.orgCc: ActiveDir@mail.activedir.org ; [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?Hi Al I did want to throw in a personl experience I had with W2K3 thatvalidatesthe "Point your DNS server to a replication partner theory".I did seeinone environment where every DC had DNS and the msdcs partition was a forestpartition.An unfortunate DNS scavenge was done deleting some of theGUIDrecords in the MSCDCS partition.Replication started to fail shortlyafterthat and the missing GUIDs were discovered.The netlogon service was restarted to make the DCs re-register but of course they re-registeredtheGUID on themselves.They could find themselves but not theirreplicationpartners.The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primaryandthemselves as secondary the problem went away - the netlogon service wasrestarted, the GUIDs registered on the central DNS server, the spokes didthe lookup for replication parnters on the hub site DC and eventuallythings started working again.This was pre - SP1 so this may not be a problem anymore, but after thatexperience I have seen value in doing the DNS configuration so that the DCsall point to the hub first and themselves second.I have not seen anyproblems for the DC itself when the WAN link dropped for a length oftimeand the primary DNS server was not reachable.Of course, if there are never any changes to DC IPs or names and the MSDCSis never scavenged (or the interval is long enough not to recreate theabove problem) then the above argument is moot.Regards;James R. DayActive Directory Core TeamOffice of the Chief Information Officer National Park Service202-230-2983[EMAIL PROTECTED] "Al Mulnick" [EMAIL PROTECTED] To:ActiveDir@mail.activedir.org Sent by: cc: (bcc:James Day/Contractor/NPS) [EMAIL PROTECTED]Subject:Re:[ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNSserver...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;)There are many many many ways to properly configure DNS.One thing thathelps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternateserver that you want this DC to be a client of.DNS is a standard.Windows 2003 DNS
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Now don't go getting misty eyed and thinking that I'm coming over the joe-side of thinking when it comes to DNS and Microsoft. But aye, it has it's shortcomings and could be much better. Perhaps they need a real competitor vis a vis Firefox and IE to get things jumping? Hmm. :) On 7/21/06, joe [EMAIL PROTECTED] wrote: Hehe Bingo... keep playing and one day you may even think how nice it is to not have DNS on DCs at all or even on Microsoft Is that heresy here? If so I will say three Hail Kwan's and sprinkle some ground up Intel chip dust on myself... ;o) Dean wonders why I hate DNS. :) http://www.gilsblog.com/index.cfm?commentID=60 -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Al MulnickSent: Thursday, July 13, 2006 3:32 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but I detest the idea of a DNS server being a client to a peer name res server. I'm still inclined to continue to use the self-as-primary deployment. I understand that silliness (thanks for pointing out that situation James) can impact availability and that would normally indicate a bad design. I'm curious though, why in the situation described that the server couldn't replicate and begin serving records. I haven't looked lately, but how many replication partners does it have to talk to before it will serve DNS? I'm looking for server x. Do you have it? Hello? Are you there? No? Let me check myself then. It also goes against the idea that each name res server should have as much of a complete picture of the environment as possible else there's no reason to have multiples. Hmm... On 7/13/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: note that DNS startup behavious changes with SP1, which is anotherreason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it hassuccessfully replicated with one of it's replication partners.This isto avoid false or duplicate registration of records (or even duplicate creation of the application partitions).As such, with SP1 it's better to point your DCs to a replication partneras a primary DNS and to self as a secondary./Guido-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.orgCc: ActiveDir@mail.activedir.org ; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?Hi Al I did want to throw in a personl experience I had with W2K3 thatvalidates the Point your DNS server to a replication partner theory.I did seeinone environment where every DC had DNS and the msdcs partition was a forestpartition.An unfortunate DNS scavenge was done deleting some of the GUIDrecords in the MSCDCS partition.Replication started to fail shortlyafterthat and the missing GUIDs were discovered.The netlogon service was restarted to make the DCs re-register but of course they re-registered theGUID on themselves.They could find themselves but not theirreplicationpartners.The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary andthemselves as secondary the problem went away - the netlogon service wasrestarted, the GUIDs registered on the central DNS server, the spokes didthe lookup for replication parnters on the hub site DC and eventually things started working again.This was pre - SP1 so this may not be a problem anymore, but after thatexperience I have seen value in doing the DNS configuration so that the DCsall point to the hub first and themselves second.I have not seen any problems for the DC itself when the WAN link dropped for a length oftimeand the primary DNS server was not reachable.Of course, if there are never any changes to DC IPs or names and the MSDCSis never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot.Regards;James R. DayActive Directory Core TeamOffice of the Chief Information Officer National Park Service202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To:ActiveDir@mail.activedir.org Sent by: cc: (bcc:James Day/Contractor/NPS) [EMAIL PROTECTED]Subject:Re:[ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNSserver...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;)There are many many many ways to properly configure DNS.One thing thathelps is to think of the terms client and server vs. preferred and alternate
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Nice answer Steve. Thanks for the info. and the KB. - Original Message - From: Steve Linehan To: ActiveDir@mail.activedir.org Sent: Friday, July 14, 2006 7:41 PM Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I believe I covered most of this on a previous posting to ActiveDir but here are all of the details into what change was made and why: First of all the change that was made requires that an Initial Sync is completed before DNS will load the zones. This change was made after a customer reported a very nasty outage of all DNS records for one of their Domains. Needless to say with no DNS records many things break. So how and why did this happen. It turns out that many things have to come together but the end result is that we Conflict the MicrosoftDNS container, note not the application partition. This can occur do to a timing issue that was first seen when using an Install from Media (IFM) technique across a slow WAN link and of course you are not using the new feature in Windows Server 2003 SP1 that allows sourcing Application Partitions from media. Because Application Partitions have the lowest replication priority it was possible that the machine would register to host the DomainDNSZones application partition but never get a chance to replicate any information in do to it being pre-empted by higher priority Config and Domain partition replication. In that case if the timing was just right it was possible that the DNS server on this box would recreate the MicrosoftDNS container in order to store the root hints. This would of course replicate out and cause a CNF and since last writer wins you would end up with what looked like an empty MicrosoftDNS container, except for the root hints, which looked like corruption to all of the other DNS servers since they had records loaded from there at one point. To keep this from happening a requirement that the DC must perform an initial sync was put in place. This was the safest way to insure that we had replicated the necessary data in before trying to load zones and possibly conflict the MicrosoftDNS container. There were other places where this type of issue could pop up such as how we handle SOAs so the change was made. There is additional work being done in Windows Server “Code Name Longhorn” to help with this as well as other performance issues of loading large zones which caused slow DNS startup times. I have sent Email to the appropriate component owners so that they can revise if necessary our guidelines on how DNS should be configured for both Windows Server 2003 and the next version of the product. The only thing I would not recommend is removing the initial sync requirements by adding a registry value as this not only has affects on DNS but also the code that is used to insure that we do not have multiple machines believing that they are a particular FSMO owner. Here is the KB for the change that was introduced and rolled into SP1: http://support.microsoft.com/kb/836534/en-us . I have left out some of the hairy details as to exactly why the above happens as well as the customer who initially hit this, they know who they are. J Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 14, 2006 12:46 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Indeed very usefull information, thanks for this. - Oorspronkelijk bericht - Van: Paul Williams [EMAIL PROTECTED] Datum: maandag, juli 17, 2006 12:06 pm Onderwerp: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Nice answer Steve. Thanks for the info. and the KB. - Original Message - From: Steve Linehan To: ActiveDir@mail.activedir.org Sent: Friday, July 14, 2006 7:41 PM Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I believe I covered most of this on a previous posting to ActiveDir but here are all of the details into what change was made and why: First of all the change that was made requires that an Initial Sync is completed before DNS will load the zones. This change was made after a customer reported a very nasty outage of all DNS records for one of their Domains. Needless to say with no DNS records many things break. So how and why did this happen. It turns out that many things have to come together but the end result is that we Conflict the MicrosoftDNS container, note not the application partition. This can occur do to a timing issue that was first seen when using an Install from Media (IFM) technique across a slow WAN link and of course you are not using the new feature in Windows Server 2003 SP1 that allows sourcing Application Partitions from media. Because Application Partitions have the lowest replication priority it was possible that the machine would register to host the DomainDNSZones application partition but never get a chance to replicate any information in do to it being pre-empted by higher priority Config and Domain partition replication. In that case if the timing was just right it was possible that the DNS server on this box would recreate the MicrosoftDNS container in order to store the root hints. This would of course replicate out and cause a CNF and since last writer wins you would end up with what looked like an empty MicrosoftDNS container, except for the root hints, which looked like corruption to all of the other DNS servers since they had records loaded from there at one point. To keep this from happening a requirement that the DC must perform an initial sync was put in place. This was the safest way to insure that we had replicated the necessary data in before trying to load zones and possibly conflict the MicrosoftDNS container. There were other places where this type of issue could pop up such as how we handle SOAs so the change was made. There is additional work being done in Windows Server Code Name Longhorn to help with this as well as other performance issues of loading large zones which caused slow DNS startup times. I have sent Email to the appropriate component owners so that they can revise if necessary our guidelines on how DNS should be configured for both Windows Server 2003 and the next version of the product. The only thing I would not recommend is removing the initial sync requirements by adding a registry value as this not only has affects on DNS but also the code that is used to insure that we do not have multiple machines believing that they are a particular FSMO owner. Here is the KB for the change that was introduced and rolled into SP1: http://support.microsoft.com/kb/836534/en-us . I have left out some of the hairy details as to exactly why the above happens as well as the customer who initially hit this, they know who they are. J Thanks, -Steve --- --- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 14, 2006 12:46 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicate app-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFM feature to rollout the DCs. But prior to SP1 you couldn't add the application partitions to the dcpromo process (IFM in SP1 now offers an the options to include app partitions during the promotion). During this rollout a couple of DCs
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
I can't see how you can get a duplicate NDNC as the creation of such objects is targetted at the DN master. The DN master will check the existing crossRefs and stop this happening, as we can't rely on the DS stopping it as the RDN is different for each NDNC (unless they've used well-known GUIDs for the DNS NCs?). Although the behaviour you speak of is new to me, and another one of those slight, interesting changes, so thanks for that. Can you elaborate on this new behaviour? What, exactly, happens and in what order? --Paul - Original Message - From: Grillenmeier, Guido [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, July 13, 2006 6:52 PM Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it has successfully replicated with one of it's replication partners. This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replication partner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when the WAN link dropped for a length of time and the primary DNS server was not reachable. Of course, if there are never any changes to DC IPs or names and the MSDCS is never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent by: cc: (bcc: James Day/Contractor/NPS) [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNS server...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
I'd have to do some more digging as to *why* the duplicate app-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFM feature to rollout the DCs. But prior to SP1 you couldn't add the application partitions to the dcpromo process (IFM in SP1 now offers an the options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created the DomainDnsZones app-partiontion right after their first reboot, causing some interesting challenges. Agree they should have contacted the DN master - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition. Anyways, to avoid similar issues, SP1 ensures that AD completes the replication with one partner prior to allowing the DNS service to read it's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs to advertise their GC status prior to finishing a replication cycle with another GC or one DC of every domain in their site. The challenge here is that you get into a race-condition when using the DC itself as the primary DNS server - ofcourse this will still work, but you have to wait for many more timeouts during the reboot of the AD DC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary until a DNS timeout... I've seen the boot-times of DCs go up to 10 and more minutes. This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are booted at once - consider this during your DR planning...) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Freitag, 14. Juli 2006 12:33 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I can't see how you can get a duplicate NDNC as the creation of such objects is targetted at the DN master. The DN master will check the existing crossRefs and stop this happening, as we can't rely on the DS stopping it as the RDN is different for each NDNC (unless they've used well-known GUIDs for the DNS NCs?). Although the behaviour you speak of is new to me, and another one of those slight, interesting changes, so thanks for that. Can you elaborate on this new behaviour? What, exactly, happens and in what order? --Paul - Original Message - From: Grillenmeier, Guido [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Thursday, July 13, 2006 6:52 PM Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it has successfully replicated with one of it's replication partners. This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replication partner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a race-condition when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used well-known GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: Grillenmeier, Guido [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until ithas successfully replicated with one of it's replication partners.This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replicationpartner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed toitself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory.I didsee in one environment where every DC had DNS and the msdcs partition was a forest partition.An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition.Replication started to fail shortly after that and the missing GUIDs were discovered.The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves.They could find themselves but not their replication partners.The replication partners could find them but notthemeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon servicewas restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
there was no need to check on this issue again - with SP1 it doesn't happen ;-) I'm sure there were several pre-SP1 fixes targeted at this issue and were then integrated into SP1. but rgd. the startup behaviour of DNS in SP1, I'm rather sure that's unchanged at this point. Would be happy to be corrected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Freitag, 14. Juli 2006 19:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a "race-condition" when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used "well-known" GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: "Grillenmeier, Guido" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until ithas successfully replicated with one of it's replication partners.This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replicationpartner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed toitself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the "Point your DNS server to a replication partner
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
I believe I covered most of this on a previous posting to ActiveDir but here are all of the details into what change was made and why: First of all the change that was made requires that an Initial Sync is completed before DNS will load the zones. This change was made after a customer reported a very nasty outage of all DNS records for one of their Domains. Needless to say with no DNS records many things break. So how and why did this happen. It turns out that many things have to come together but the end result is that we Conflict the MicrosoftDNS container, note not the application partition. This can occur do to a timing issue that was first seen when using an Install from Media (IFM) technique across a slow WAN link and of course you are not using the new feature in Windows Server 2003 SP1 that allows sourcing Application Partitions from media. Because Application Partitions have the lowest replication priority it was possible that the machine would register to host the DomainDNSZones application partition but never get a chance to replicate any information in do to it being pre-empted by higher priority Config and Domain partition replication. In that case if the timing was just right it was possible that the DNS server on this box would recreate the MicrosoftDNS container in order to store the root hints. This would of course replicate out and cause a CNF and since last writer wins you would end up with what looked like an empty MicrosoftDNS container, except for the root hints, which looked like corruption to all of the other DNS servers since they had records loaded from there at one point. To keep this from happening a requirement that the DC must perform an initial sync was put in place. This was the safest way to insure that we had replicated the necessary data in before trying to load zones and possibly conflict the MicrosoftDNS container. There were other places where this type of issue could pop up such as how we handle SOAs so the change was made. There is additional work being done in Windows Server Code Name Longhorn to help with this as well as other performance issues of loading large zones which caused slow DNS startup times. I have sent Email to the appropriate component owners so that they can revise if necessary our guidelines on how DNS should be configured for both Windows Server 2003 and the next version of the product. The only thing I would not recommend is removing the initial sync requirements by adding a registry value as this not only has affects on DNS but also the code that is used to insure that we do not have multiple machines believing that they are a particular FSMO owner. Here is the KB for the change that was introduced and rolled into SP1: http://support.microsoft.com/kb/836534/en-us . I have left out some of the hairy details as to exactly why the above happens as well as the customer who initially hit this, they know who they are. J Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, July 14, 2006 12:46 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicate app-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFM feature to rollout the DCs. But prior to SP1 you couldn't add the application partitions to the dcpromo process (IFM in SP1 now offers an the options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created the DomainDnsZones app-partiontion right after their first reboot, causing some interesting challenges. Agree they should have contacted the DN master - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition. Anyways, to avoid similar issues, SP1 ensures that AD completes the replication with one partner prior to allowing the DNS service to read it's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs to advertise their GC status prior to finishing a replication cycle with another GC or one DC of every domain in their site. The challenge here is that you get into a race-condition when using the DC itself as the primary DNS server - ofcourse this will still work, but you have to
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
just found the description of the error and the pre-SP1 hotfix to the duplicate DNS app-partitions issue: http://support.microsoft.com/kb/836534/en-us From: Grillenmeier, Guido Sent: Freitag, 14. Juli 2006 20:34To: 'ActiveDir@mail.activedir.org'Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? there was no need to check on this issue again - with SP1 it doesn't happen ;-) I'm sure there were several pre-SP1 fixes targeted at this issue and were then integrated into SP1. but rgd. the startup behaviour of DNS in SP1, I'm rather sure that's unchanged at this point. Would be happy to be corrected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Freitag, 14. Juli 2006 19:46To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a "race-condition" when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used "well-known" GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: "Grillenmeier, Guido" [EMAIL PROTECTED]To: ActiveDir@mail.activedir.orgSent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until ithas successfully replicated with one of it's replication partners.This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replicationpartner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Yeah, that looks a lot more familiar now. I recall working with several of the hotfixes for a similar issue. Thanks Guido and Steve for taking the time and Steve for suggesting to the owners that recommendations get updated. As I've mentioned before, the thinking changes but I'd still prefer to keep the DC a client of itself and to makeit thereforeas autonomous as possible. I can accept putting a centrally accessible DNS server in some other site as the secondary client. I can alsoaccept the reboot times Guido mentioned.The clients have other servers to use anyway andif the DC's are rebooting constantly or more frequently than monthly (patches and all) then I've got bigger issues to deal with. Al On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: just found the description of the error and the pre-SP1 hotfix to the duplicate DNS app-partitions issue: http://support.microsoft.com/kb/836534/en-us From: Grillenmeier, Guido Sent: Freitag, 14. Juli 2006 20:34 To: 'ActiveDir@mail.activedir.org ' Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? there was no need to check on this issue again - with SP1 it doesn't happen ;-) I'm sure there were several pre-SP1 fixes targeted at this issue and were then integrated into SP1. but rgd. the startup behaviour of DNS in SP1, I'm rather sure that's unchanged at this point. Would be happy to be corrected. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Al Mulnick Sent: Freitag, 14. Juli 2006 19:46 To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to allowing the DNS service to readit's records and to register anything. This is actually similar to the change that was done with either Win2000 SP2 or SP3 to avoid DCs toadvertise their GC status prior to finishing a replication cycle withanother GC or one DC of every domain in their site.The challenge here is that you get into a race-condition when using the DC itself as the primary DNS server - ofcourse this will still work,but you have to wait for many more timeouts during the reboot of the ADDC: for every DNS query prior to a successful replication, the DC will first try to query it's own DNS server and won't use the secondary untila DNS timeout...I've seen the boot-times of DCs go up to 10 and moreminutes.This can usually be fixed by setting the primary DNS server of the DC to another DNS server (naturally won't help, if both are bootedat once - consider this during your DR planning...)/Guido-Original Message-From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of Paul WilliamsSent: Freitag, 14. Juli 2006 12:33To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?I can't see how you can get a duplicate NDNC as the creation of such objectsis targetted at the DN master. The DN master will check the existingcrossRefs and stop this happening, as we can't rely on the DS stoppingit asthe RDN is different for each NDNC (unless they've used well-known GUIDsfor the DNS NCs?).Although the behaviour you speak of is new to me, and another one ofthoseslight, interesting changes, so thanks for that.Can you elaborate on this new behaviour?What, exactly, happens and in whatorder?--Paul- Original Message -From: Grillenmeier, Guido [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org Sent: Thursday, July 13, 2006 6:52 PMSubject: RE: [ActiveDir] Always point a DC with DNS installed to itselfasthe preferred DNS server...always? note that DNS startup behavious changes
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
thanks for the additional information Steve - I would also be interested to hear the official recommendation rgd. DNS configuration on DCs in Win2003 SP1/SP2 and Longhorn. /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve LinehanSent: Friday, July 14, 2006 8:41 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? I believe I covered most of this on a previous posting to ActiveDir but here are all of the details into what change was made and why: First of all the change that was made requires that an Initial Sync is completed before DNS will load the zones. This change was made after a customer reported a very nasty outage of all DNS records for one of their Domains. Needless to say with no DNS records many things break. So how and why did this happen. It turns out that many things have to come together but the end result is that we Conflict the MicrosoftDNS container, note not the application partition. This can occur do to a timing issue that was first seen when using an Install from Media (IFM) technique across a slow WAN link and of course you are not using the new feature in Windows Server 2003 SP1 that allows sourcing Application Partitions from media. Because Application Partitions have the lowest replication priority it was possible that the machine would register to host the DomainDNSZones application partition but never get a chance to replicate any information in do to it being pre-empted by higher priority Config and Domain partition replication. In that case if the timing was just right it was possible that the DNS server on this box would recreate the MicrosoftDNS container in order to store the root hints. This would of course replicate out and cause a CNF and since last writer wins you would end up with what looked like an empty MicrosoftDNS container, except for the root hints, which looked like corruption to all of the other DNS servers since they had records loaded from there at one point. To keep this from happening a requirement that the DC must perform an initial sync was put in place. This was the safest way to insure that we had replicated the necessary data in before trying to load zones and possibly conflict the MicrosoftDNS container. There were other places where this type of issue could pop up such as how we handle SOAs so the change was made. There is additional work being done in Windows Server Code Name Longhorn to help with this as well as other performance issues of loading large zones which caused slow DNS startup times. I have sent Email to the appropriate component owners so that they can revise if necessary our guidelines on how DNS should be configured for both Windows Server 2003 and the next version of the product. The only thing I would not recommend is removing the initial sync requirements by adding a registry value as this not only has affects on DNS but also the code that is used to insure that we do not have multiple machines believing that they are a particular FSMO owner. Here is the KB for the change that was introduced and rolled into SP1: http://support.microsoft.com/kb/836534/en-us . I have left out some of the hairy details as to exactly why the above happens as well as the customer who initially hit this, they know who they are. J Thanks, -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: Friday, July 14, 2006 12:46 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Guido, have you checked this lately? I know there were several changes to that behavior in several revs IIRC. The problems you describe were better than a challenge, as I recall. they had a tenedancy to wreak havoc with integrated dns zones when a dc would come up and create a new zone and then replicate that. There were several fixes related though and that behavior might have changed several times. On 7/14/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: I'd have to do some more digging as to *why* the duplicateapp-partitions were created, but I've had to troubleshoot this prior to SP1. This was during a global Win2003 DC rollout - we used the IFMfeature to rollout the DCs. But prior to SP1 you couldn't add theapplication partitions to the dcpromo process (IFM in SP1 now offers anthe options to include app partitions during the promotion). During this rollout a couple of DCs actually re-created theDomainDnsZones app-partiontion right after their first reboot, causingsome interesting challenges. Agree they should have contacted the DNmaster - not sure why either they didn't, or why the DN master allowed them to re-create this well-known app-partition.Anyways, to avoid similar issues, SP1 ensures that AD completes thereplication with one partner prior to
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
One point that is nearly always overlooked is the following, if a DC points to itself for DNS name res: The DNS server service starts *after* NETLOGON, at startup The DNS server service stops *before* NETLOGON, at shutdown i.e. at startup netlogon cannot register DNS records on the local machine until the DNS server starts (record reg may fail or be stalled / time out). at shutdown or during a demotion netlogon cannot un-register DNS records on the local machine since DNS server has stopped (demotion will leave DC records in tact). For these reasons alone - I always recommend that a DC points to another (local) DNS server (not necessarily a DC) and then itself as secondary (or maybe even tertiary). my 2 penneth, neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: 13 July 2006 02:59To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server.That'd be the best practice. Before 2003 you could have an "island effect" where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :) He'll try the neigbor first, because that's the preferred. He'll also register there etc. The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information. Now, will it work? Yes. Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the sounds of it, an unwillingness to fix the underlying issues that led them there as well. On the other hand, they're spot on if it's W2K vs. K3 :) Does that help? [1] unless you like a granular audit logging. But that'sneither here nor there. On 7/12/06, Victor W. [EMAIL PROTECTED] wrote: Today a conversation at my jobcame up about setting the preferred DNS server on the NIC of a DC with DNS installed. For as far as I know it's best topoint the DC (with DNS installed) to itself for DNS by specifying
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Al, This sure helped, we are by the way indeed talking about W2K DC's. Victor - Oorspronkelijk bericht - Van: Al Mulnick [EMAIL PROTECTED] Datum: donderdag, juli 13, 2006 3:58 am Onderwerp: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternateonly. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancementsabove and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND.Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client*to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'llhave one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization)and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configureyour DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice. Before 2003 you could have an island effect wherebecause you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectivelycreating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continueas a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the informationwhen he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :) He'll try the neigbor first, because that's the preferred. He'll also register there etc. The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information. Now, will it work? Yes. Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the sounds of it, an unwillingness to fix the underlying issues that led them there as well. On the other hand, they're spot on if it's W2K vs. K3 :) Does that help? [1] unless you like a granular audit logging. But that's neither here nor there. On 7/12/06, Victor W. [EMAIL PROTECTED] wrote: Today a conversation at my job came up about setting the preferred DNS server on the NIC of a DC with DNS installed. For as far as I know it's best to point the DC (with DNS installed) to itself for DNS by specifying the internal IP address of the DC as the preferred DNS server on the NIC. Then I was told that this is not always necessary and this puzzled me a bit. Not everybody was convinced of the above and this got me thinking. Some people are claiming that it doesnt really matter if you set that DC to be the *preferred* or the *alternate* DNS server. I was then showed an environment where all DC's in a child domain (all had DNS installed), had the same DNS server set as preferred DNS server. Perhaps an example will make it more clear: a forest root domain with 4
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
In that case, then you won't want to make the host a client of itself. Then you would/could run into the island effect. When you get to R2, you'll want to weigh Neil's comments and see how that plays in your environment. Al On 7/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Al,This sure helped, we are by the way indeed talking about W2K DC's.Victor- Oorspronkelijk bericht - Van: Al Mulnick [EMAIL PROTECTED]Datum: donderdag, juli 13, 2006 3:58 amOnderwerp: Re: [ActiveDir] Always point a DC with DNS installed toitself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternateonly. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?)Microsoft has done some enhancementsabove and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND.Active Directory plays very well with such third party DNS systems.You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone.You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client*to another DNS server that hosts the zones.You're also talking about making dc1 a client of dc2 and vice versa.That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'llhave one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization)and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configureyour DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice.Before 2003 you could have an island effect wherebecause you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectivelycreating an island of a DC.In 2003 some additional code was put in to make sure that doesn't happen.You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted.After replication completes, you have a full list and there's no need to continueas a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information?I find it amusing that if the server wants to find something he'll ask his neighbor if he has the informationwhen he could just ask himself.It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :)He'll try the neigbor first, because that's the preferred. He'll also register there etc.The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information. Now, will it work? Yes.Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the sounds of it, an unwillingness to fix the underlying issues that led them there as well. On the other hand, they're spot on if it's W2K vs. K3 :) Does that help? [1] unless you like a granular audit logging.But that's neither here nor there. On 7/12/06, Victor W. [EMAIL PROTECTED] wrote: Today a conversation at my job came up about setting the preferred DNS server on the NIC of a DC with DNS installed. For as far as I know it's best to point the DC (with DNS installed) to itself for DNS by specifying the internal IP address of the DC as the preferred DNS server on the NIC. Then I was told that this is not always necessary and this puzzled me a bit. Not everybody was convinced of the above and this got me thinking. Some people are claiming that it doesnt really matter if you set that DC to be the *preferred* or the *alternate* DNS server. I was then showed an environment where all DC's in a child domain (all had DNS installed), had the same DNS server set as preferred DNS server.
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Not unless you make Netlogon dependent on DNS in the startup order. That should be a standard practice. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /) (/ Microsoft MVP - Directory Serviceswww.readymaids.com - we know ITwww.akomolafe.com-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED]Sent: Thu 7/13/2006 1:20 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? One point that is nearly always overlooked is the following, if a DC points to itself for DNS name res: The DNS server service starts *after* NETLOGON, at startup The DNS server service stops *before* NETLOGON, at shutdown i.e. at startup netlogon cannot register DNS records on the local machine until the DNS server starts (record reg may fail or be stalled / time out). at shutdown or during a demotion netlogon cannot un-register DNS records on the local machine since DNS server has stopped (demotion will leave DC records in tact). For these reasons alone - I always recommend that a DC points to another (local) DNS server (not necessarily a DC) and then itself as secondary (or maybe even tertiary). my 2 penneth, neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: 13 July 2006 02:59To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server.That'd be the best practice. Before 2003 you could have an "island effect" where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :) He'll try the neigbor first, because that's the preferred. He'll also register there etc. The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information. Now, will it work? Yes. Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
I'd rather not make fundamental changes like that - I'd need to spend time testing, which I can better allocate to other tasks :) It's also not a "visible" change and one which may be overlooked and falls into my 'over engineering' bucket. :) neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji AkomolafeSent: 13 July 2006 15:11To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Not unless you make Netlogon dependent on DNS in the startup order. That should be a standard practice. Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_(_/ /) (/ Microsoft MVP - Directory Serviceswww.readymaids.com - we know ITwww.akomolafe.com-5.75, -3.23Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED]Sent: Thu 7/13/2006 1:20 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? One point that is nearly always overlooked is the following, if a DC points to itself for DNS name res: The DNS server service starts *after* NETLOGON, at startup The DNS server service stops *before* NETLOGON, at shutdown i.e. at startup netlogon cannot register DNS records on the local machine until the DNS server starts (record reg may fail or be stalled / time out). at shutdown or during a demotion netlogon cannot un-register DNS records on the local machine since DNS server has stopped (demotion will leave DC records in tact). For these reasons alone - I always recommend that a DC points to another (local) DNS server (not necessarily a DC) and then itself as secondary (or maybe even tertiary). my 2 penneth, neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: 13 July 2006 02:59To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server.That'd be the best practice. Before 2003 you could have an "island effect" where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when the WAN link dropped for a length of time and the primary DNS server was not reachable. Of course, if there are never any changes to DC IPs or names and the MSDCS is never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent by: cc: (bcc: James Day/Contractor/NPS) [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNS server...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Don't domain controllers register their SRV records with both primary and secondary DNS? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:02 AM To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when the WAN link dropped for a length of time and the primary DNS server was not reachable. Of course, if there are never any changes to DC IPs or names and the MSDCS is never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent by: cc: (bcc: James Day/Contractor/NPS) [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNS server...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice. Before 2003 you could have an island effect where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
note that DNS startup behavious changes with SP1, which is another reason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it has successfully replicated with one of it's replication partners. This is to avoid false or duplicate registration of records (or even duplicate creation of the application partitions). As such, with SP1 it's better to point your DCs to a replication partner as a primary DNS and to self as a secondary. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Donnerstag, 13. Juli 2006 17:02 To: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? Hi Al I did want to throw in a personl experience I had with W2K3 that validates the Point your DNS server to a replication partner theory. I did see in one environment where every DC had DNS and the msdcs partition was a forest partition. An unfortunate DNS scavenge was done deleting some of the GUID records in the MSCDCS partition. Replication started to fail shortly after that and the missing GUIDs were discovered. The netlogon service was restarted to make the DCs re-register but of course they re-registered the GUID on themselves. They could find themselves but not their replication partners. The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primary and themselves as secondary the problem went away - the netlogon service was restarted, the GUIDs registered on the central DNS server, the spokes did the lookup for replication parnters on the hub site DC and eventually things started working again. This was pre - SP1 so this may not be a problem anymore, but after that experience I have seen value in doing the DNS configuration so that the DCs all point to the hub first and themselves second. I have not seen any problems for the DC itself when the WAN link dropped for a length of time and the primary DNS server was not reachable. Of course, if there are never any changes to DC IPs or names and the MSDCS is never scavenged (or the interval is long enough not to recreate the above problem) then the above argument is moot. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service 202-230-2983 [EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent by: cc: (bcc: James Day/Contractor/NPS) [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNS server...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;) There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice. Before 2003 you could have an
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but I detest the idea of a DNS server being a client to a peer name res server. I'm still inclined to continue to use the self-as-primary deployment. I understand that silliness (thanks for pointing out that situation James) can impact availability and that would normally indicate a bad design. I'm curious though, why in the situation described that the server couldn't replicate and begin serving records. I haven't looked lately, but how many replication partners does it have to talk to before it will serve DNS? I'm looking for server x. Do you have it? Hello? Are you there? No? Let me check myself then. It also goes against the idea that each name res server should have as much of a complete picture of the environment as possible else there's no reason to have multiples. Hmm... On 7/13/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: note that DNS startup behavious changes with SP1, which is anotherreason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it hassuccessfully replicated with one of it's replication partners.This isto avoid false or duplicate registration of records (or even duplicate creation of the application partitions).As such, with SP1 it's better to point your DCs to a replication partneras a primary DNS and to self as a secondary./Guido-Original Message- From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]Sent: Donnerstag, 13. Juli 2006 17:02To: ActiveDir@mail.activedir.orgCc: ActiveDir@mail.activedir.org ; [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?Hi Al I did want to throw in a personl experience I had with W2K3 thatvalidatesthe Point your DNS server to a replication partner theory.I did seeinone environment where every DC had DNS and the msdcs partition was a forestpartition.An unfortunate DNS scavenge was done deleting some of theGUIDrecords in the MSCDCS partition.Replication started to fail shortlyafterthat and the missing GUIDs were discovered.The netlogon service was restarted to make the DCs re-register but of course they re-registeredtheGUID on themselves.They could find themselves but not theirreplicationpartners.The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primaryandthemselves as secondary the problem went away - the netlogon service wasrestarted, the GUIDs registered on the central DNS server, the spokes didthe lookup for replication parnters on the hub site DC and eventuallythings started working again.This was pre - SP1 so this may not be a problem anymore, but after thatexperience I have seen value in doing the DNS configuration so that the DCsall point to the hub first and themselves second.I have not seen anyproblems for the DC itself when the WAN link dropped for a length oftimeand the primary DNS server was not reachable.Of course, if there are never any changes to DC IPs or names and the MSDCSis never scavenged (or the interval is long enough not to recreate theabove problem) then the above argument is moot.Regards;James R. DayActive Directory Core TeamOffice of the Chief Information Officer National Park Service202-230-2983[EMAIL PROTECTED] Al Mulnick [EMAIL PROTECTED] To:ActiveDir@mail.activedir.org Sent by: cc: (bcc:James Day/Contractor/NPS) [EMAIL PROTECTED]Subject:Re:[ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNSserver...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;)There are many many many ways to properly configure DNS.One thing thathelps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternateserver that you want this DC to be a client of.DNS is a standard.Windows 2003 DNS follows those standards (commentsreally, but let's not pick right?)Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoftsphere[1].You can however have DNS that is a third party DNS system, such as BIND.Active Directory plays very well with such third party DNS systems.You could have your domain controllers not have any DNS hosted on them atall.You could have it hosted, but as a secondary zone.You could also haveitAD integrated meaning that you have a listener for DNS but the data(base)is stored in the active directory.Something to clarify: what you're talking about is making the DC a*client*to another DNS server that hosts the zones.You're also talking aboutmaking dc1 a client of dc2 and vice versa.That's silly, but I'll get tothat.If you have your dns hosted on a third party system such as BIND, you'llhave one server as the primary (not best
RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Great input, it's really getting more and more interesting, I'm glad I raised the question. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al MulnickSent: donderdag 13 juli 2006 21:32To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always? See how quickly thinking changes? :) I almost think this is a better reason not to have AD-integrated DNS. Shall have to ponder a bit more, but I detest the idea of a DNS server being a client to a peer name res server. I'm still inclined to continue to use the self-as-primary deployment. I understand that silliness (thanks for pointing out that situation James) can impact availability and that would normally indicate a bad design. I'm curious though, why in the situation described that the server couldn't replicate and begin serving records. I haven't looked lately, but how many replication partners does it have to talk to before it will serve DNS? "I'm looking for server x. Do you have it? Hello? Are you there? No? Let me check myself then." It also goes against the idea that each name res server should have as much of a complete picture of the environment as possible else there's no reason to have multiples. Hmm... On 7/13/06, Grillenmeier, Guido [EMAIL PROTECTED] wrote: note that DNS startup behavious changes with SP1, which is anotherreason not to choose the DC itself as the preferred DNS server: with SP1, AD will not allow the DNS service to read any records, until it hassuccessfully replicated with one of it's replication partners.This isto avoid false or duplicate registration of records (or even duplicate creation of the application partitions).As such, with SP1 it's better to point your DCs to a replication partneras a primary DNS and to self as a secondary./Guido-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of[EMAIL PROTECTED]Sent: Donnerstag, 13. Juli 2006 17:02To: ActiveDir@mail.activedir.orgCc: ActiveDir@mail.activedir.org ; [EMAIL PROTECTED]Subject: Re: [ActiveDir] Always point a DC with DNS installed to itselfas the preferred DNS server...always?Hi Al I did want to throw in a personl experience I had with W2K3 thatvalidatesthe "Point your DNS server to a replication partner theory".I did seeinone environment where every DC had DNS and the msdcs partition was a forestpartition.An unfortunate DNS scavenge was done deleting some of theGUIDrecords in the MSCDCS partition.Replication started to fail shortlyafterthat and the missing GUIDs were discovered.The netlogon service was restarted to make the DCs re-register but of course they re-registeredtheGUID on themselves.They could find themselves but not theirreplicationpartners.The replication partners could find them but not themeselves. When the DCs were set to point to a hub replication partner for primaryandthemselves as secondary the problem went away - the netlogon service wasrestarted, the GUIDs registered on the central DNS server, the spokes didthe lookup for replication parnters on the hub site DC and eventuallythings started working again.This was pre - SP1 so this may not be a problem anymore, but after thatexperience I have seen value in doing the DNS configuration so that the DCsall point to the hub first and themselves second.I have not seen anyproblems for the DC itself when the WAN link dropped for a length oftimeand the primary DNS server was not reachable.Of course, if there are never any changes to DC IPs or names and the MSDCSis never scavenged (or the interval is long enough not to recreate theabove problem) then the above argument is moot.Regards;James R. DayActive Directory Core TeamOffice of the Chief Information Officer National Park Service202-230-2983[EMAIL PROTECTED] "Al Mulnick" [EMAIL PROTECTED] To:ActiveDir@mail.activedir.org Sent by: cc: (bcc:James Day/Contractor/NPS) [EMAIL PROTECTED]Subject:Re:[ActiveDir] Always point a DC with DNS installed to itself as the tivedir.org preferred DNSserver...always? 07/12/2006 09:58 PM AST Please respond to ActiveDir You don't work at the post office do you? ;)There are many many many ways to properly configure DNS.One thing thathelps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternateserver that you want this DC to be a client of.DNS is a standard.Windows 2003 DNS follows those standards (commentsreally, but let's not pick right?)Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoftsphere[1].You can however have DNS that is a third party DNS system, such as BIND.Active Directory plays very well with such third party DNS systems.You
[ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
Today a conversation at my jobcame up about setting the preferred DNS server on the NIC of a DC with DNS installed. For as far as I know it's best topoint the DC (with DNS installed) to itself for DNS by specifying the internal IP address of the DC as the preferred DNS server on the NIC. Then I was told that this is not always necessary and this puzzled me a bit. Not everybody was convinced of the above and this got me thinking. Some people are claiming thatit doesnt really matter if you set that DC to bethe preferred or the alternate DNS server. I was then showed an environment where all DC's in a child domain (all had DNS installed), had the same DNS server set as preferred DNS server. Perhaps anexample will make it more clear: a forest root domain with 4 child domains. child domain A, B, C, and D. Names of the Domain Controllers: root domain: DC-A DC-B DC-C DC-D for child domain A: DC-A1 DC-A2 for child domain B: DC-B1 DC-B2 for child domain C: DC-C1 DC-C2 for child domain D: DC-D1 DC-D2 DC-A1 has specified DC-A2 as preferred DNS server and has specified DC-A1 (itself) as alternate DNS server. DC-A2 has specified DC-A2 (itself) as preferred DNS server and has specified DC-A1 as alternate DNS server DC-B1 has specified DC-B2 as preferred DNS server and has specified DC-B1 (itself) as alternate DNS server DC-B2 has specified DC-B2 (itself) as preferred DNS server and has specified DC-B1 as alternate DNS server And so on for the other child domains. I was told that thiswas done because this ADenvironment wasnot optimaland that bypointing all the dc's ina child domain to the same DNS server, other issues were prevented from occuring. This didnt sound all that good to me to be honoust :-) I am now wondering if there arescenario's thinkable when it would be betternot to point a DC with DNS installed as the preferred server on it's NIC. Does the term Island DNS also play a role in this?
Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
You don't work at the post office do you? ;) There are many many many ways to properly configure DNS.One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of. DNS is a standard.Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory. Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that. If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system. If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers. If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server.That'd be the best practice. Before 2003 you could have an island effect where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do. So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :) He'll try the neigbor first, because that's the preferred. He'll also register there etc. The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information. Now, will it work? Yes. Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the sounds of it, an unwillingness to fix the underlying issues that led them there as well. On the other hand, they're spot on if it's W2K vs. K3 :) Does that help? [1] unless you like a granular audit logging. But that'sneither here nor there. On 7/12/06, Victor W. [EMAIL PROTECTED] wrote: Today a conversation at my jobcame up about setting the preferred DNS server on the NIC of a DC with DNS installed. For as far as I know it's best topoint the DC (with DNS installed) to itself for DNS by specifying the internal IP address of the DC as the preferred DNS server on the NIC. Then I was told that this is not always necessary and this puzzled me a bit. Not everybody was convinced of the above and this got me thinking. Some people are claiming thatit doesnt really matter if you set that DC to bethe preferred or the alternate DNS server. I was then showed an environment where all DC's in a child domain (all had DNS installed), had the same DNS server set as preferred DNS server. Perhaps anexample will make it more clear: a forest root domain with 4 child domains. child domain A, B, C, and D. Names of the Domain Controllers: root domain: DC-A DC-B DC-C DC-D for child domain A: DC-A1 DC-A2 for child domain B: DC-B1 DC-B2 for child domain C: DC-C1 DC-C2 for child domain D: DC-D1 DC-D2 DC-A1 has specified DC-A2 as preferred DNS server and has specified DC-A1 (itself) as alternate DNS server. DC-A2 has specified DC-A2 (itself) as preferred DNS server and has specified DC-A1 as alternate DNS server DC-B1 has specified DC-B2 as
