Sophie

Sophie

distrib > Mageia > 4 > x86_64 > by-pkgid > a80c2a17c20d38e6a349bb777eb92ba4 > files > 88

pdns-3.3.2-1.mga4.x86_64.rpm

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>4. Oracle backend</title><link rel="stylesheet" href="docbook.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="PowerDNS manual" /><link rel="up" href="backends-detail.html" title="Appendix A. Backends in detail" /><link rel="prev" href="generic-mypgsql-backends.html" title="3. Generic MySQL and PgSQL backends" /><link rel="next" href="gsqlite.html" title="5. Generic SQLite backend (2 and 3)" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4. Oracle backend</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="generic-mypgsql-backends.html">Prev</a> </td><th width="60%" align="center">Appendix A. Backends in detail</th><td width="20%" align="right"> <a accesskey="n" href="gsqlite.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="4. Oracle backend"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="oracle"></a>4. Oracle backend</h2></div></div></div><div class="toc"><dl><dt><span class="sect2"><a href="oracle.html#idp9400256">4.1. The Database Schema</a></span></dt><dt><span class="sect2"><a href="oracle.html#idp9472608">4.2. The SQL Statements</a></span></dt></dl></div><p>
        </p><div class="table"><a id="idp9373904"></a><p class="title"><b>Table A.4. Oracle backend capabilities</b></p><div class="table-contents"><table summary="Oracle backend capabilities" border="1"><colgroup><col /><col /></colgroup><tbody><tr><td>Native</td><td>Yes</td></tr><tr><td>Master</td><td>Yes</td></tr><tr><td>Slave</td><td>Yes</td></tr><tr><td>Superslave</td><td>Yes</td></tr><tr><td>Autoserial</td><td>Yes</td></tr><tr><td>DNSSEC</td><td>Yes</td></tr><tr><td>Module name</td><td>oracle</td></tr><tr><td>Launch name</td><td>oracle</td></tr></tbody></table></div></div><p><br class="table-break" />
      </p><p>
        This is the Oracle Database backend, completely rewritten for the 3.0 release, with easily
        configurable SQL statements, allowing you to graft PowerDNS functionality onto any Oracle
        database of your choosing.
      </p><p>
        The Oracle backend is difficult, and possibly illegal, to distribute in binary form. To use it,
        you will probably need to compile PowerDNS from source. OCI headers are expected in
        <code class="filename">$ORACLE_HOME/rdbms/public</code>, and OCI libraries in
        <code class="filename">$ORACLE_HOME/lib</code>. That is where they should be with a working installation
        of the full Oracle Database client. Oracle InstantClient should work as well, but you will need
        to make the libraries and headers available in appropriate paths.
      </p><p>
        This backend uses two kinds of database connections. First, it opens a session pool.
        Connections from this pool are used only for queries reading DNS data from the database.
        Second, it opens normal (non-pooled) connections on demand for any kind of write access.
        The reason for this split is to allow redundancy by replication. Each DNS frontend
        server can have a local read-only replicated instance of your database. Open the session
        pool to the local replicated copy, and all data will be available with high performance,
        even if the main database goes down. The writing connections should go directly to the
        main database.
      </p><p>
        Of course, if you do not require this kind of redundancy, or want to avoid the substantial
        Oracle Database licensing costs, all connections can just go to the same database with the
        same credentials. Also, the write connections should be entirely unnecessary if you
        do not plan to use either master or slave mode.
      </p><p>
        The following configuration settings are available:
      </p><p>
        </p><div class="variablelist"><dl><dt><span class="term">oracle-pool-database, oracle-pool-username, oracle-pool-password</span></dt><dd><p>
                The database to use for read access. OracleBackend will try to create a session
                pool, so make sure this database user has the necessary permissions. If your
                connection requires environment variables to be set, e.g.
                <code class="varname">ORACLE_HOME</code>, <code class="varname">NLS_LANG</code>, or
                <code class="varname">LD_LIBRARY_PATH</code>, make sure these are set when PowerDNS runs.
                <code class="filename">/etc/default/pdns</code> might help.
              </p></dd><dt><span class="term">oracle-master-database, oracle-master-username, oracle-master-password</span></dt><dd><p>
                The database to use for write access. These are normal connections, not a
                session pool. The backend may open more than one at a time.
              </p></dd><dt><span class="term">oracle-session-min, oracle-session-max, oracle-session-inc</span></dt><dd><p>
                Parameters for the connection pool underlying the session pool. OCI will open
                <code class="varname">session-min</code> connections at startup, and open more connections as
                needed, <code class="varname">session-inc</code> at a time, until <code class="varname">session-max</code>
                connections are open.
              </p></dd><dt><span class="term">oracle-nameserver-name</span></dt><dd><p>
                This can be set to an arbitrary string that will be made available in the optional bind
                variable <code class="varname">:nsname</code> for all SQL statements.  You can use this to run
                multiple PowerDNS instances off the same database, while serving different zones.
              </p></dd></dl></div><p>
      </p><p>
        There are many more options that are used to define the different SQL statements. These will be
        discussed after the reference database schema has been explained.
      </p><div class="sect2" title="4.1. The Database Schema"><div class="titlepage"><div><div><h3 class="title"><a id="idp9400256"></a>4.1. The Database Schema</h3></div></div></div><p>
          You can find an example database schema in <code class="filename">schema.sql</code> in the PowerDNS
          source distribution.  It is intended more as a starting point to come up with a schema that
          works well for your organisation, than as something you should run as it is. As long as the
          semantics of the SQL statements still work out, you can store your DNS data any way you like.
        </p><p>
          You should read this while having <code class="filename">schema.sql</code> to hand. Columns will not be
          specifically explained where their meaning is obvious.
        </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="note.png" /></td><th align="left">Note</th></tr><tr><td align="left" valign="top"><p>
            All FQDNs should be specified in lower case and without a trailing dot. Where things are
            lexicographically compared or sorted, make sure a sane ordering is used.
            <strong class="userinput"><code>NLS_LANG=AMERICAN_AMERICA.AL32UTF8</code></strong> should generally work well enough;
            when in doubt, enforce a plain ordering with
            <strong class="userinput"><code>NLSSORT(value, 'NLS_SORT = BINARY')</code></strong>.
          </p></td></tr></table></div><div class="sect3" title="Zones Table"><div class="titlepage"><div><div><h4 class="title"><a id="idp9406128"></a>Zones Table</h4></div></div></div><p>
            This table lists the zones for which PowerDNS is supposed to be an authoritative nameserver,
            plus a small amount of information related to master/slave mode.
          </p><div class="variablelist"><dl><dt><span class="term">name</span></dt><dd>
                  The FQDN of the zone apex, e.g. <code class="literal">example.com</code>.
                </dd><dt><span class="term">type</span></dt><dd><p class="simpara">
                  Describes how PowerDNS should host the zone. Valid values are
                  <code class="constant">NATIVE</code>, <code class="constant">MASTER</code>, and
                  <code class="constant">SLAVE</code>.  PowerDNS acts as an authoritative nameserver for the zone
                  in all modes. In slave mode, it will additionally attempt to acquire the zone's
                  content from a master server. In master mode, it will additionally send
                  <code class="constant">NOTIFY</code> packets to other nameservers for the zone when its content
                  changes.
                </p><div class="tip" title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="tip.png" /></td><th align="left">Tip</th></tr><tr><td align="left" valign="top"><p>
                    There is a global setting to make PowerDNS send <code class="constant">NOTIFY</code> packets
                    in slave mode.
                  </p></td></tr></table></div></dd><dt><span class="term">last_check</span></dt><dd>
                  This value, updated by PowerDNS, is the unix timestamp of the last successful attempt
                  to check this zone for freshness on the master.
                </dd><dt><span class="term">refresh</span></dt><dd>
                  The number of seconds PowerDNS should wait after a successful freshness check before
                  performing another one. This value is also found in the zone's SOA record. You may
                  want to make sure to put the same thing in both places.
                </dd><dt><span class="term">serial</span></dt><dd>
                  The serial of the version of the zone's content we are hosting now. This value is also
                  found in the zone's SOA record. You may want to make sure to put the same thing in
                  both places.
                </dd><dt><span class="term">notified_serial</span></dt><dd>
                  The latest serial for which we have sent <code class="constant">NOTIFY</code> packets. Updated
                  by PowerDNS.
                </dd><dt><span class="term"></span></dt><dd>
                </dd></dl></div></div><div class="sect3" title="The Zonemasters and ZoneAlsoNotify Tables"><div class="titlepage"><div><div><h4 class="title"><a id="idp9424352"></a>The Zonemasters and ZoneAlsoNotify Tables</h4></div></div></div><p>
            These are lists of hosts PowerDNS will interact with for a zone in master/slave mode.
            <code class="classname">Zonemasters</code> lists the hosts PowerDNS will attempt to pull zone
            transfers from, and accept <code class="constant">NOTIFY</code> packets from.
            <code class="classname">ZoneAlsoNotify</code> lists hosts PowerDNS will send
            <code class="constant">NOTIFY</code> packets to, in addition to any hosts that have NS records.
          </p><p>
            Host entries can be IPv4 or IPv6 addresses, in string representation. If you need to specify
            a port, use <strong class="userinput"><code>1.2.3.4:5300</code></strong> notation for IPv4 and brackets for IPv6:
            <strong class="userinput"><code>[abcd::1234]:5300</code></strong>.
          </p></div><div class="sect3" title="The Supermasters Table"><div class="titlepage"><div><div><h4 class="title"><a id="idp9429536"></a>The Supermasters Table</h4></div></div></div><p>
            In superslave mode, PowerDNS can accept <code class="constant">NOTIFY</code> packets for zones that
            have not been defined in the zone table yet. PowerDNS will then create an entry for the zone
            and attempt a zone transfer. This table defines the list of acceptable sources for
            supernotifications.
          </p><div class="variablelist"><dl><dt><span class="term">name</span></dt><dd>
                  An identifying string for this entry. Only used for logging.
                </dd><dt><span class="term">ip</span></dt><dd>
                  The alleged originating IP address of the notification.
                </dd><dt><span class="term">nameserver</span></dt><dd>
                  The FQDN of an authoritative nameserver.
                </dd></dl></div><p>
            A supernotification will be accepted if an entry is found such that the notification came
            from <code class="varname">ip</code> and <code class="varname">nameserver</code> appears in an NS record for that zone.
          </p></div><div class="sect3" title="The ZoneMetadata Table"><div class="titlepage"><div><div><h4 class="title"><a id="idp9438208"></a>The ZoneMetadata Table</h4></div></div></div><p>
            This is a per-zone key-value store for various things PowerDNS needs to know that are not
            part of the zone's content or handled by other tables. Depending on your needs, you may not
            want this to exist as an actual table, but simulate this in PL/SQL instead.
          </p><p>
            The currently defined metadata types are:
            </p><div class="variablelist"><dl><dt><span class="term"><code class="constant">PRESIGNED</code></span></dt><dd>
                    If set to 1, PowerDNS should assume that DNSSEC signatures for this zone exist in
                    the database and use them instead of signing records itself. For a slave zone, this
                    will also signal to the master that we want DNSSEC records when attempting a zone
                    transfer.
                  </dd><dt><span class="term"><code class="constant">NSEC3PARAM</code></span></dt><dd>
                    The NSEC3 hashing parameters for the zone.
                  </dd><dt><span class="term"><code class="constant">TSIG-ALLOW-AXFR</code></span></dt><dd>
                    The value is the name of a TSIG key. A client will be allowed to AXFR from us if the
                    request is signed with that key.
                  </dd><dt><span class="term"><code class="constant">AXFR-MASTER-TSIG</code></span></dt><dd>
                    The value is the name of a TSIG key. Outgoing <code class="constant">NOTIFY</code> packets
                    for this zone will be signed with that key.
                  </dd></dl></div><p>
          </p></div><div class="sect3" title="The Tables for Cryptographic Keys"><div class="titlepage"><div><div><h4 class="title"><a id="idp9448480"></a>The Tables for Cryptographic Keys</h4></div></div></div><p>
            We have two of them: <code class="classname">TSIGKeys</code> for symmetric TSIG keys, and
            <code class="classname">ZoneDNSKeys</code> for DNSSEC signing keys.
          </p></div><div class="sect3" title="The Records Table"><div class="titlepage"><div><div><h4 class="title"><a id="idp9450544"></a>The Records Table</h4></div></div></div><p>
            The actual DNS zone contents are stored here.
          </p><div class="variablelist"><dl><dt><span class="term">zone_id</span></dt><dd>
                  The zone this records belongs to. Normally, this is obvious. When you are dealing with
                  zone delegations, you have to insert some records into the parent zone of their actual
                  zone. See also <code class="varname">auth</code>.
                </dd><dt><span class="term">fqdn</span></dt><dd>
                  The owner name of this record. Again, this is lower case and without a trailing dot.
                </dd><dt><span class="term">revfqdn</span></dt><dd>
                  This should be a string that consists of the labels of the owner name, in reverse
                  order, with spaces instead of dots separating them, for example:
                  <pre class="synopsis">'www.example.com' =&gt; 'com example www'</pre>
                  This is used as a quick and dirty way to get canonical zone ordering. You can chose
                  a more correct and much more complicated implementation instead if you prefer.
                  In the reference schema, this is automatically set by a trigger.
                </dd><dt><span class="term">fqdnhash</span></dt><dd>
                  The NSEC3 hash of the owner name. The reference schema provides code and a trigger to
                  calculate this, but they are not production quality. The recommendation is to load the
                  dnsjava classes into your database and use their facilities for dealing with DNS names
                  and NSEC3 hashes.
                </dd><dt><span class="term">ttl</span></dt><dd>
                  The TTL for the record set. This should be the same for all members of a record set,
                  but PowerDNS will quietly use the minimum if it encounters different values.
                </dd><dt><span class="term">type</span></dt><dd>
                  The type of the record, as a canonical identification string, e.g.
                  <code class="constant">AAAA</code> or <code class="constant">MX</code>. You can set this and
                  <code class="varname">content</code> NULL to indicate a name that exists, but doesn't carry any
                  record (a so called empty non-terminal) for NSEC/NSEC3 ordering purposes.
                </dd><dt><span class="term">content</span></dt><dd>
                  The data part of the DNS record, in canonical string representation, except that if
                  this includes FQDNs, they should be specified without a trailing dot.
                </dd><dt><span class="term">last_change</span></dt><dd>
                  The unix timestamp of the last change to this record. Used only for the deprecated
                  autoserial feature. You can omit this unless you want to use that feature.
                </dd><dt><span class="term">auth</span></dt><dd><p class="simpara">
                  0 or 1 depending on whether this record is an authoritative member of the zone
                  specified in <code class="varname">zone_id</code>. These are the rules for determining that: A
                  record is an authoritative member of the zone its owner name belongs to, except for DS
                  records, which are authoritative members of the parent zone. Delegation records, that
                  is, NS records and related A/AAAA glue records, are additionally non-authoritative
                  members of the parent zone.
                </p><p class="simpara">
                  PowerDNS has a function to automatically set this. OracleBackend doesn't support that.
                  Do it in the database.
                </p></dd></dl></div></div></div><div class="sect2" title="4.2. The SQL Statements"><div class="titlepage"><div><div><h3 class="title"><a id="idp9472608"></a>4.2. The SQL Statements</h3></div></div></div><div class="sect3" title="Fetching DNS records"><div class="titlepage"><div><div><h4 class="title"><a id="idp9473152"></a>Fetching DNS records</h4></div></div></div><p>
            There are five queries to do this. They all share the same set of return columns:
            </p><div class="variablelist"><dl><dt><span class="term">fqdn</span></dt><dd>
                    The owner name of the record.
                  </dd><dt><span class="term">ttl</span></dt><dd>
                    The TTL of the record set.
                  </dd><dt><span class="term">type</span></dt><dd>
                    The type of the record.
                  </dd><dt><span class="term">content</span></dt><dd>
                    The content of the record.
                  </dd><dt><span class="term">zone_id</span></dt><dd>
                    The numerical identifier of the zone the record belongs to. A record can belong to
                    two zones (delegations/glue), in which case it may be returned twice.
                  </dd><dt><span class="term">last_change</span></dt><dd>
                    The unix timestamp of the last time this record was changed. Can safely be set as
                    a constant 0, unless you use the autoserial feature.
                  </dd><dt><span class="term">auth</span></dt><dd>
                    1 or 0 depending on the zone membership (authoritative or not).
                  </dd></dl></div><p>
            Record sets (records for the same name of the same type) must appear consecutively, which
            means <span class="command"><strong>ORDER BY</strong></span> clauses are needed in some places. Empty non-terminals
            should be suppressed.
          </p><p>
            The queries differ in which columns are restricted by <span class="command"><strong>WHERE</strong></span> clauses:
            </p><div class="variablelist"><dl><dt><span class="term">oracle-basic-query</span></dt><dd><p class="simpara">
                    Looking for records based on owner name and type. Default:
                  </p><pre class="programlisting">
