"Fossies" - the Fresh Open Source Software Archive

Member "bind-9.11.23/doc/arm/dlz.xml" (7 Sep 2020, 6340 Bytes) of package /linux/misc/dns/bind9/9.11.23/bind-9.11.23.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) XML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "dlz.xml": 9.11.21_vs_9.11.22.

    1 <!--
    2  - Copyright (C) Internet Systems Consortium, Inc. ("ISC")
    3  -
    4  - This Source Code Form is subject to the terms of the Mozilla Public
    5  - License, v. 2.0. If a copy of the MPL was not distributed with this
    6  - file, You can obtain one at http://mozilla.org/MPL/2.0/.
    7  -
    8  - See the COPYRIGHT file distributed with this work for additional
    9  - information regarding copyright ownership.
   10 -->
   12 <!-- Converted by db4-upgrade version 1.0 -->
   13 <section xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="dlz-info"><info><title>DLZ (Dynamically Loadable Zones)</title></info>
   15   <para>
   16     Dynamically Loadable Zones (DLZ) are an extension to BIND 9 that allows
   17     zone data to be retrieved directly from an external database.  There is
   18     no required format or schema.  DLZ drivers exist for several different
   19     database backends, including PostgreSQL, MySQL, and LDAP, and can be
   20     written for any other.
   21   </para>
   22   <para>
   23     Historically, DLZ drivers had to be statically linked with the <command>named</command>
   24     binary and were turned on via a configure option at compile time (for
   25     example, <userinput>configure --with-dlz-ldap</userinput>).
   26     The drivers provided in the BIND 9 tarball in
   27     <filename>contrib/dlz/drivers</filename> are still linked this
   28     way.
   29   </para>
   30   <para>
   31     In BIND 9.8 and higher, it is possible to link some DLZ modules
   32     dynamically at runtime, via the DLZ "dlopen" driver, which acts as a
   33     generic wrapper around a shared object implementing the DLZ API.  The
   34     "dlopen" driver is linked into <command>named</command> by default, so configure options
   35     are no longer necessary when using these dynamically linkable drivers;
   36     they are still needed for the older drivers in
   37     <filename>contrib/dlz/drivers</filename>.
   38   </para>
   40   <para>
   41     The DLZ module provides data to <command>named</command> in text format,
   42     which is then converted to DNS wire format by <command>named</command>.  This
   43     conversion, and the lack of any internal caching, places significant
   44     limits on the query performance of DLZ modules.  Consequently, DLZ is
   45     not recommended for use on high-volume servers.  However, it can be
   46     used in a hidden primary configuration, with secondaries retrieving zone
   47     updates via AXFR.  Note, however, that DLZ has no built-in support for
   48     DNS notify; secondary servers are not automatically informed of changes to the
   49     zones in the database.
   50   </para>
   52   <section><info><title>Configuring DLZ</title></info>
   54     <para>
   55       A DLZ database is configured with a <command>dlz</command>
   56       statement in <filename>named.conf</filename>:
   57     </para>
   58     <screen>
   59     dlz example {
   60     database "dlopen driver.so <option>args</option>";
   61     search yes;
   62     };
   63     </screen>
   64     <para>
   65       This specifies a DLZ module to search when answering queries; the
   66       module is implemented in <filename>driver.so</filename> and is
   67       loaded at runtime by the dlopen DLZ driver.  Multiple
   68       <command>dlz</command> statements can be specified; when
   69       answering a query, all DLZ modules with <option>search</option>
   70       set to <literal>yes</literal> are queried to see whether
   71       they contain an answer for the query name. The best available
   72       answer is returned to the client.
   73     </para>
   74     <para>
   75       The <option>search</option> option in the above example can be
   76       omitted, because <literal>yes</literal> is the default value.
   77     </para>
   78     <para>
   79       If <option>search</option> is set to <literal>no</literal>, then
   80       this DLZ module is <emphasis>not</emphasis> searched for the best
   81       match when a query is received.  Instead, zones in this DLZ must be
   82       separately specified in a zone statement.  This allows users to
   83       configure a zone normally using standard zone-option semantics,
   84       but specify a different database backend for storage of the
   85       zone's data.  For example, to implement NXDOMAIN redirection using
   86       a DLZ module for backend storage of redirection rules:
   87     </para>
   88     <screen>
   89     dlz other {
   90     database "dlopen driver.so <option>args</option>";
   91     search no;
   92     };
   94     zone "." {
   95     type redirect;
   96     dlz other;
   97     };
   98     </screen>
   99   </section>
  100   <section><info><title>Sample DLZ Driver</title></info>
  102     <para>
  103       For guidance in the implementation of DLZ modules, the directory
  104       <filename>contrib/dlz/example</filename> contains a basic
  105       dynamically linkable DLZ module - i.e., one which can be
  106       loaded at runtime by the "dlopen" DLZ driver.
  107       The example sets up a single zone, whose name is passed
  108       to the module as an argument in the <command>dlz</command>
  109       statement:
  110     </para>
  111     <screen>
  112     dlz other {
  113     database "dlopen driver.so example.nil";
  114     };
  115     </screen>
  116     <para>
  117       In the above example, the module is configured to create a zone
  118       "example.nil", which can answer queries and AXFR requests and
  119       accept DDNS updates.  At runtime, prior to any updates, the zone
  120       contains an SOA, NS, and a single A record at the apex:
  121     </para>
  122     <screen>
  123  example.nil.  3600    IN      SOA     example.nil. hostmaster.example.nil. (
  124                            123 900 600 86400 3600
  125                        )
  126  example.nil.  3600    IN      NS      example.nil.
  127  example.nil.  1800    IN      A
  128     </screen>
  129     <para>
  130       The sample driver can retrieve information about the
  131       querying client and alter its response on the basis of this
  132       information.  To demonstrate this feature, the example driver
  133       responds to queries for "source-addr.<option>zonename</option>&gt;/TXT"
  134       with the source address of the query.  Note, however, that this
  135       record will <emphasis>not</emphasis> be included in AXFR or ANY responses.  Normally,
  136       this feature is used to alter responses in some other fashion,
  137       e.g., by providing different address records for a particular name
  138       depending on the network from which the query arrived.
  139     </para>
  140     <para>
  141       Documentation of the DLZ module API can be found in
  142       <filename>contrib/dlz/example/README</filename>.  This directory also
  143       contains the header file <filename>dlz_minimal.h</filename>, which
  144       defines the API and should be included by any dynamically linkable
  145       DLZ module.
  146     </para>
  147   </section>
  148 </section>