stub zones ,redundancy and DDNS

Kevin Darcy kcd at
Thu Nov 3 22:39:41 UTC 2005

mmccaws2 wrote:

>behind the firewall we have two domains, unrelated by name.  The first
>domain is registered and the second is a AD forest non-routable domain
>like domain.local.  The site's primary domain is configured on the
>site's primary nameserver.  The AD is configure as it's own primary and
>the primary name server has the AD as a stub zone.
>The question is about resolving fully qualified host names from the AD
>domain in the primary name server. If the AD DNS server goes down,
>could anyone resolve those domain's hosts from the primary. Since the
>AD is configured as a stub zone on the primary name server, would any
>entries for the AD zone ever be resolved if the AD nameserver goes
>down?  How about if they are entered as static entries?  Basically once
>a name server has a stub zone configured will it try to resolve it from
>it's own records if the nameserver for the stub zone is down?
>primary name server
> stub zone:
>AD domain.local
If you care about redundancy, add more authoritative nameservers for the 
AD zone. This could include reconfiguring your "primary nameserver" as a 
slave for the zone instead of just a stub.

>Does it make sense to run the DHCP services for  the AD domain from the
>primary DNS server?
Depends on what you're trying to accomplish. If you're relying on the 
DHCP server to dynamically update DNS based on DHCP lease activity, then 
you'd need to configure and maintain that on your box if you moved it 
there. If the domain you expect to dynamically update with that lease 
information is the AD domain, and they only allow Microsoft-flavored 
Secure Dynamic Updates to the domain, then you may be out of luck unless 
you happen to be running the one (that I'm aware of) vendor-modified 
version of BIND that actually supports that protocol extension.

                                             - Kevin

More information about the bind-users mailing list