SELECT fqdn, ttl, type, content, zone_id, last_change, auth
FROM Records
WHERE type = :type AND fqdn = lower(:name)
                  </pre></dd><dt><span class="term">oracle-basic-id-query</span></dt><dd><p class="simpara">
                    Looking for records from one zone based on owner name and type. Default:
                  </p><pre class="programlisting">
SELECT fqdn, ttl, type, content, zone_id, last_change, auth
FROM Records
WHERE type = :type AND fqdn = lower(:name) AND zone_id = :zoneid
                  </pre></dd><dt><span class="term">oracle-any-query</span></dt><dd><p class="simpara">
                    Looking for records based on owner name. Default:
                  </p><pre class="programlisting">
SELECT fqdn, ttl, type, content, zone_id, last_change, auth
FROM Records
WHERE fqdn = lower(:name)
  AND type IS NOT NULL
ORDER BY type
                  </pre></dd><dt><span class="term">oracle-any-id-query</span></dt><dd><p class="simpara">
                    Looking for records from one zone based on owner name. Default:
                  </p><pre class="programlisting">
SELECT fqdn, ttl, type, content, zone_id, last_change, auth
FROM Records
WHERE fqdn = lower(:name)
  AND zone_id = :zoneid
  AND type IS NOT NULL
ORDER BY type
                  </pre></dd><dt><span class="term">oracle-list-query</span></dt><dd><p class="simpara">
                    Looking for all records from one zone. Default:
                  </p><pre class="programlisting">
