PowerDNSSEC can operate in several modes. In the simplest situation, there is a single "SQL" database that contains, in separate tables, all domain data, keying material and other DNSSEC related settings.
This database is then replicated to all PowerDNS instances, which all serve identical records, keys and signatures.
In this mode of operation, care should be taken that the database replication occurs over a secure network, or over an encrypted connection. This is because keying material, if intercepted, could be used to counterfeit DNSSEC data using the original keys.
Such a single replicated database requires no further attention beyond monitoring already required during non-DNSSEC operations.
In this mode, PowerDNS serves zones that already contain DNSSEC records. Such zones can either be slaved from a remote master, or can be signed using tools like OpenDNSSEC, ldns-signzone or dnssec-signzone.
As a special feature, PowerDNSSEC can operate as a signing server which operates as a slave to an unsigned master.
In this way, if keying material is available for an unsigned zone that is retrieved from a master server, this keying material will be used when serving data from this zone.
As part of the zone retrieval, the equivalent of 'pdnssec rectify-zone' is run to make sure that all DNSSEC-related fields are set correctly.
Starting with PowerDNS 3.1, the bindbackend can manage keys in an SQLite3 database without launching a separate gsqlite3 backend.
To use this mode, add "bind-dnssec-db=/var/db/bind-dnssec-db.sqlite3" to pdns.conf, and run "pdnssec create-bind-db /var/db/bind-dnssec-db.sqlite3". Then, restart PowerDNS.
After this, you can use "pdnssec secure-zone" and all other pdnssec commands on your BIND zones without trouble.
![]() | Warning |
---|---|
This mode is only supported in 3.0 and 3.0.1! In 3.1 and up, the bindbackend always does its own key storage. |
PowerDNS can also operate based on 'BIND'-style zone & configuration files. This 'bindbackend' has full knowledge of DNSSEC, but has no native way of storing keying material.
However, since PowerDNS supports operation with multiple simultaneous backends, this is not a problem.
In hybrid mode, keying material and zone records are stored in different backends. This allows for 'bindbackend' operation in full DNSSEC mode.
To benefit from this mode, include at least one database-based backend in the 'launch' statement. The Generic SQLite backend version 3 (gsqlite3) probably complements BIND mode best, since it does not require a database server process.
![]() | Warning |
---|---|
For now, it is necessary to execute a manual SQL 'insert' into the domains table of the backend hosting the keying material. This is needed to generate a zone-id for the relevant domain. Sample SQL statement: insert into domains (name, type) values ('powerdnssec.org', 'NATIVE');. |
![]() | Note |
---|---|
The BIND Backend automates all the steps outlined below, and does not need 'manual' help |
For DNSSEC, two additional fields are important: 'auth' and 'ordername'. These fields are set correctly on an incoming zone transfer, and also by running 'pdnssec rectify-zone', or 'zone2sql' with the --dnssec flag.
The 'auth' field should be set to '1' for data for which the zone itself is authoritative, which includes the SOA record and its own NS records.
The 'auth' field should be 0 however for NS records which are used for delegation, and also for any glue (A, AAAA) records present for this purpose. Do note that the DS record for a secure delegation should be authoritative!
The 'ordername' field needs to be filled out depending on the NSEC/NSEC3 mode. When running in NSEC3 'Narrow' mode, the ordername field is ignored and best left empty. In NSEC mode, the ordername field should be NULL for any glue but filled in for delegation NS records and all authoritative records. In NSEC3 opt-out mode (the only NSEC3 mode PowerDNS currently supports), any non-authoritative records (as described for the 'auth' field) should have ordername set to NULL.
In 'NSEC' mode, it should contain the relative part of a domain name, in reverse order, with dots replaced by spaces. So 'www.uk.powerdnssec.org' in the 'powerdnssec.org' zone should have 'uk www' as its ordername.
In 'NSEC3' non-narrow mode, the ordername should contain a lowercase base32hex encoded representation of the salted & iterated hash of the full record name. pdnssec hash-zone-record zone record can be used to calculate this hash.