Sorry, should have read *AFTER* replication has occurred.
If you use itself prior to replication of DNS records, then you have created a
naming island as described.
Isn't your DC sometimes a *client* of the DNS
service? It is for some functions of authentication. See below for
more detail.
"Doesn't it store all the DNS entries it needs in its own
active directory integrated DNS local on the domain controller in order to
allow the users to continue to login? "
Yes it does store the same exact data that the central DNS
server does. But it's configured to look across the WAN link for it's name
resolution meaning that when it's asked for an address it can give it, but when
the DC asks for an address it never asks itself, and fails to get a
response explaining the entries you recvd and the errors logging in to networked
resources including rebooted workstations that needed new
tickets.
"I somewhat understand what you're saying, but if the
clients DNS is responding since the DNS is local, why does the DNS server need
to connect to DNS in order for them to map drives to local resources and be able
to login?"
The DNS server is not connecting to DNS. That's
likely the confusion. It is the DC that is connecting to name resolution
which happens to be on the same machine and integrated in Active Directory (the
DC is a *client* in this situation). When that breaks, so does your
authentication.
For reference: http://support.microsoft.com/kb/q266080/ (note
that your DNS is not working when the WAN link goes down, even though you have a
full copy on that DC; you've configured it not to trust that copy but instead go
to another server across the down link. Your clients can find resources because
they have connection to a working copy still, right?)
Question
How does Windows 2000 locate the Key Distribution Centers (KDCs)?Answer
Windows 2000 clients use Domain Name System (DNS) SRV records to locate domain controllers in a domain, and they attempt to resolve the _ldap._tcp.dc._msdcs SRV records. Windows 2000 domain controllers also publish SRV records for _kerberos and _kpasswd services. The list of published SRV records can be found on a domain controller in the following file:%Windir%\System32\Config\Netlogon.dns
Make more
sense?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Thursday, October 14, 2004 4:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
You said
"If you don't use the same
server as itself for DNS resolution replication has occurred, then when the WAN
link goes down, your workstations cannot find the resources they need to
authenticate. "
Did you mean "BEFORE"
replication has occurred? (I'm not sure what word was left out).
These sites have been up for many months, so replication has occurred multiple
times. Why does the remote site's DC/DNS need DNS in order for its local
clients to authenticate? Doesn't it store all the DNS entries it needs in
its own active directory integrated DNS local on the domain controller in
order to allow the users to continue to login? I somewhat understand
what you're saying, but if the clients DNS is responding since the DNS is local,
why does the DNS server need to connect to DNS in order for them to map drives
to local resources and be able to login?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Thursday, October 14, 2004 1:09 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
From http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&id=kb;en-us;275278 (see
note in method 1 below).
NOTE:
This implementation process may not be suitable if the server that functions as
the primary server is subject to heavy loads or the domain controllers in the
forest root are geographically dispersed.
So the
issue you face is this: Name resolution must continue in the event that the
WAN link fails.
Since
your DC is using an off-site host for DNS, this cannot possibly work.
Unless your DC knows how to find an alternate route through thin air anyway
:)
If you
don't use the same server as itself for DNS resolution replication has occurred,
then when the WAN link goes down, your workstations cannot find the resources
they need to authenticate.
Result? you end up with a down site until the WAN
link comes back.
Your
possible solutions look like this:
Either
put a second DNS in that remote site with the full zone information and let
them use each other for resolution to avoid a possible island issue during
DCPromo events or human error, or put all of the records on the remote DC and
let it become an authentication 'island' in the case that the WAN link goes
down.
As
long as nothing changes during the WAN link outage, specifically the DNS
zone information for DC location, then you should resume normal operations
when the link comes back as long as it's not so long that garbage collection
kicks in (60 days by default).
In
short, islanding is really only a problem when you first create a DC (dcpromo)
or when you make a human mistake and remove the records needed. WAN links
are more of a threat in this case based on the information
posted.
Test,
Test, Test, and then run it through testing to make sure you have the
results you want.
Al
