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 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; ActiveDir- > [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 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'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 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 this was done because this AD environment was not > > optimal > > and that by pointing all the dc's in a 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 are scenario's thinkable when it > would be > > better not 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? > > > > > > > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: http://www.activedir.org/ml/threads.aspx > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: http://www.activedir.org/ml/threads.aspx > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > > > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
