AD & DNS??

Michael E. Hanson MEHanson at
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 "" domain if they are a member of the =
"" 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
P.O. Box 1151
Bellevue, NE 68005-1151
(402) 871-9622

MEHanson at (primary)
Gryphons_Master at

----- Original Message -----=20
From: "fih" <frhak at>
Newsgroups: comp.protocols.dns.bind
To: <comp-protocols-dns-bind at>
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> skrev i meddelandet
news:buelbr$2ff5$1 at
> Personally, I'd have to side with M$ on this one.  If your client PCs =
> are to be members of the AD Domain, then their FQDNs =
> be <clienthostname>.<optionalsubdomainname.>  The =
clients =3D
> 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 =3D
> 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 =
is =3D
> distributed geographically, I would not recommend a single global =3D
> domain.  My recommendation would be to create an AD forest (what you =
> called 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 =
> 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 =
are =3D
> 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 =
for =3D
> 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 =
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 =
> 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 =
> 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 (primary)
> Gryphons_Master at
> ----- Original Message -----=3D20
> From: "fih" <frhak at>
> Newsgroups: comp.protocols.dns.bind
> To: <comp-protocols-dns-bind at>
> 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 =
> zone,
> we can call it 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 =
> very
> interesting DNS solution, which might replace QIP in the future)
> My thinking was that I will delegate 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 along with the =
> 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 (This is what I want but is
> depreciated by Microsoft)
> 2. A-records and SRV-records in 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 + an extra A-record for each AD =
> member
> in (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.

More information about the bind-users mailing list