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