AD & DNS??

[fih]

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 =
> 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.
>
>
>
>
>