DC's to use their own DNS/Domain name, while clients use another

[Ziek]

Is the following situation possible and functional? :

-DHCP provided by cisco devices
-All clients/member servers configured with hostnames of
[client].internal.net
-All client/member servers configured to use DNS servers that host the zone
"internal.net" . These DNS servers are BIND 8.2, non-intel servers.
-All client/member servers are members of Active Directory domain
"internal.local" .
-Domain Controllers use the DNS service installed on themselves, which hosts
the "internal.net" zone, ad-integrated. These AD-DNS boxes are configured
to forward to the main BIND 8.2 DNS boxes to resolve anything outside of
"internal.local".
-Bind 8.2 DNS servers are configured to receive a secondary transfer of the
"internal.local" zone from the DC's, so that clients/member servers can
resolve/query information from that zone.

Will this setup function correctly?

 

[Herb Martin]

Is the following situation possible and functional? :

-DHCP provided by cisco devices
Yes.

-All clients/member servers configured with hostnames of
[client].internal.net

Assuming that is your AD domain name that would be correct.

DCs too.

All domain machines should be named in the domain, as well
as being members of that domain.

You may give them additional search suffixes but it is wrong
(even if you manage to get it to work, i.e., limp along) with
name mismatches.

-All client/member servers configured to use DNS servers that host the zone
"internal.net" . These DNS servers are BIND 8.2, non-intel servers.

Technically workable but a poor choice to support
AD.

-All client/member servers are members of Active Directory domain
"internal.local" .

That would be wrong given the domain/machine names above.

The DCs need to be registered in the domain, and all of the
members should be in that domain for DNS as well.

-Domain Controllers use the DNS service installed on themselves, which hosts
the "internal.net" zone, ad-integrated.

Pretty silly since the domain clients are using the BIND set.

The domain clients should use the AD-integrated set.

ALL internal DNS clients (workstations, servers, DCs are clients
too) MUST use a consistent set of DNS server that return the
same and correct answers.

These AD-DNS boxes are configured
to forward to the main BIND 8.2 DNS boxes to resolve anything outside of
"internal.local".

Forwarding is fine, but the clients would be much
better served by using their own domain's DNS and
by having that DNS on AD-DCs.

-Bind 8.2 DNS servers are configured to receive a secondary transfer of the
"internal.local" zone from the DC's, so that clients/member servers can
resolve/query information from that zone.

But you may certainly have the BIND DNS hold secondaries
of the AD-integrated zone(s).

BIND 8.2 is pretty out of date these days as well.

Will this setup function correctly?

Maybe but it will be extremely difficult to troubleshoot,
have odd (unexplainable) problems, replicate inefficiently,
and give up most of the advantages of AD integrated DNS.

Stop swimming upstream against the current -- AD-DNS
is better than BIND for an internal DNS that supports and
AD domain.

(I run BIND servers so this is NOT a MS-centric opinion,
but I do NOT run BIND servers for the direct support of AD
and the domain clients.)