DLZ is Dynamically Loadable Zones, in principle a large patch to the BIND name server originally created by Rob Butler. DLZ allows a BIND name server to obtain the DNS zone data it serves from sources other than zone master files, for example from an LDAP directory server or from an SQL database server such as MySQL or PostgreSQL, or from its fastest module, the BDB driver. DLZ was a very useful addition for BIND as it permitted its integration into existing provisioning systems: DNS data, managed in a back- end database, could be fed directly into BIND. If you’re interested in the gory details, I have a whole chapter on DLZ in my book Alternative DNS Servers which, as you probably know, you can meanwhile get free of charge. (But you are, of course, welcome to purchase a paper copy.) One disadvantage to DLZ is that, from the DNS point of view (i.e. seen from BIND’s interface) it is read-only. Starting exactly today, I have to rephrase that: it was read-only. A one-liner in today’s announcement on the availability of a beta of the upcoming BIND 9.8 release caught my attention:

Dynamically Loadable Zones (DLZ) now support dynamic updates.

I new that was coming, because I’d seen Andrew’s writeup a month ago, but I was waiting for inclusion into an official BIND release. You all know of Andrew Tridgell: he’s the man who authored Samba. Be that as it may, updateable DLZ is there and it works! Actually the new driver is two-fold: it is dynamically loadable (meaning it doesn’t have to be compiled into named), and it accepts updates. What I did to prove it works, is to take the test suite for a run. The sample driver (compiled from the code in contrib/dlz/example) starts off knowing very little. It’s built-in knowledge consists of an SOA record, a name server, and an address record; nothing else. The driver can store up to 100 DNS records in core; in a real world, DNS zone data would be retrieved from some sort of database of course, and updates would be stored into that database. Here’s my named starting up. It loads the DLZ driver using a call to dlopen():

    21-Jan-2011 21:18:30.837 Loading 'example zone' using driver dlopen
    21-Jan-2011 21:18:30.838 dlz_example: started for zone example.nil
    21-Jan-2011 21:18:30.838 dlz_example: starting configure
    21-Jan-2011 21:18:30.838 dlz_example: configured writeable zone example.nil
    

If I query named for a domain www.example.nil I get an NXDOMAIN, because the driver doesn’t have any data. Now for the magic: I use nsupdate to send an RFC 2136 Dynamic DNS update request to the name server:

    /usr/local/bin/nsupdate -k ddns.key <<ENDS
    server 127.0.0.1 
    update add www.example.nil 3600 A 10.0.12.1
    send
    
    ENDS
    

Watching named’s output, I see:

    21-Jan-2011 21:48:14.027 dlz_example: allowing update of name=www.example.nil by ddns-key.example.nil
    21-Jan-2011 21:48:14.027 client 127.0.0.1#48571: updating zone 'example.nil/NONE': adding an RR at 'www.example.nil' A
    21-Jan-2011 21:48:14.027 dlz_example: adding rdataset www.example.nil 'www.example.nil. 3600    IN 10.0.12.1'
    21-Jan-2011 21:48:14.028 dlz_example: subtracting rdataset example.nil 'example.nil.    3600    IN SOA      example.nil. hostmaster.example.nil. 123 900 600 86400 3600'
    21-Jan-2011 21:48:14.028 dlz_example: adding rdataset example.nil 'example.nil. 3600    IN      SOAexample.nil. hostmaster.example.nil. 124 900 600 86400 3600'
    21-Jan-2011 21:48:14.028 dlz_example: committing transaction on zone example.nil
    

and when I then query the server I see the domain:

    $ dig @127.0.0.1 www.example.nil
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51838
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available
    
    ;; ANSWER SECTION:
    www.example.nil.  3600 IN A   10.0.12.1
    
    ;; AUTHORITY SECTION:
    example.nil.      3600 IN NS  example.nil.
    

Now, if only I had a bit more time … I’d love to take my CouchDB SDB back-end one step further and port that to DLZ. Imagine that: a NoSQL back-end to BIND…. :-) Andrew has done a great job with this, and I’d wager we’ll see a few new back-ends for the BIND name server. Now, Andrew, if you ever get to read this, you do know there is one bit missing don’t you? ;-)