bind-dyndb-ldap versions and release notes

Latest release notes

See NEWS file in Git.

Version numbering

Version number has format X.Y:

• X = features/significant changes (support for IXFR, DNSSEC etc.)
• Y = bug fixes without significat functional changes
• Historical version numbers < 2.0 are chaotic, do not look for any meaning in them.

Major functional changes

11.x

• Port plugin to BIND 9.11 dyndb interface
  • Plugin is no longer compatible with older BIND versions
• Configuration format in named.conf follows BIND 9.11 conventions and is incompatible

10.x

• Support default TTL at zone level: dNSdefaultTTL attribute
• Support per-server configuration in idnsServerConfigObject:
  • only fake_mname, global forwarders and idnsSubstitutionVariable;ipalocation are supported

9.x

• Automatic unload automatic empty zones conflicting with forward zones with policy ‘only’
  • Behavior consistent with BIND 9.10

8.x

• Support unknown record types in LDAP using generic syntax (RFC 3597)
• Rework PTR record synchronization: SERVFAIL error is no longer returned to clients if A/AAAA record update succeeded but PTR record synchronization failed because of misconfiguration.
• Support for LDAP MODRDN (rename) for DNS records
• Properly refresh data changed in LDAP while connection to server is down

7.x

• Support for BIND 9.10

6.x

• Support for idnsZoneActive attribute: zones can be activated and deactivated at run-time
• Generate DNS NOTIFY messages after any modification to the zone data

5.x

• Support for DNSSEC in-line signing (equivalent to named.conf option inline-signing yes)
• Forwarder semantic changed to match BIND’s semantic:
  • idnsZone object always represents master zone
  • idnsForwardZone object always represents forward zone
• Master root zone (.) can be stored in LDAP

4.x

• Wildcard records are supported
• IXFR is supported
• Read-query performance is nearly same as with plain BIND
• Queries for non-existing records do not impose load on LDAP server (all authoritative data are loaded into BIND memory)
• Data are not served to clients until initial synchronization with LDAP is finished. All queries are answered with NXDOMAIN during initial synchronization!

New requirements

• SyncRepl (RFC 4533) support on the LDAP server is required
• Writeable directory for journal files is required
• SOA serial auto-increment feature is now mandatory (the plugin requires write access to LDAP)
• All zone data are cached in memory

Limitations

• LDAP MODRDN operation (rename) is not supported
• Zones enabled at run-time are not loaded properly
• Zones and records deleted when connection to LDAP is down are not refreshed properly after re-connection

3.x

• Support for DNAME records
• Support for all RR types supported by BIND
• Support pure forward zones (object class idnsForwardZone)
• IPv6 support in SyncPTR feature
• Automatic empty zone unloading
  • Works only for subset of automatic empty zones and in general is buggy and inconsistent with BIND behavior
• Persistent search enabled by default

2.x

• SOA serial number can be incremented automatically after each change in LDAP database. (Configuration option serial_autoincrement.)
• AXFR returns correct data
• Support for update-policy match type ‘external’

Ancient versions

There is couple of limitations from ancient versions. Some of these were fixed in subsequent versions (see above):

• Data for particular name were loaded from LDAP
  • optional cache TTL specified by cache_ttl option in named.conf
• No cache for non-existent records
• No/buggy support for zone transfers
• No support for wildcard records
• No automatic SOA serial management
• Support for limited set of record types
• SyncPTR only for IPv4
• TTL definition per name but not per zone

Git branches

• Main development is hapenning in master branch. Master will become vX+1 branch when it enters maintenance phase.
• Branches vX are maintenance branches. X denotes main version number
• Branching is done as late as possible. I.e. v4 branch was created right before first patch for v5 was pushed to Git master. v5 branch will be created right before first patch for v6 is pushed to Git master etc.
• As a result, it is possible that latest released version is equivalent to master branch instead of vX branch.