Questions about Bind and AD dns integration

[Mark Andrews]

> The short answer to your question is "yes."
> 
> We use BIND exclusively in an AD environment, and it works very nicely.
> In our environment, all of the dynamic updates for forward (A and SRV)
> records as well as all the reverse (PTR) records all go to the same BIND
> server acting as master for all zones.  But if you want to have some
> zones on one server and other zones on a different server, you can do
> that -- with BIND or non-BIND DNS servers -- by simply delegating the
> sub-domains into sub-zones.
> 
> You cannot, however, split a single domain to have part of it homed on
> one server and another part homed on a different server, which you might
> be hoping to do for the reverse DNS.  But don't need to as long as you
> don't mind if the updates are insecure, or else you don't mind going
> through great pains to integrate GSS-TSIG with BIND.
> 
> As long as you are clear on the point that zone delegation is an all-
> or-nothing proposition, the key for the dynamic DNS to work is setting
> the MNAME field of the SOA correctly, which means that for each zone,
> the MNAME must be set to the FQDN (with trailing dot) of the master DNS
> server for that zone.
> 
> Let me explain about the insecure dynamic updates: The BIND server
> doesn't work with the GSS-TSIG (at least not out of the box), so we
> considered using TSIG, which does work with BIND.

	BIND 9.5.0 supports GSS-TSIG.

> But the amount of
> work that would be required to setup the TSIG on each of the servers
> needing dynamic DNS was more than we were willing to do, so we decided
> simply to *not* use secure updates.  This is safe because everything is
> behind a firewall.  As a perfectly acceptable compromise, we use ACL's
> in BIND to control whose updates are allowed (the allow-update option).

	BIND 9.6.0 will support TCP as a weak authentication method
	for hosts to update their own reverse records (policy tcp-self).
 
> We setup the DHCP server to perform all forward and reverse DNS for
> workstations (and other DHCP clients), and we really do not need dynamic
> DNS for any other servers that have static ip address assignments with
> the notable exception of the AD domain controllers, the MS Cluster
> servers, and the KMS servers, so the allow-update list includes a
> relatively small number of hosts.
> 
> This architecture works better (in terms of trouble-free operation and
> ease of administration) that the MS DNS servers, and it has proven to be
> a very good choice for us.  I do wish we could get the GSS-TSIG to work
> for secure dynamic updates, but as I said we are content with this one
> compromise.  But there is one more detail I must mention:
> 
> During certain MS server maintenance steps performed according to MS
> recommendations, the unnecessary DHCP client has been removed from
> virtually all of our servers, and on the nights that this was done, the
> affected servers lost their forward and reverse DNS records.  The reason
> for this is that the DHCP client, on its dying breath, removes those
> records.  So we needed to manually re-add the records the next day.
> This problem did not occur when the allow-update option did not allow
> updates from those servers.  So it is important to set the allow-update
> option!!!
> 
> And, lastly, I must say that this architecture suffers from a major
> single-point-of-failure flaw.  We are investigating an option whereby
> the MNAME resolves to an IP address that is a virtual address which
> stably binds to a base master server, but in the event of a failure, a
> stand-by master server can take over the virtual address.  The obvious
> difficulty is trying to maintain state between the base master and the
> stand-by master.  If we use our IPAM system (that tries to keep track of
> the dynamic DNS via also-notify which prompts ixfr's), we will typically
> lose some data, but it would be better than ceasing to function.  We are
> hoping, though, to find a more robust solution for BIND multi-master.

	That's inherent part of the DNS protocol.
 
> I'm not the first to express this desire -- hopefully some day it will
> become more important the DNSSEC.
> 
> --
> Gordon A. Lang
> 
> ----- Original Message ----- 
> From: "Simon Gao" <gao at schrodinger.com>
> To: <bind-users at isc.org>
> Sent: Friday, May 02, 2008 7:15 PM
> Subject: Questions about Bind and AD dns integration
> 
> 
> > Hi,
> > 
> > We are running Bind as name servers for our internal and public network. 
> > Now we need to bring AD online. We assign AD a sub domain for AD dns 
> > servers to manage, like ad.corp.com. However, we run into one problem 
> > with reverse dns setting since all hosts are on the same network. 
> > Currently, reverse map is not set to allow dynamic update and we want to 
> > keep it that way.
> > 
> > One option is set up AD dns as primary server for reverse maps and 
> > transfer them to the Bind servers, or set up forwarders pointing to AD 
> > dns servers Anyone see any problem with such setup?
> > 
> > Is it possible to set up a sub domain on Bind to allow Windows DC and 
> > clients to do dynamic update to service locator records?
> > 
> > Simon
> >
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org