1OVERVIEW:
2
3DLZ (Dynamically Loadable Zones) is an extention to BIND 9 that
4allows zone data to be retrieved directly from an external database.
5There is no required format or schema.  DLZ drivers exist for several
6different database backends including PostgreSQL, MySQL, and LDAP and
7can be written for any other.
8
9Historically, DLZ drivers had to be statically linked with the named
10binary and were turned on via a configure option at compile time (for
11example, "configure --with-dlz-ldap").  Currently, the drivers provided
12in the BIND 9 tarball in contrib/dlz/drivers are still linked this way.
13
14However, as of BIND 9.8, it is also possible to link some DLZ modules
15dynamically at runtime, via the DLZ "dlopen" driver, which acts as a
16generic wrapper around a shared object that implements the DLZ API.  The
17"dlopen" driver is linked into named by default, so configure options are
18no longer necessary unless using older DLZ drivers.
19
20When the DLZ module provides data to named, it does so in text format.
21The response is converted to DNS wire format by named.  This conversion,
22and the lack of any internal caching, places significant limits on the
23query performance of DLZ modules.  Consequently, DLZ is not recommended
24for use on high-volume servers.  However, it can be used in a hidden
25master configuration, with slaves retrieving zone updates via AXFR.
26(Note, however, that DLZ has no built-in support for DNS notify; slaves
27are not automatically informed of changes to the zones in the database.)
28
29CONFIGURING DLZ:
30
31A DLZ database is configured with a "dlz" statement in named.conf.
32
33    dlz example {
34        database "dlopen driver.so <args>";
35        search yes;
36    };
37
38This specifies a DLZ module to search when answering queries; the module
39is implemented in "driver.so" and is loaded at runtime by the dlopen DLZ
40driver.  Multiple "dlz" statements can be specified; when answering a
41query, all DLZ modules with the "search" option set to "yes" will be
42checked for an answer, and the best available answer will be returned
43to the client.
44
45The "search" option in this example can be omitted, as "yes" is the
46default value.  If it is set to "no", then this DLZ module is *not*
47searched for best-match when a query is received.  Instead, zones in
48this DLZ must be separately specified in a zone statement.  This can
49be useful when conventional zone semantics are desired but you wish
50to use a different back-end storage mechanism than the standard zone
51database.  For example, to use a DLZ module for an NXDOMAIN redirection
52zone:
53
54    dlz other {
55        database "dlopen driver.so <args>";
56        search no;
57    };
58
59    zone "." {
60        type redirect;
61        dlz other;
62    };
63
64EXAMPLE DRIVER:
65
66This directory contains an example of an externally-lodable DLZ module,
67dlz_example.c, which demonstrates the features of the DLZ API.  It sets up
68a single zone, whose name is configured in named.conf.  The zone can answer
69queries and AXFR requests, and accept DDNS updates.
70
71By default, at runtime, the zone implemented by this driver will contain
72an SOA, NS, and a single A record at the apex.  If configured in named.conf
73to use the name "example.nil", then, the zone will look like this:
74
75 example.nil.  3600    IN      SOA     example.nil. hostmaster.example.nil. (
76                                               123 900 600 86400 3600
77                                       )
78 example.nil.  3600    IN      NS      example.nil.
79 example.nil.  1800    IN      A       10.53.0.1
80
81The driver is also capable of retrieving information about the querying
82client, and altering its response on the basis of this information.  To
83demonstrate this feature, the example driver responds to queries for
84"source-addr.<zonename>/TXT" with the source address of the query.
85Note, however, that this record will *not* be included in AXFR or ANY
86responses.  (Normally, this feature would be used to alter responses in
87some other fashion, e.g., by providing different address records for
88a particular name depending on the network from which the query arrived.)
89
90IMPLEMENTATION NOTES:
91
92The minimal set of type definitions, prototypes, and macros needed
93for implementing a DLZ driver is in ../modules/dlz_minimal.h.  Copy this
94header file into your source tree when creating an external DLZ module.
95
96The DLZ dlopen driver provides a set of callback functions:
97
98  - void log(int level, const char *fmt, ...);
99
100    Writes the specified string to the named log, at the specified
101    log level.  Uses printf() format semantics.
102
103  - isc_result_t putrr(dns_sdlzlookup_t *lookup, const char *type,
104                       dns_ttl_t ttl, const char *data);
105
106    Puts a DNS resource record into the query response, which
107    referenced by the opaque structure 'lookup' provided by named.
108
109  - isc_result_t putnamedrr(dns_sdlzallnotes_t *allnodes,
110                            const char *name, const char *type,
111                            dns_ttl_t ttl, const char *data);
112
113    Puts a DNS resource record into an AXFR response, which is
114    referenced by the opaque structure 'allnodes' provided by named.
115
116  - isc_result_t writeable_zone(dns_view_t *view, const char *zone_name);
117
118    Allows the DLZ module to inform named that a given zone can recieve
119    DDNS updates.  (Note: This is not currently supported for DLZ
120    databases that are configured as 'search no;')
121
122The external DLZ module can define the following functions (some of these
123are mandatory, others optional).
124
125  - int dlz_version(unsigned int *flags);
126
127    Required for alL external DLZ modules, to indicate the version number
128    of the DLZ dlopen driver that this module supports.  It should return
129    the value DLZ_DLOPEN_VERSION, which is defined in the file
130    contrib/dlz/modules/dlz_minimal.h and is currently 3.  'flags' is
131    updated to indicate capabilities of the module.  In particular, if
132    the module is thread-safe then it sets 'flags' to include
133    DNS_SDLZFLAG_THREADSAFE.  (Other capability flags may be added in
134    the future.)
135
136  - isc_result_t dlz_create(const char *dlzname,
137                            unsigned int argc, char *argv[],
138                            void **dbdata, ...);
139
140    Required for all external DLZ modules; this call initializes the
141    module.
142
143  - void dlz_destroy(void *dbdata);
144
145    Optional.  If supplied, this will be called when the driver is
146    unloaded.
147
148  - isc_result_t dlz_findzonedb(void *dbdata, const char *name,
149                                dns_clientinfomethods_t *methods,
150                                dns_clientinfo_t *clientinfo);
151
152    Required for all external DLZ modules.  This indicates whether
153    the DLZ module can answer for the given name.  Returns ISC_R_SUCCESS
154    if so, and ISC_R_NOTFOUND if not.  As an optimization, it can
155    also return ISC_R_NOMORE: this indicates that the DLZ module has
156    no data for the given name or for any name above it in the DNS.
157    This prevents named from searching for a zone cut.
158
159   - isc_result_t dlz_lookup(const char *zone, const char *name, void *dbdata,
160                             dns_sdlzlookup_t *lookup,
161                             dns_clientinfomethods_t *methods,
162                             dns_clientinfo_t *clientinfo);
163
164    Required for all external DLZ modules.  This carries out the database
165    lookup for a query.
166
167  - isc_result_t dlz_allowzonexfr(void *dbdata, const char *name,
168                                  const char *client);
169
170    Optional.  Supply this if you want the module to support AXFR
171    for the specified zone and client.  A return value of ISC_R_SUCCESS
172    means AXFR is allowed, any other value means it isn't.
173
174  -  isc_result_t dlz_allnodes(const char *zone, void *dbdata,
175                               dns_sdlzallnodes_t *allnodes);
176
177     Optional, but must be supplied dlz_allowzonexfr() is.  This function
178     returns all nodes in the zone in order to perform a zone transfer.
179
180  - isc_result_t dlz_newversion(const char *zone, void *dbdata,
181                                void **versionp);
182
183    Optional.  Supply this if you want the module to support DDNS
184    updates.  This function starts a transaction in the database.
185
186
187  - void dlz_closeversion(const char *zone, isc_boolean_t commit,
188                          void *dbdata, void **versionp);
189
190    Optional, but must be supplied if dlz_newversion() is.  This function
191    closes a transaction.  'commit' indicates whether to commit the changes
192    to the database, or ignore them.
193
194  - isc_result_t dlz_configure(dns_view_t *view, void *dbdata);
195
196    Optional, but must be supplied in order to support DDNS updates.
197
198  - isc_boolean_t dlz_ssumatch(const char *signer, const char *name,
199                               const char *tcpaddr, const char *type,
200                               const char *key, uint32_t keydatalen,
201                               uint8_t *keydata, void *dbdata);
202
203    Optional, but must be supplied in order to support DDNS updates.
204
205  - isc_result_t dlz_addrdataset(const char *name, const char *rdatastr,
206                                 void *dbdata, void *version);
207
208    Optional, but must be supplied in order to support DDNS updates.
209    Adds the data in 'rdatastr' to a database node.
210
211  - isc_result_t dlz_subrdataset(const char *name, const char *rdatastr,
212                                 void *dbdata, void *version);
213
214    Optional, but must be supplied in order to support DDNS updates.
215    Removes the data in 'rdatastr' from a database node.
216
217  - isc_result_t dlz_delrdataset(const char *name, const char *rdatastr,
218                                 void *dbdata, void *version);
219
220    Optional, but must be supplied in order to support DDNS updates.
221    Deletes all data matching the type specified in 'rdatastr' from
222    the database.
223