- When persistent search was in use, the plug-in sometimes terminated unexpectedly due to an assertion failure when the "rndc reload" command was issued and the LDAP server was not reachable. With this update, the code has been improved so that connection failures and reconnects are now handled more robustly. As a result, the plug-in no longer crashes in the scenario described.
- Previously, some relative domain names were not expanded correctly to FQDNs. Consequently, zone transfers sometimes contained relative domain names although they should only contain FQDNs (for example, they contained "name." record instead of "name.example.com."). The plug-in has been patched, and as a result, zone transfers now contain the correct domain names.
- Due to a bug in bind-dyndb-ldap, the named process sometimes terminated unexpectedly when a connection to LDAP timed out. Consequently, when a connection to LDAP timed out (or failed), the named process was sometimes aborted and DNS service was unavailable. The plug-in has been fixed and as a result, the plug-in now handles situations when a connection to LDAP fails gracefully.
- Due to a race condition, the plug-in sometimes caused the named process to terminate unexpectedly when it received a request to reload. Consequently, the DNS service was sometimes unavailable. A patch has been applied and as a result, the race condition during reload no longer occurs.
- LDAP in Red Hat Enterprise Linux 6.4 includes support for persistent search for both zones and their resource records. Persistent search allows the bind-dyndb-ldap plug-in to be immediately informed about all changes in an LDAP database. It also decreases network bandwidth usage required by repeated polling.
- Previously, it was only possible to configure IPv4 forwarders in LDAP. With this update, a patch has been added to the plug-in, and as a result, the plug-in is now able to parse and use IPv6 forwarders. BIND9 syntax for "forwarders" is required.
- Previously, it was impossible to share one LDAP database between multiple master servers; only one master server could be used. A new bind-dyndb-ldap option "fake_mname" which allows for overriding the master server name in the SOA record has been added. With this option it is now possible to override the master server name in the SOA record so that multiple servers can act as master server for one LDAP database.
- When multiple named processes shared one LDAP database and dynamically updated DNS records (via DDNS), they did not update the SOA serial numbers so it was impossible to serve such zones on secondary servers correctly (that is to say, they were not updated on slave servers). With this update, the plug-in can now update SOA serial numbers automatically, if configured to do so. Refer to the new "serial_autoincrement" option in the /usr/share/doc/bind-dyndb-ldap/README file for more details.
- This update provides support for the per-zone disabling of forwarding. Some setups require the disabling of forwarding per-zone. For example, company servers are configured as authoritative for a non-public zone and have global forwarding turned on. When the non-public zone contains delegation for a non-public subdomain, the zone must have explicitly disabled forwarding otherwise the glue records will not be returned. As a result, a server can now return delegation glue records for private zones when global forwarding is turned on. Refer to /usr/share/doc/bind-dyndb-ldap/README for detailed information.
- The bind-dyndb-ldap plug-in processed settings too early, which led to the daemon terminating unexpectedly with a segmentation fault during startup or reload. The bind-dyndb-ldap plug-in has been fixed to process its options later, and so, no longer crashes during startup or reload.