|
Thanks Jorge and Deji for your responses. It sounds like we’re all pretty much of the same opinion, i.e.
that there will be a sequence of attempts against a list of DCs in Forest B.
It would still be good to understand the how the DNS interactions work in
this situation. I’ve searched around for documentation, but with no
success so far. Tweaking the DC locator records for the DCs in the Forest B domain
sounds like an interesting idea. I suspect some adjustmens to SRV
priority might do the trick. As you indicate, I would need to find a way
of doing this such that it doesn’t impact anything else. Tony From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto,
Jorge de I would think the client receives a list of referrals and use
the DC on top of the list and goes down the list until it finds a DC that
responds. A client simply does not know why a certain DC does not respond. It
can be anything... firewall, network, DC down or whatever. As there is no sites and subnets synchronization in place yet the
DC retrieving the referral does not know in which site to query for a DC, it
will query for the DCs in a certain domain. Do you have the possibility to
tweak the registration of domain wide DC locator records for the DCs in forest
B that are not reachable (taking into account that it does not impact services
in forest B) Cheers, Jorge From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Hi
all Need
a bit of help with this one. Here’s the scenario. Two
Windows Server 2003 forests federated with a cross forest trust. Forest A
has 4 DCs, all of which are reachable from Forest B. Forest B has approx.
30 DC, of which only those in main site (10) are reachable from Forest
A’s network. There is no site and subnet synchronisation in
place. My
concern is that not all the DCs in Forest B are reachable from Forest A
((because network routes are only in place to the main site). DNS
secondary zones are being used and these obviously contain information about
the unreachable DCs in Forest B. What happens when a client in Forest A
need to access a resource in Forest B? The routing of Kerberos
authentication requires DNS lookups for DCs in Forest B. If the client in
Forest A receives a referral to an unreachable DC in Forest B, does the request
simply fail or is there some built-in intelligent retry mechanism? In
other words will the client in Forest A eventually be referred to a reachable
DC? I
realise there are long term solutions to this (site and subnet synchronisation,
the addition of network routes), but I am keen to understand the DNS
interactions so I can determine whether this will work in the short term. Tony This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this communication
or disclose anything about it. Thank you. Please note that this communication
does not designate an information system for the purposes of the Electronic
Transactions Act 2002. This
e-mail and any attachment is for authorised use by the intended recipient(s)
only. It may contain proprietary material, confidential information and/or be
subject to legal privilege. It should not be copied, disclosed to, retained or
used by, any other party. If you are not an intended recipient then please
promptly delete this e-mail and any attachment and all copies and inform the
sender. Thank you. |
- RE: [ActiveDir] Cross forest trust and DNS Tony Murray
- RE: [ActiveDir] Cross forest trust and DNS Almeida Pinto, Jorge de
- RE: [ActiveDir] Cross forest trust and DNS Bernard, Aric
- RE: [ActiveDir] Cross forest trust and DNS Tony Murray
- RE: [ActiveDir] Cross forest trust and DNS Bernard, Aric
- RE: [ActiveDir] Cross forest trust and DNS Tony Murray
- RE: [ActiveDir] Cross forest trust and DNS Almeida Pinto, Jorge de
- RE: [ActiveDir] Cross forest trust and DN... Tony Murray
- RE: [ActiveDir] Cross forest trust and DNS neil.ruston
- RE: [ActiveDir] Cross forest trust and DNS Bernard, Aric