SELECT fqdn, ttl, type, content, zone_id, last_change, auth
FROM Records
WHERE zone_id = :zoneid
  AND type IS NOT NULL
ORDER BY fqdn, type
                  </pre></dd></dl></div><p>
          </p></div><div class="sect3" title="Zone Metadata and TSIG"><div class="titlepage"><div><div><h4 class="title"><a id="idp9501584"></a>Zone Metadata and TSIG</h4></div></div></div><div class="variablelist"><dl><dt><span class="term">oracle-get-zone-metadata-query</span></dt><dd><p class="simpara">
                  Fetch the content of the metadata entries of type <code class="varname">:kind</code> for the
                  zone called <code class="varname">:name</code>, in their original order. Default:
                </p><pre class="programlisting">
SELECT md.meta_content
FROM Zones z JOIN ZoneMetadata md ON z.id = md.zone_id
WHERE z.name = lower(:name) AND md.meta_type = :kind
ORDER BY md.meta_ind
                </pre></dd><dt><span class="term">oracle-del-zone-metadata-query</span></dt><dd><p class="simpara">
                  Delete all metadata entries of type <code class="varname">:kind</code> for the zone called
                  <code class="varname">:name</code>. You can skip this if you do not plan to manage zones with the
                  <span class="command"><strong>pdnssec</strong></span> tool. Default:
                </p><pre class="programlisting">
