Significance of the First DC

  • Thread starter Thread starter Ron
  • Start date Start date
R

Ron

Q articles regarding DNS suggest state that all additional
DCs running DNS should have the first DC as primary and
point to themselves as secondary. Anybody know the
reasoning behind this and are there other properties
attributed to the first DC besides the FSMO roles
originally residing there.
 
Ron said:
Q articles regarding DNS suggest state that all additional
DCs running DNS should have the first DC as primary and
point to themselves as secondary. Anybody know the
reasoning behind this and are there other properties
attributed to the first DC besides the FSMO roles
originally residing there.

It's a poor generalization. It is either too general or needs to be
read in the specific context of the article.

When you have a single Primary DNS server with Secondaries servers
on the other "DCs", they are going to have to register themselves with
that Primary and so might as well list is as PREFERRED (not primary)
with themselves as ALTERNATE (not secondary.)

When you have a distributed Site layout with multiple AD Integrated DCs
you seldom want the local DC to use another Site's DC-DNS server.

The recommendation applies mainly to "small domains, single site, beginning
admins".

The reason for including "beginning admins" is that once you go to a fully
distributed model the Admin must both UNDERSTAND and MAINTAIN
both AD and DNS replication (separately or together) and the simple
recommendations protects those who don't yet have those skills or knowledge.

(Or sometimes enough time to worry about it. <grin>)
 
In
Ron said:
Q articles regarding DNS suggest state that all additional
DCs running DNS should have the first DC as primary and
point to themselves as secondary. Anybody know the
reasoning behind this and are there other properties
attributed to the first DC besides the FSMO roles
originally residing there.

I think you mean this:

Assuming that you have two DCs with DNS on them and both are AD Integrated
zones:

DC1's IP properties
1st DNS address: DC2
2nd DNS address: DC1

DC2's IP properties:
1st DNS address: DC1
2nd DNS address: DC2

If this is what you're talking about, this eliminates two issues if you
point to itself as the first:

1. DNS becomes an Island. This is where the _msdcs zone does not replicate
to other DNS servers in an AD Integrated scenario. Granted a previous SP
fixed this, but we like to do it as I illustrated above for best practice to
eliminate any possiblity this will occur.

2. Eliminates 5781 and 5782 errors during bootup, where basically it says
that there are no DNS server are available to register into. This is
*normally* caused by the zone being in AD, and the AD database has not quite
initialized while the netlogon service is trying to register into the zone.
Maybe the machine is slow or overloaded with services would tend to generate
that error. If pointing to it's partner DC's DNS, this will eiliminate it.

There are articles on this, but this is pretty much a summary.

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
Thanks. The Q I'm referencing is 291382. Reading it,
your comments regarding smaller sites and domains makes
sense as the article starts discussing single DNS server
setups. Primary/secondary is something I "added" since
I've been dealing with WINS a lot lately but isn't it
really semantics? If we're saying that we should use
another DNS server as the "preferred" server, aren't we
saying that it will dynamically register with that other
DNS and then rely on AD replication (assuming integrated
DNS) to add its records to its own DNS table? Wouldn't it
make more sense to have itself as the preferred server, or
is it because DNS is likely not up at that point that it
wouldn't be able to register itself?
 
Thanks. The Q I'm referencing is 291382. Reading it,
your comments regarding smaller sites and domains makes
sense as the article starts discussing single DNS server
setups. Primary/secondary is something I "added" since
I've been dealing with WINS a lot lately but isn't it
really semantics?

Yes, and "semantics" is the study of MEANING so it frequently
an important topic to get straight -- the oft heard (I even say it),
"We are only arguing semantics." refers to the case where two
people are both clear on the NEXT STEP but saying it differently
or one/both of the are just misinterpreting the words.

In this case (not your fault) the words are already heavily overloaded
with TECHNICAL semantic meaning and it is just too confusing for
beginners (or for experts trying to help them) if "DNS Primary for a Zone"
is conflated with "the client's DNS preferred server".
If we're saying that we should use
another DNS server as the "preferred" server, aren't we
saying that it will dynamically register with that other
DNS and then rely on AD replication (assuming integrated
DNS) to add its records to its own DNS table?

Yes (but only if both servers are AD Integrated) because if the client is
using a Secondary as a preferred server it's registration must actually be
sent to THE Primary, then zone transferred back to the Secondary.

Primaries (and AD Integrated) can change the DNS zone file; secondaries
ARE "authoritative" for their zone but cannot change it, only copy it from
another (any other) DNS server of that same zone.
Wouldn't it
make more sense to have itself as the preferred server, or
is it because DNS is likely not up at that point that it
wouldn't be able to register itself?

I generally prefer it to be it's own preferred server -- so we agree on
this.
(Others do not -- e.g., that article you quote.)

Their thinking (not totally wrong) is if both AD-DNS servers use and
register
with the OPPOSITE, then at least they can find each other.

It is actually (somewhat) wrong - -since if the OTHER DNS server doesn't
include "itself" (the other DC too) it will not be there for the first to
resolve.

Might as well do it right and ensure replication at the start. (My theory.)

OCCASIONALLY, when two AD-DNS servers lose contact (extended down
of a WAN etc.) I will point BOTH of them at #1, cycle NetLogon, then point
BOTH of them at #2, cycle NetLogon AGAIN, and then point each at itself
as primary.

Now they both have each other registered, and vice versa.

You seem to understand the issue and that was apparently the thrust of your
original question....
 
Back
Top