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