AD & DNS??

[Michael E. Hanson]

Personally, I'd have to side with M$ on this one.  If your client PCs =
are to be members of the AD Domain Microstuff.net, then their FQDNs MUST =
be <clienthostname>.<optionalsubdomainname.>Microstuff.net.  The clients =
must also look to their configured DNS server to find the appropriate =
SRV records for the domain/site they are in.  They (the clients) will =
not look one place for the SRV records and another place for normal name =
resolution.  Therefore, whatever solution you provide must include a DNS =
solution that provides both simple name/address resolution and SRV =
resolution from the same server.

However, with the size of your user base, and the implication that it is =
distributed geographically, I would not recommend a single global =
domain.  My recommendation would be to create an AD forest (what you =
called Microstuff.net) with a subdomain for each major geographic =
location.  Further, I would recommend that you set up AD sites for each =
geographic location, each with their own TCP/IP subnet.  This permits =
you to group services (such as DHCP, DNS, AD DC, Applications Servers, =
SMTP relay, etc.) and administration (assuming you have the IT =
department to support it) by geographic area.

If you also have internet connectivity, a public Web/FTP server, and are =
providing your users access to the internet, then I would create a DMZ =
(if you don't already have one) and place a separate and independent DNS =
server in the DMZ strictly to handle DNS requests from the internet for =
your public namespace.  It can also be the forwarder for your internal =
DNS to handle DNS requests for internet addresses from your users, but =
this isn't strictly necessary.  I usually setup this external DNS as a =
BIND DNS, but I would assume QIP or Nomimium would handle the job also.

Which brings me to my last point.  From a security standpoint, you =
probably want to keep your internal and external namespaces separate and =
distinct.  Many security people get nervous (or downright nasty) when AD =
SRV records get exposed to the public.  For this reason alone you might =
be forced into the M$ solution for your internal network.

You might also consider hiring an outside consultant, one who's =
qualified/certified in M$ and is also an experienced internetworking =
engineer.  Microsoft Consulting Services will always give you the strict =
M$ solution and party-line of it can be made to work, and that's not =
always the right or best solution.

Hope this helps...
_______________
Michael E. Hanson
President, Gryphon Consulting Services
(http://www.GryphonsGate.com)
P.O. Box 1151
Bellevue, NE 68005-1151
(402) 871-9622

MEHanson at GryphonsGate.com (primary)
Gryphons_Master at yahoo.com


----- Original Message -----=20
From: "fih" <frhak at hotmail.com>
Newsgroups: comp.protocols.dns.bind
To: <comp-protocols-dns-bind at isc.org>
Sent: Sunday, January 18, 2004 8:29 AM
Subject: AD & DNS??


Hello guys!

I like to start a conversation regarding DNS and AD. I like to get in
contact with people running DNS for companies with more than 20000 =
hosts.

Basically these are the facts:

At our 60000 users company it's blowing a heavy Microsoft Active =
Directory
wind. Microsoft have recommended our AD team to create one global AD =
zone,
we can call it microstuff.net. We are also currently using a =
geographical
DNS namespace under our own root name servers. We manage our =
geographical
and reverse zones with QIP. (We have lately been looking at Nominums =
very
interesting DNS solution, which might replace QIP in the future)

My thinking was that I will delegate microstuff.net to AD DNS servers =
and
they would have their SRV records in their huge global zone, and the
A-records would be located in the geographical zone as usual with PTR
pointing back to the GEO zone. In my world this would be a good DNS
solution, except for maybe the global SRV record zone.

When I have been discussing this with Microsoft they recommend us to =
have AD
members A-records in the global AD zone microstuff.net along with the =
SRV
records, because programmers some times takes for granted that the =
A-records
exists in the same zone as the SRV records.

We have been discussing three solutions:

1. A-records in geographical zones with corresponding PTR records. SRV
records in the AD zone microstuff.net. (This is what I want but is
depreciated by Microsoft)

2. A-records and SRV-records in microstuff.net and corresponding
PTR-records. (This is what Microsoft wants)

3. A-records in geographical zones with corresponding PTR records. SRV
records in the AD zone microstuff.net + an extra A-record for each AD =
member
in microstuff.net. (This is a terrible compromise since all AD members =
will
have two A-records and one PTR record.)

I like to know how other great companies have solved this.