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