On Fri, Aug 20, 2010 at 12:52 PM, Jim Dandy <[email protected]> wrote:
> I'm pretty sure we have what you refer to as split DNS.
> We have AD Integrated DNS but it isn't accessible outside the
> subnet/firewall. A few hosts are registered with the campus DNS
> and are discoverable by the outside world but the rest are not.
Okay, you can either change your policy to make both AD domains
resolvable from the public 'net in general, or you can find a way to
make just those two AD domains resolvable from each other's systems.
The later is probabbly the best choice. Conditional forwarding will
get you that. So will stub zones, as others suggested.
Note that if your "public records" are deliberately different from
your "records in AD" (e.g., because firewall policy or NAT means you
need different IP addresses depending on which side of the firewall
you're on), then you're probabbly in for some pain.
> Let's say my domain is A and the other department's domain is B. Could I
> add b.ucdavis.edu with an IP address of their domain controller to my DNS
> and a.ucdavis.edu to their DNS?
A zone of authority is more than an IP address. (Specifically, it's
an SOA record and some NS records.) In order for your systems in "a"
to answer queries for "b", your systems in "a" need to believe they
are authoritative for <b.ucdavis.edu.> or <ucdavis.edu>. You don't
want to claim <ucdavis.edu> for obvious reasons. Claiming
<b.ucdavis.edu.> using standard DNS mechanisms won't help you, because
then your systems in "a" will be expected to know *all* answers for
<b.ucdavis.edu.>.
Conditional forwarding lets you tell your DNS servers to forward
queries for <b.ucdavis.edu.> to systems in "b". A stub zone is a
"fake" zone which intercepts queries for <b.ucdavis.edu.> and gives
out the SOA and NS for systems in "b"; the rest of the queries will
then go to systems in "b" naturally. They both have the same
requirements and the same end results.
> Perhaps another approach would be to include the DNS server of the other
> department's DNS as a secondary DNS server?
Do *NOT* attempt this. DNS doesn't work that way. The DNS client
resolver tries the first DNS server you've got configured. If that
DNS server responds with NXDOMAIN (non-existent domain), that's a
proper answer, and the client resolver stops there. It doesn't go ask
other servers just to see if they give a different answer. The only
time the resolver tries different DNS servers is if one isn't
responding at all.
> Yes, there is a router between the two subnets. I threw in that detail
> thinking that browsing across subnets might be more complicated.
Do you mean NetBIOS browsing ("Network Neighborhood", "Computers
Near Me", etc.)? If so, yes, that will need something. You'll need
one or more WINS servers, and all clients configured to use the same
set of WINS servers. (WINS isn't distributed like DNS is; all servers
have to have everything.)
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