DELETE FROM ZoneMetadata md
WHERE zone_id = (SELECT id FROM Zones z WHERE z.name = lower(:name))
AND md.meta_type = :kind
                </pre></dd><dt><span class="term">oracle-set-zone-metadata-query</span></dt><dd><p class="simpara">
                  Create a metadata entry. You can skip this if you do not plan to manage zones with
                  the <span class="command"><strong>pdnssec</strong></span> tool. Default:
                </p><pre class="programlisting">
INSERT INTO ZoneMetadata (zone_id, meta_type, meta_ind, meta_content)
VALUES (
  (SELECT id FROM Zones WHERE name = lower(:name)),
  :kind, :i, :content
)
                </pre></dd><dt><span class="term">oracle-get-tsig-key-query</span></dt><dd><p class="simpara">
                  Retrieved the TSIG key specified by <code class="varname">:name</code>. Default:
                </p><pre class="programlisting">
SELECT algorithm, secret
FROM TSIGKeys
WHERE name = :name
                </pre></dd></dl></div></div><div class="sect3" title="DNSSEC"><div class="titlepage"><div><div><h4 class="title"><a id="idp9516448"></a>DNSSEC</h4></div></div></div><div class="variablelist"><dl><dt><span class="term">oracle-get-zone-keys-query</span></dt><dd><p class="simpara">
                  Retrieve the DNSSEC signing keys for a zone. Default:
                </p><pre class="programlisting">
