1. Docs
  2. Meta-database

Meta-database

Ticket Summary
#151 Implement internal meta-database

Overview

Currently the driver relies on 1:1 mapping between LDAP DN and DNS names and there are no means for storing additional data about DNS names, e.g. LDAP UUID of object or so.

Some features cannot be reasonably implemented without these additional metadata.

Use Cases

Few examples follow:

LDAP MODRDN

Support for LDAP MODRDN operation requires following mapping:

  • LDAP UUID -> (DNS zone name, DNS FQDN)

For details see BIND9/Design/RBTDB#Entryrenamingmoddnhandling.

Refresh after reconnection to LDAP

Support for coalesced LDAP delete requires following metadata:

  • LDAP UUID -> (DNS zone name, DNS FQDN) mapping
  • LDAP UUID -> object class
  • last successfully processed SyncRepl cookie

For details see ticket 128#comment:7.

Default TTL value

Support for default per-entry TTL requires following:

  • Information if TTL is explicitly defined for particular DNS name in given DNS zone

Per-RRset TTL value

Ticket Summary
#59 Per-RRset TTL

Further optimization outside schope of ticket:70 needs information from where the TTL information for particular RRset was inherited.

It might be possible to implement this without optimizations, I’m not sure how slow or fast it would be if any change in any TTL definition triggered iteration over all names and re-computation of all TTLs.

Re-synchronization

Support for full re-synchronization with LDAP requires following metadata:

  • LDAP UUID -> monotonic object generation number
  • LDAP UUID -> (DNS zone name, DNS FQDN) mapping
  • LDAP UUID -> object class

Auto-generated _location records

Support for refresh/batch re-synchronization with LDAP requires:

  • LDAP UUID -> (DNS zone name, DNS FQDN) mapping
  • LDAP UUID -> boolean that _location record was auto-generated.

Support for overrides in LDAP requires:

  • (DNS zone name, DNS FQDN) -> metaDB entry mapping

This mapping will be used if override _location.example. is processed. We have to find metadata entry for DNS FQDN example. and change boolean that _location record was auto-generated (if the parent entry exists).

Startup with big amount of data in LDAP is slow

Additional metadata which are outside scope of ticket:128 and ticket:125:

  • Where are real zone data stored (filesystem path).
  • Timestamp when the cached version of the zone was stored.
  • Zone configuration (allow-query etc.)

Design

Various metadata will be stored in internal RBTDB instances to allow fast key -> value mapping.

TTL of all records is zero unless stated otherwise.

LDAP UUID -> metadata mapping

Purpose of this sub-tree is to store necessary metadata about LDAP objects. For example, an LDAP server might send notification like ‘object UUID 1234 was removed’ but does not add other information (like DN or object class) to the notification.

RBTDB for LDAP UUID -> value mapping will have nodes named like <LDAP UUID>.uuid.ldap.

Every metadata type will be mapped to a particular RR type:

  • object class = AAAA record where the address is bit field according to LDAP_ENTRYCLASS_* definitions from ldap_entry.h
  • boolean that _location record was auto-generated = a bit in the object class bit field
  • monotonic object generation number = A record, i.e. 32 bit integer. This number can be easily compared using isc_serial_* functions.
  • (DNS zone name, DNS FQDN) = RP record with (zone name, FQDN)
  • Information if TTL is explicitly defined for particular DNS name in given DNS zone = TTL value of the RP record.
    • 0 = implicit value
    • 1 = explicit value defined in the entry

Global metadata

This kind of metadata is not related to DNS data.

Global metadata will be stored in the same RBTDB as LDAP UUID -> value mapping, just under a different sub-tree.

  • last successfully processed SyncRepl cookie = URI RR at node syncrepl.ldap., numeric components of URI are ignored. This entry has to be updated strictly sequentially otherwise some updates could be missing after reconnection to LDAP.
  • global configuration (global forwarder etc.) -> serialization of LDAPMessage returned by OpenLDAP client libs stored at node gconfig.ldap.

Zone register metadata

Zone register metadata will be stored in a separate RBTDB which will be used to quickly load data from disk without a need to contact LDAP.

Node names in this RBTDB will be equal to zone FQDN.

  • Zone configuration (allow-query etc.) -> serialization of LDAPMessage returned by OpenLDAP client libs, most likely stored in URI RR
  • Filesystem path to zone database dump -> value derived from zone name and global plugin configuration
  • Timestamp when the cached version of the zone was stored -> A record (32 bit unsigned integer)

(DNS zone name, DNS FQDN) -> metaDB entry mapping

This mapping will be used if override _location.example. is processed. We have to find metadata entry for DNS FQDN example. and change boolean that _location record was auto-generated (if the parent entry exists).

Every zone in zone register will have own RBTDB with name -> <UUID>.uuid.ldap. name mapping which can be used for accessing the LDAP metadata database. Most likely in form of CNAME record.

Nothing else should be stored in this RBTDB.

Implementation

  • New dependency on libuuid
  • Notes about cookie serialization:
    • SyncRepl events are generated by OpenLDAP library one by one. Potentially each even can have a new value of cookie in it.
    • SyncRepl events are translated to ISC events which are processed in parallel. Our internal SyncRepl event queue is limited to 100 unprocessed events to avoid BIND9/Bugs/ISC-35160.
    • We need to make sure that no cookies are ever skipped.
    • An older cookie should not overwrite a newer cookie.
    • A newer cookie can be written to the syncrepl.ldap. node only if all preceding cookies were processed before the write.
    • Example:
      • Last processed cookie value is 0.
      • OpenLDAP library generated new events with cookie values 1, 2, 3. These OpenLDAP events are translated to independent ISC events which are processed in parallel.
      • ISC event with cookie = 2 is the first processed event. Events 1 and 3 are not processed yet.
      • At this point value 2 cannot be stored in syncrepl.ldap. node because event with previous cookie value = 1 was not processed yet.
      • Reason: We would have skipped changes in LDAP made between cookies 1 and 2 if we actually stored the cookie 2 and reconnected to LDAP (using stored cookie 2) before the event with cookie 1 was processed.

Feature Management

This feature does not have any user interface. It will automatically create new files in /var/named/dyndb-ldap/ipa directory and that is it.

Configuration

No new configuration options will be added.

How to Test

Particular features listed in section Use Cases will work as specified.

Author

pspacek

© Copyright 2017, bind-dyndb-ldap contributors. Created using Sphinx.