Questions about Bind and AD dns integration
kcd at chrysler.com
Tue May 6 00:03:52 UTC 2008
Simon Gao wrote:
> 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?
Like Danny Mayer said, the DHCP server should be updating the
reverse-mapping records; the clients wouldn't do that directly.
As a general matter, whenever you have part of your main namespace
hierarchy hosted on "foreign" servers (whether they be Microsoft DNS
servers, departmental/regional servers, business partner's servers or
whatever), you shouldn't just look at either slaving or forwarding as a
way to gain visibility to that part of the namespace. Slaving introduces
significant overhead and typically (these days) requires special
authorization on the server side. Forwarding has a reputation for being
non-scalable and somewhat non-resilient against failures. Some other
options are: just delegate zone(s) in question and allow your iterative
resolvers to find the zone information "naturally"; or, set up a "stub"
zone definition, which effectively only replicates the "top" of the zone
(SOA and apex NS records) and thus, although more lightweight, doesn't
provide the same level of redundancy as full slaving. You need to weigh
the risks/benefits and decide what makes the most sense given your
environment and requirements.
> 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?
I'm not seeing what the issue is with respect to SRV records. You've
already delegated ad.corp.com, so the SRV records would go in at that
level or into the various "underscored" subdomains, e.g.
_tcp.ad.corp.com, _udp.ad.corp.com, _msdcs.ad.corp.com, etc. Active
Directory would manage the SRV records on its own, within the namespace
hierarchy you've delegated to it.
Hopefully you realize that reverse mappings use PTR records. SRV records
are used for a different purpose than PTRs and one would normally not
expect to see any SRVs in a reverse zone.
More information about the bind-users