SELECT k.id, k.flags, k.active, k.keydata
FROM ZoneDNSKeys k JOIN Zones z ON z.id = k.zone_id
WHERE z.name = lower(:name)
                </pre></dd><dt><span class="term">oracle-del-zone-key-query</span></dt><dd><p class="simpara">
                  Delete a DNSSEC signing key. You can skip this if you do not plan to manage zones with
                  the <span class="command"><strong>pdnssec</strong></span> tool. Default:
                </p><pre class="programlisting">
DELETE FROM ZoneDNSKeys WHERE id = :keyid
                </pre></dd><dt><span class="term">oracle-add-zone-key-query</span></dt><dd><p class="simpara">
                  Add a DNSSEC signing key. You can skip this if you do not plan to manage zones with
                  the <span class="command"><strong>pdnssec</strong></span> tool. Default:
                </p><pre class="programlisting">
INSERT INTO ZoneDNSKeys (id, zone_id, flags, active, keydata) "
VALUES (
  zonednskeys_id_seq.NEXTVAL,
  (SELECT id FROM Zones WHERE name = lower(:name)),
  :flags,
  :active,
  :content
) RETURNING id INTO :keyid
                </pre></dd><dt><span class="term">oracle-set-zone-key-state-query</span></dt><dd><p class="simpara">
                  Enable or disable a DNSSEC signing key. You can skip this if you do not plan to manage zones with
                  the <span class="command"><strong>pdnssec</strong></span> tool. Default:
                </p><pre class="programlisting">
