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

Archived from groups: microsoft.public.win2000.dns (More info?)

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?
1 answer Last reply
More about domain name clients
  1. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Ziek" <ziek@nomail.net> wrote in message
    news:e$RLhw4SFHA.3544@TK2MSFTNGP10.phx.gbl...
    > 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.)
Ask a new question

Read More

DNS Domain Name Servers Windows