AD & DNS??

[Michael E. Hanson]

Having the SRV and A records in different DNS zones is fine as far as =
DNS is concerned so long as the clients can get both answers from one =
DNS server.  But for AD, the client needs to be in the same domain as =
their AD Domain Controller (which must be in the AD Domain its serving), =
and the SRV records they are going to query will be those for their =
respective AD Domain.  Therefore, both the clients A records and the SRV =
records must be in the same AD Domain.  And since the AD Domain =
corresponds to a DNS zone, they must be in the same DNS zone.

Microsoft's network is actually setup just as I described earlier, with =
one large forest that has multiple subdomains to group the various =
departments and major geographical regions, and sites to group the =
various geographical locations and their services.

Your AD team is correct that many applications also rely on the client's =
being in the same domain as the AD domain they are a member of, and that =
only makes sense.  It is not sensible for a client to expect services =
from the "Microstuff.net" domain if they are a member of the =
"FreddyKrueger.org" domain.

BTW, with the advent of AD, the Microsoft domain is NOT a NetBIOS =
namespace (unless the admin chooses to make it so by bringing up a WINS =
server), it is a TCP/IP namespace relying on DNS as its primary =
name/address resolution service.

_______________
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

=20
----- 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 2:05 PM
Subject: Re: AD & DNS??


Thank you very much for writing such a long and contemplative answer.

Still i don't understand why they have created a solution where =
A-records
must be located in the same domain as the SRV records. In my opinion =
this
must cause a lot of trouble for huge companies trying to migrate an old =
DNS
solution to fit  into AD. With regards to DNS having SRV records in one
domain and A-records in another is perfectly fine. With all your respect
clients don't have to ask anywhere else to resolve either A or SRV =
records.
All DNS servers within our enterprise share the same root nameservers =
and
should be able to resolve all internal FQDN. Our AD team claims that the
reason for the need of A and SRV records in the same domain are due to =
many
applications needs it, one example should be SMS.

I don't know AD so i need to trust our AD team and they have together =
with
Microsoft decided upon the global domain. But i must say that your words
sounds very much like my own thoughts. To me this global zone sounds =
like
going 20 years back and the use of a huge host file alternatively =
keeping
the WINS solution. Some say that Microsoft uses one global zone them =
selves.
I also heard that they had to build their own DNS management system,
probably since they got tired of always have to put a brick on the "down
arrow" to get to the bottom of the list when trying to manage their =
domain.
;-))

Please continue the discussion!




"Michael E. Hanson" <MEHanson at GryphonsGate.com> skrev i meddelandet
news:buelbr$2ff5$1 at sf1.isc.org...
> Personally, I'd have to side with M$ on this one.  If your client PCs =
=3D
> are to be members of the AD Domain Microstuff.net, then their FQDNs =
MUST =3D
> be <clienthostname>.<optionalsubdomainname.>Microstuff.net.  The =
clients =3D
> must also look to their configured DNS server to find the appropriate =
=3D
> SRV records for the domain/site they are in.  They (the clients) will =
=3D
> not look one place for the SRV records and another place for normal =
name =3D
> resolution.  Therefore, whatever solution you provide must include a =
DNS =3D
> solution that provides both simple name/address resolution and SRV =3D
> resolution from the same server.
>
> However, with the size of your user base, and the implication that it =
is =3D
> distributed geographically, I would not recommend a single global =3D
> domain.  My recommendation would be to create an AD forest (what you =
=3D
> called Microstuff.net) with a subdomain for each major geographic =3D
> location.  Further, I would recommend that you set up AD sites for =
each =3D
> geographic location, each with their own TCP/IP subnet.  This permits =
=3D
> you to group services (such as DHCP, DNS, AD DC, Applications Servers, =
=3D
> SMTP relay, etc.) and administration (assuming you have the IT =3D
> department to support it) by geographic area.
>
> If you also have internet connectivity, a public Web/FTP server, and =
are =3D
> providing your users access to the internet, then I would create a DMZ =
=3D
> (if you don't already have one) and place a separate and independent =
DNS =3D
> server in the DMZ strictly to handle DNS requests from the internet =
for =3D
> your public namespace.  It can also be the forwarder for your internal =
=3D
> DNS to handle DNS requests for internet addresses from your users, but =
=3D
> this isn't strictly necessary.  I usually setup this external DNS as a =
=3D
> 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 =3D
> probably want to keep your internal and external namespaces separate =
and =3D
> distinct.  Many security people get nervous (or downright nasty) when =
AD =3D
> SRV records get exposed to the public.  For this reason alone you =
might =3D
> be forced into the M$ solution for your internal network.
>
> You might also consider hiring an outside consultant, one who's =3D
> qualified/certified in M$ and is also an experienced internetworking =
=3D
> engineer.  Microsoft Consulting Services will always give you the =
strict =3D
> M$ solution and party-line of it can be made to work, and that's not =
=3D
> 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 -----=3D20
> 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 =3D
> hosts.
>
> Basically these are the facts:
>
> At our 60000 users company it's blowing a heavy Microsoft Active =3D
> Directory
> wind. Microsoft have recommended our AD team to create one global AD =
=3D
> zone,
> we can call it microstuff.net. We are also currently using a =3D
> geographical
> DNS namespace under our own root name servers. We manage our =3D
> geographical
> and reverse zones with QIP. (We have lately been looking at Nominums =
=3D
> very
> interesting DNS solution, which might replace QIP in the future)
>
> My thinking was that I will delegate microstuff.net to AD DNS servers =
=3D
> 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 =
=3D
> have AD
> members A-records in the global AD zone microstuff.net along with the =
=3D
> SRV
> records, because programmers some times takes for granted that the =3D
> 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 =
=3D
> member
> in microstuff.net. (This is a terrible compromise since all AD members =
=3D
> will
> have two A-records and one PTR record.)
>
> I like to know how other great companies have solved this.
>
>
>
>
>