UPDATE ZoneDNSKeys SET active = :active WHERE id = :keyid
                </pre></dd><dt><span class="term">oracle-prev-next-name-query</span></dt><dd><p class="simpara">
                  Determine the predecessor and successor of an owner name, in canonical zone ordering.
                  See the reference implementation for the quick and dirty way, and the RFCs for the
                  full definition of canonical zone ordering.
                </p><p class="simpara">
                  This statement is a PL/SQL block that writes into two of the bind variables, not a query.
                </p><p class="simpara">
                  Default:
                </p><pre class="programlisting">
BEGIN
  get_canonical_prev_next(:zoneid, :name, :prev, :next);
END;
                </pre></dd><dt><span class="term">oracle-prev-next-hash-query</span></dt><dd><p class="simpara">
                  Given an NSEC3 hash, this call needs to return its predecessor and successor in NSEC3
                  zone ordering into <code class="varname">:prev</code> and <code class="varname">:next</code>, and the
                  FQDN of the predecessor into <code class="varname">:unhashed</code>. Default:
                </p><pre class="programlisting">
BEGIN
  get_hashed_prev_next(:zoneid, :hash, :unhashed, :prev, :next);
END;
                </pre></dd></dl></div></div><div class="sect3" title="Incoming AXFR"><div class="titlepage"><div><div><h4 class="title"><a id="idp9537344"></a>Incoming AXFR</h4></div></div></div><div class="variablelist"><dl><dt><span class="term">oracle-zone-info-query</span></dt><dd><p class="simpara">
                  Get some basic information about the named zone before doing master/slave things. Default:
                </p><pre class="programlisting">
SELECT id, name, type, last_check, serial, notified_serial
FROM Zones
WHERE name = lower(:name)
                </pre></dd><dt><span class="term">oracle-delete-zone-query</span></dt><dd><p class="simpara">
                  Delete all records for a zone in preparation for an incoming zone transfer. This
                  happens inside a transaction, so if the transfer fails, the old zone content will
                  still be there. Default:
                </p><pre class="programlisting">
DELETE FROM Records WHERE zone_id = :zoneid
                </pre></dd><dt><span class="term">oracle-insert-record-query</span></dt><dd><p class="simpara">
                  Insert a record into the zone during an incoming zone transfer. This happens inside
                  the same transaction as delete-zone, so we will not end up with a partially
                  transferred zone. Default:
                </p><pre class="programlisting">
INSERT INTO Records (id, fqdn, zone_id, ttl, type, content)
VALUES (records_id_seq.NEXTVAL, lower(:name), :zoneid, :ttl, :type, :content)
                </pre></dd><dt><span class="term">oracle-finalize-axfr-query</span></dt><dd><p class="simpara">
                  A block of PL/SQL to be executed after a zone transfer has successfully completed, but
                  before committing the transaction. A good place to locate empty non-terminals, set the
                  <code class="varname">auth</code> bit and NSEC3 hashes, and generally do any post-processing
                  your schema requires. The do-nothing default:
                </p><pre class="programlisting">
DECLARE
  zone_id INTEGER := :zoneid;
BEGIN
  NULL;
