[unisog] AD and ISC Interoperability?

Anne Bennett anne at alcor.concordia.ca
Thu Jul 25 15:12:15 GMT 2002

> 1) Has anyone had any experience with a mixed (ISC DHCP & Microsoft DNS) DDNS
> implementation for Win2K AD? 

Before AD, we had everything on ISC bind, non-dynamic, and would have
preferred to keep it that way, but it became clear that allowing dynamic
updates for the "underscore subdomains" is necessary for the healthy
functioning of the AD.  Since we were not about to move all of our
campus DNS service to the Microsoft machines, that left us with either
delegating the underscore subdomains to the DC, or allowing dynamic
updates for just the underscores on the ISC (v9) bind.  We tried the
first, and ran into problems, so we ended up with the second: all DNS
uses ISC bind, and we allow dynmaic updates (restricted by IP address)
to the underscore subdomains by the DCs.

The DCs log errors when we refuse their A and PTR record registrations,
which puts all kinds of annoying stop signs in the logs, but is otherwise
harmless.  DO NOT TURN OFF "register this connection", even though that
seems to be the obvious thing to do to get rid of the complaints, since
this has the side effect of preventing *all* DNS updates from the DCs.
We found this out the hard way, when "underscore" registrations turned out
to be incomplete, since some DCs had had their "register this connection"
boxes unchecked before they performed an initial registration of their
AD data, and some after; we ended up with replication problems, and
some extremely misleading error messages ("No DNS servers configured
for local system").

Anyway, I append the notes I prepared when we decided how to do this;
hope they help someone!

Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8
anne at alcor.concordia.ca                                        +1 514 848-7606
Subject: Notes on AD and DNS
From: Anne Bennett <anne at alcor.concordia.ca>
Date: Tue, 26 Mar 2002 18:34:37 -0500

For posterity: DNS scenarios, with pros and cons.

Explanation: the "island problem" is described on the Microsoft Technet
under "DNS server becomes an island when a domain controller points to
itself for the _mcdcs.forestdomain Domain".  In short, when we set up a
domain controller and, when asked, let Microsoft automatically set up the
corresponding DNS server on the same host (a standard installation!),
that domain could not be replicated correctly.  We were very puzzled
by the replication errors being logged, and assumed initially that they
were caused by the various DNS changes we had made *after* that point.
Fulvio found the reference.

Note 1: the Microsoft DNS server understands three kinds of zone:
master, slave, and "Active Directory-integrated".  With the latter, it
is possible to restrict dynamic updates to "secure only", whose
cryptographic checks are (we assume!) much better than just
restricting by IP address, which is all I can do (interoperably) on
Clyde at the moment.  However, if it is not possible to make a given
zone "Active Directory-integrated", it looks as though there is no
other mechanism for restricting dynamic updates.

Note 2: AD seems to "remember" how its DNS was initially set up, and
changing delegations in the regular DNS works only partly; it seems to
work for the routine registration of SRV records at a DC's boot time,
but it is not possible to depromote the DC without returning the DNS
configuration to its set-up-time values.  This means we have to get it
right the first time.

  - Scenario 1:
      * Microsoft DNS servers do all AD-related DNS, by taking over
        DNS service for "concordia.ca".
        Pros: No fighting with AD.
        Cons: dynamic updates permitted in concordia.ca, might "take
              over" sensitive records such as "alcor.concordia.ca".
              We have an existing "bind" infrastructure that is stable
              and satisfactory; it's not at all clear that Microsoft
              can do as well.  Thousands of machines are already
              configured to query Clyde and Alcor for resolution
              (though Clyde and Alcor could still function as
              non-masters of some kind).  Suffers from "island
        Upshot: Not acceptable.

  - Scenario 2:
      * Microsoft DNS servers do all AD-related DNS; we delegate a
        subdomain "ad.concordia.ca" for use by AD.
        Pros: No fighting with AD.
        Cons: A separate namespace is created, machines have to move
              into this separate namespace.  Suffers from "island
        Upshot: We prefer to keep our namespace as it is.
        Note: This was effectively the scenario we had when we first
        set up "forestroot.concordia.montreal.qc.ca".

  - Scenario 3:
      * Underscore domains delegated to Microsoft DNS servers, where
        they are set up manually.
        Pros: If this were possible, it *might* be the cleanest
        approach, but:
          - Suffers from "island problem".
          - It seems to be impossible to prepare the four "underscore
            zones" as type "AD-integrated" before installing AD, but
            we need the DNS service to install AD.  Chicken and egg.
            I did at one point change the type of a zone from "master"
            to "AD-integrated", but it's not at all clear whether or
            not it really got integrated correctly.
          - Since this is not the way Microsoft sets up its integrated
            domains (they are set up as a single zone of domain name
            plus four underscore subdomains), subtle errors could crop
            up that are almost impossible to diagnose.
        Upshot: Too risky.
        Note: We had this for the initial set-up of "adpilot", but the
              four zones accepted dynamic updates from anywhere; this
              was not deemed acceptable.

  - Scenario 4:
      * Underscore domains delegated to Microsoft DNS servers, where
        they are are actually contained in an automatically set up
        zone (zone = domain plus four underscores).
        Pros: Could take advantage of AD replication and dynamic
              update security.
          - Suffers from "island problem".
          - Not technically correct, since the delegations do not
            correspond to zone boundaries; not sure what problems that
            might cause for AD, and it causes a lot of complaints from
            DNS-walking procedures on Clyde.
          - Domain data for top-level domain would become inconsistent
            between AD servers (which would accept dynamic updates)
            and bind servers -- such inconsistency could lead to huge
        Upshot: Not acceptable.
        Note: We effectively have this on Atila dcg-2000 test domain.

  - Scenario 5:
      * All DNS on Clyde (and secondaries), no dynamic updates.
      Pros: Keeps DNS on well-understood software; no change to our
            current operations.  No increase in security risk.
            Can switch between this scenario and scenario 6 with no
            change to AD.
        - Must make entries manually when a DC is added (based on
        - We're not completely sure whether any services other than
          domain controllers need to make "underscore" entries; we
          could find this out the hard way.
        - DCs log errors at boot time because they cannot make
          their SRV updates.
        - Includes non-Microsoft components, which may complicate
          getting support in case of problems.
      Upshot: Acceptable.

  - Scenario 6:
      * All DNS on Clyde (and secondaries), with dynamic updates for
        underscores only.
      Pros: Keeps DNS on well-understood software; no change to our
            current operations.  Small increase in security risk,
            manageable with packetfilters.  Interchangeable with
            scenario 5 if we find a reason to turn off dynamic updates.
        - Not possible to use AD dynamic update security (but can
          still restrict by IP address).
        - Includes non-Microsoft components, which may complicate
          getting support in case of problems.
      Upshot: this scenario was selected.
      Note: the initial production "forestroot" was promoted with no
            complaints or difficulties in this scenario.

Per subnet egress packetfilters become more important, since we must
prevent the spoofing of packets apparently from one of the DCs to
Clyde, to avoid DNS update forgeries which would result in redirecting
service requests.

More information about the unisog mailing list