Coding a zone statement within the dhcp config file tells dhcp where to send DDNS updates to. This has traditionally been a method used to update a truly stealth (hidden) DNS master/primary zone.
However, in the case of using bind DNS servers to provide DNS for Windows Active Directory, this can present an issue. There are a couple of requirements for Active Directory Domain Controllers. Ome, they must have authoritative access to the Active Directory DNS domain. Two, they must be able to dynamically update that same DNS domain. The issue this presents is that with a truly stealth (hidden) DNS domain, the server identified in the MNAME field of the SOA record is not really the master/primary. At this point, there are traditionally a few choices. One, use allow-update-forwarding and be stuck with increased and time consuming troubleshooting. Two, use GSS-TSIG to update the DNS domain. (Be careful, this method has its own holy war. You've been warned!) Three, eliminate the stealth master/primary by making the MNAME field of the SOA record match the actual master/primary server name. Now, personally, I have never seen the worth of having stealth master/primary servers within an internal environment. Again, my personal opinion is that it needlessly complicates the architecture of the environment and adds unnecessary cost. However, my experience with internal environments is with DDI appliances and they would offer any necessary backup requirements for a DNS zone. YMMV Bob
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