END;
                </pre></dd></dl></div></div><div class="sect3" title="Master/Slave Stuff"><div class="titlepage"><div><div><h4 class="title"><a id="idp9549328"></a>Master/Slave Stuff</h4></div></div></div><div class="variablelist"><dl><dt><span class="term">oracle-unfresh-zones-query</span></dt><dd><p class="simpara">
                  Return a list of zones that need to be checked and their master servers. Return
                  multiple rows, identical except for the master address, for zones with more than one
                  master. Default:
                </p><pre class="programlisting">
SELECT z.id, z.name, z.last_check, z.serial, zm.master
FROM Zones z JOIN Zonemasters zm ON z.id = zm.zone_id
WHERE z.type = 'SLAVE'
  AND (z.last_check IS NULL OR z.last_check + z.refresh &lt; :ts)
ORDER BY z.id
                </pre></dd><dt><span class="term">oracle-zone-set-last-check-query</span></dt><dd><p class="simpara">
                  Set the last check timestamp after a successful check. Default:
                </p><pre class="programlisting">
UPDATE Zones SET last_check = :lastcheck WHERE id = :zoneid
                </pre></dd><dt><span class="term">oracle-updated-masters-query</span></dt><dd><p class="simpara">
                  Return a list of zones that need to have <code class="constant">NOTIFY</code> packets sent out.
                  Default:
                </p><pre class="programlisting">
SELECT id, name, serial, notified_serial
FROM Zones
WHERE type = 'MASTER'
AND (notified_serial IS NULL OR notified_serial &lt; serial)
                </pre></dd><dt><span class="term">oracle-zone-set-notified-serial-query</span></dt><dd><p class="simpara">
                  Set the last notified serial after packets have been sent. Default:
                </p><pre class="programlisting">
UPDATE Zones SET notified_serial = :serial WHERE id = :zoneid
                </pre></dd><dt><span class="term">oracle-also-notify-query</span></dt><dd><p class="simpara">
                  Return a list of hosts that should be notified, in addition to any nameservers in the
                  NS records, when sending <code class="constant">NOTIFY</code> packets for the named zone.
                  Default:
                </p><pre class="programlisting">
SELECT an.hostaddr
FROM Zones z JOIN ZoneAlsoNotify an ON z.id = an.zone_id
WHERE z.name = lower(:name)
                </pre></dd><dt><span class="term">oracle-zone-masters-query</span></dt><dd><p class="simpara">
                  Return a list of masters for the zone specified by id. Default:
                </p><pre class="programlisting">
SELECT master
FROM Zonemasters
WHERE zone_id = :zoneid
                </pre></dd><dt><span class="term">oracle-is-zone-master-query</span></dt><dd><p class="simpara">
                  Return a row if the specified host is a registered master for the named zone. Default:
                </p><pre class="programlisting">
SELECT zm.master
FROM Zones z JOIN Zonemasters zm ON z.id = zm.zone_id
WHERE z.name = lower(:name) AND zm.master = :master
                </pre></dd></dl></div></div><div class="sect3" title="Superslave Stuff"><div class="titlepage"><div><div><h4 class="title"><a id="idp9569328"></a>Superslave Stuff</h4></div></div></div><div class="variablelist"><dl><dt><span class="term">oracle-accept-supernotification-query</span></dt><dd><p class="simpara">
                  If a supernotification should be accepted from <code class="varname">:ip</code>, for the master
                  nameserver <code class="varname">:ns</code>, return a label for this supermaster. Default:
                </p><pre class="programlisting">
SELECT name
FROM Supermasters
WHERE ip = :ip AND nameserver = lower(:ns)
                </pre></dd><dt><span class="term">oracle-insert-slave-query</span></dt><dd><p class="simpara">
                  A supernotification has just been accepted, and we need to create an entry for the new
                  zone. Default:
                </p><pre class="programlisting">
INSERT INTO Zones (id, name, type)
VALUES (zones_id_seq.NEXTVAL, lower(:zone), 'SLAVE')
RETURNING id INTO :zoneid
                </pre></dd><dt><span class="term">oracle-insert-master-query</span></dt><dd><p class="simpara">
                  We need to register the first master server for the newly created zone. Default:
                </p><pre class="programlisting">
INSERT INTO Zonemasters (zone_id, master)
VALUES (:zoneid, :ip)
                </pre></dd></dl></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="generic-mypgsql-backends.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="backends-detail.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="gsqlite.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">3. Generic MySQL and PgSQL backends </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 5. Generic SQLite backend (2 and 3)</td></tr></table></div></body></html>