AD & DNS??
Michael E. Hanson
MEHanson at GryphonsGate.com
Mon Jan 19 01:05:52 UTC 2004
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 =
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
P.O. Box 1151
Bellevue, NE 68005-1151
MEHanson at GryphonsGate.com (primary)
Gryphons_Master at yahoo.com
----- Original Message -----=20
From: "fih" <frhak at hotmail.com>
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 =
must be located in the same domain as the SRV records. In my opinion =
must cause a lot of trouble for huge companies trying to migrate an old =
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 =
All DNS servers within our enterprise share the same root nameservers =
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 =
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 =
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 =
going 20 years back and the use of a huge host file alternatively =
the WINS solution. Some say that Microsoft uses one global zone them =
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 =
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 =
> be <clienthostname>.<optionalsubdomainname.>Microstuff.net. The =
> 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 =
> resolution. Therefore, whatever solution you provide must include a =
> 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 =
> distributed geographically, I would not recommend a single global =3D
> domain. My recommendation would be to create an AD forest (what you =
> called Microstuff.net) with a subdomain for each major geographic =3D
> location. Further, I would recommend that you set up AD sites for =
> 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 =3D
> department to support it) by geographic area.
> If you also have internet connectivity, a public Web/FTP server, and =
> 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 =
> server in the DMZ strictly to handle DNS requests from the internet =
> 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 =
> Which brings me to my last point. From a security standpoint, you =3D
> probably want to keep your internal and external namespaces separate =
> distinct. Many security people get nervous (or downright nasty) when =
> SRV records get exposed to the public. For this reason alone you =
> 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 =
> engineer. Microsoft Consulting Services will always give you the =
> 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
> 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
> Basically these are the facts:
> At our 60000 users company it's blowing a heavy Microsoft Active =3D
> wind. Microsoft have recommended our AD team to create one global AD =
> we can call it microstuff.net. We are also currently using a =3D
> DNS namespace under our own root name servers. We manage our =3D
> and reverse zones with QIP. (We have lately been looking at Nominums =
> interesting DNS solution, which might replace QIP in the future)
> My thinking was that I will delegate microstuff.net to AD DNS servers =
> 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 =
> records, because programmers some times takes for granted that the =3D
> 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 =
> in microstuff.net. (This is a terrible compromise since all AD members =
> have two A-records and one PTR record.)
> I like to know how other great companies have solved this.
More information about the bind-users