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
