</sect2>
</sect1>
</chapter>
- <chapter id="migration"><title>Migrating to PDNS</title>
+ <chapter id="migration"><title>Migrating to PowerDNS</title>
<para>
- Before migrating to PDNS a few things should be considered.
+ Before migrating to PowerDNS a few things should be considered.
<variablelist>
<varlistentry>
- <term>PDNS does not operate as a 'slave' or 'master' server with all backends</term>
+ <term>PowerDNS does not operate as a 'slave' or 'master' server with all backends</term>
<listitem>
<para>
Only the Generic SQL, OpenDBX and BIND backends have the ability to act as master or slave.
</para>
</sect1>
</chapter>
-
+ <chapter id="powerdnssec-auth">
+ <title>Serving authoritative DNSSEC data</title>
+ <para>
+ (only available in PowerDNS 3.0 and beyond, not yet available in the PowerDNS Recursor)
+ </para>
+ <para>
+ PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data,
+ with minimal administrative overhead.
+ </para>
+ <para>
+ In PowerDNSSEC, DNS and signatures and keys are treated as separate entities. The domain & record
+ storage is thus almost completely devoid of DNSSEC record types.
+ </para>
+ <para>
+ Instead, keying material is stored separately, allowing operators to focus on the already complicated task
+ of keeping DNS data correct. In practice, DNSSEC related material is often stored within the same database,
+ but within separate tables.
+ </para>
+ <para>
+ If a DNSSEC configuration is found for a domain, the PowerDNS daemon will provide keys, signatures and (hashed)
+ denials of existence automatically.
+ </para>
+ <para>
+ As an example, securing an existing zone can be as simple as:
+ <screen>
+$ pdnssec secure-zone powerdnssec.org
+$ pdnssec rectify-zone
+ </screen>
+ </para>
+ <section id="dnssec-introduction">
+ <title>A brief introduction to DNSSEC</title>
+ <para>
+ DNSSEC is a complicated subject, but it is not required to know all the ins and outs of this protocol to be able to use PowerDNSSEC.
+ In this section, we explain the core concepts that are needed to operate a PowerDNSSEC installation.
+ </para>
+ <para>
+ Zone material is enhanced with signatures using 'keys'. Such a signature (called an RRSIG) is a cryptographic guarantee that the data served
+ is the original data. DNSSEC keys are asymmetric (RSA, DSA or GOST), the public part is published over DNS and is called a
+ DNSKEY record, and is used for verification. The private part is used for signing and is never published.
+ </para>
+ <para>
+ To make sure that the internet knows that the key that is used for signing is the authentic key, confirmation can be gotten from
+ the parent zone. This means that to become operational, a zone operator will have to publish a representation of the signing key to
+ the parent zone, often a ccTLD or a gTLD. This representation is called a DS record, and is a shorter (hashed) version of the DNSKEY.
+ </para>
+ <para>
+ Once the parent zone has the DS, and the zone is signed with the DNSSEC key, we are done in theory.
+ </para>
+ <para>
+ However, for a variety of reasons, most DNSSEC operations run with another layer of keys. The so called 'Key Signing Key' is sent to the
+ parent zone, and this Key Signing Key is used to sign a new set of keys called the Zone Signing Keys.
+ </para>
+ <para>
+ This setup allows us to change our keys without having to tell the zone operator about it.
+ </para>
+ <para>
+ A final challenge is how to DNSSEC sign the answer 'no such domain'. In the language of DNS, the way to say 'there is no such domain' (NXDOMAIN)
+ or there is no such record type is to send an empty answer. Such empty answers are universal, and can't be signed.
+ </para>
+ <para>
+ In DNSSEC parlance we therefore sign a record that says 'there are no domains between A.powerdnssec.org and C.powerdnssec.org'. This
+ securely tells the world that B.powerdnssec.org does not exist. This solution is called NSEC, and is simple but has downsides - it also
+ tells the world exactly which records DO exist.
+ </para>
+ <para>
+ So alternatively, we can say that if a certain mathematical operation (an 'iterated salted hash') is performed on a question, that
+ no valid answers exist that have as outcome of this operation an answer between two very large numbers. This leads to the same 'proof of
+ non-existence'. This solution is called NSEC3.
+ </para>
+ <para>
+ A PowerDNSSEC zone can either be operated in NSEC or in one of two NSEC3 modes ('inclusive' and 'narrow').
+ </para>
+ </section>
+ <section id="dnssec-migration">
+ <title>Migration</title>
+ <para>
+ To migrate an existing database-backed PowerDNS installation, a few changes must be made to the database schema.
+ First, the records table gains two new fields: 'auth' and 'ordername'. Some data in a zone, like glue records, should
+ not be signed, and this is signified by setting 'auth' to 0.
+ </para>
+ <para>
+ Additionally, NSEC and NSEC3 in non-narrow mode require ordering data in order to perform (hashed) denial of existence. The 'ordername'
+ field is used for this purpose.
+ </para>
+ <para>
+ Finally, two new tables are needed. DNSSEC keying material is stored in the 'cryptokeys' table (in a portable standard format).
+ Domain metadata is stored in the 'domainmetadata' table. This includes NSEC3 settings.
+ </para>
+ <para>
+ Once the database schema has been changed for DNSSEC usage (see the relevant backend chapters for the update statements), the 'pdnssec'
+ tool can be used to fill out keying details, and 'rectify' the auth and ordername fields.
+ </para>
+ <para>
+ In short, 'pdnssec secure-zone powerdnssec.org && pdnssec rectify-zone powerdnssec.org' will deliver a correctly NSEC signed zone.
+ </para>
+ </section>
+ <section id="powerdnssec">
+ <title>Records, Keys, signatures, hashes within PowerDNSSEC</title>
+ <para>
+ Within PowerDNSSEC, keys are stored separately from the zone records. Zone data are only
+ combined with signatures and keys when requests come in over the internet.
+ </para>
+ <para>
+ Each zone can have a number of keys associated with it, with varying key lenghts. Typically 1 or at most 2 of these
+ keys are employed as actual Zone Signing Keys (ZSKs). During normal operations, this means that only 1 ZSK is 'active', and
+ the other is passive.
+ </para>
+ <para>
+ Should it be desired to 'roll over' to a new key, both keys can temporarily be active (and used for signing), and after a while the
+ old key can be inactivated. Subsequently it can be removed.
+ </para>
+ <para>
+ As elucidated above, there are several ways in which DNSSEC can deny the existence of a record, and this setting too is stored
+ away from zone records, and lives with the DNSSEC keying material.
+ </para>
+ <para>
+ In order to facilitate interoperability with existing technologies, PowerDNSSEC keys can be imported and exported in industry standard formats.
+ </para>
+ <para>
+ Keys and hashes are configured using the 'pdnssec' tool, which is described next.
+ </para>
+ </section>
+ <section id="pdnssec">
+ <title>'pdnssec' for PowerDNSSEC command & control</title>
+ <para>
+ 'pdnssec' is a powerful command that is the operator-friendly gateway into PowerDNSSEC configuration. Behind the scenes,
+ 'pdnssec' manipulates a PowerDNS backend database, which also means that for many databases, 'pdnssec' can be run remotely,
+ and can configure key material on different servers.
+ </para>
+ <para>
+ The following pdnssec commands are available:</para>
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>activate-zone-key ZONE KEY-ID</term>
+ <listitem>
+ <para>
+ Activate a key with id KEY-ID within a zone called ZONE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>add-zone-key ZONE [ksk|zsk] [bits]</term>
+ <listitem>
+ <para>
+ Create a new key for zone ZONE, and make it a KSK or a ZSK. WARNING: Only ZSK is supported right now, no 'KSK' or 'ZSK' should
+ be passed on the command line. WARNING: 'bits' defaults to 1024 for now and can't be passed on the command line yet.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>deactivate-zone-key ZONE KEY-ID</term>
+ <listitem>
+ <para>
+ Deactivate a key with id KEY-ID within a zone called ZONE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>export-zone-dnskey ZONE KEY-ID</term>
+ <listitem>
+ <para>
+ Export to standard output DNSKEY and DS of key with key id KEY-ID within zone called ZONE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>export-zone-dnskey ZONE KEY-ID</term>
+ <listitem>
+ <para>
+ Export to standard output full (private) key with key id KEY-ID within zone called ZONE. The format
+ used is compatible with BIND and NSD/LDNS.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>import-zone-dnskey ZONE filename [ksk|zsk]</term>
+ <listitem>
+ <para>
+ Import from 'filename' a full (private) key for zone called ZONE. The format
+ used is compatible with BIND and NSD/LDNS. WARNING: defaults to a KSK, option is ignored right now.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>rectify-zone ZONE</term>
+ <listitem>
+ <para>
+ Calculates the 'ordername' and 'auth' fields for a zone called ZONE so they comply with DNSSEC settings.
+ Can be used to fix up migrated data. Can always safely be run, it does no harm.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>remove-zone-key ZONE KEY-ID</term>
+ <listitem>
+ <para>
+ Remove a key with id KEY-ID from a zone called ZONE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>secure-zone ZONE</term>
+ <listitem>
+ <para>
+ Configures a zone called ZONE with reasonable DNSSEC settings. You should manually run 'rectify-zone' afterwards.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>set-nsec3 ZONE 'parameters' [narrow]</term>
+ <listitem>
+ <para>
+ Sets NSEC3 parameters for this zone. A sample commandline is: "pdnssec set-nsec3 powerdnssec.org '1 0 1 ab' narrow".
+ The NSEC3 parameters must be quoted on the command line.
+ WARNING: an empty salt is not yet supported!
+ WARNING: This requires updating the 'DS" over at the parent zone!
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>show-zone ZONE</term>
+ <listitem>
+ <para>
+ Shows all DNSSEC related settings of a zone called ZONE.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>unset-nsec3 ZONE</term>
+ <listitem>
+ <para>
+ Converts a zone to NSEC operations. WARNING: This requires updating the 'DS" over at the parent zone!
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </section>
+ <section id="dnssec-modes">
+ <title>Modes of operation</title>
+ <para>
+ 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.
+ </para>
+ <para>
+ This database is then replicated to all PowerDNS instances, which all serve identical records, keys
+ and signatures.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ Such a single replicated database requires no further attention beyond monitoring already required during
+ non-DNSSEC operations.
+ </para>
+ <section id="dnssec-frontserver"><title>PowerDNSSEC Front-signing</title>
+ <para>
+ As a special feature, PowerDNSSEC can operate as a signing server which operates as a slave
+ to an unsigned master.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ 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.
+ </para>
+ </section>
+ <section id="dnssec-bind-hybrid"><title>PowerDNSSEC hybrid BIND-mode operation</title>
+ <para>
+ 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.
+ </para>
+ <para>
+ However, since PowerDNS supports operation with multiple simultaneous backends, this is not a problem.
+ </para>
+ <para>
+ In hybrid mode, keying material and zone records are stored in different backends. This allows for
+ 'bindbackend' operation in full DNSSEC mode.
+ </para>
+ <para>
+ To benefit from this mode, include at least one database-based backend in the 'launch' statement.
+ </para>
+ <warning>
+ <para>
+ 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.
+ </para>
+ </warning>
+ </section>
+ </section>
+ <section id="dnssec-security"><title>Security</title>
+ <para>
+ During typical PowerDNSSEC operation, the private part of the signing keys are 'online', which can be compared
+ to operating an HTTPS server, where the certificate is available on the webserver for cryptographic purposes.
+ </para>
+ <para>
+ In some settings, having such (private) keying material available online is considered undesireable.
+ </para>
+ </section>
+ <section id="dnssec-performance"><title>Performance</title>
+ <para>
+ As of version 3.0, PowerDNSSEC has not be tuned for performance. In practice this means that operations
+ above 1000 queries per second should not yet be attempted.
+ </para>
+ </section>
+ <section id="dnssec-thanks-to"><title>Thanks to, acknowledgements</title>
+ <para>
+ PowerDNSSEC has been made possible by the help & contributions of many people.
+ We would like to thank:
+ <itemizedlist>
+ <listitem><para>Peter Koch (DENIC)</para></listitem>
+ <listitem><para>Olaf Kolkman (NLNetLabs)</para></listitem>
+ <listitem><para>Wouter Wijngaards (NLNetLabs)</para></listitem>
+ <listitem><para>Marco Davids (SIDN)</para></listitem>
+ <listitem><para>Marcus Travaille (SIDN)</para></listitem>
+ <listitem><para>Antoin Verschuren (SIDN)</para></listitem>
+ <listitem><para>Olafur Guðmundsson (IETF)</para></listitem>
+ <listitem><para>Dan Kaminsky (Recursion Ventures)</para></listitem>
+ <listitem><para>Roy Arends (Nominet)</para></listitem>
+ <listitem><para>Peter van Dijk</para></listitem>
+ <listitem><para>Maik Zumstrull</para></listitem>
+ <listitem><para>Jose Arthur Benetasso Villanova</para></listitem>
+ <listitem><para>Stefan Schmidt (CCC ;-))</para></listitem>
+ <listitem><para>Roland van Rijswijk (Surfnet)</para></listitem>
+ <listitem><para>Paul Bakker (Brainspark/Fox-IT)</para></listitem>
+ <listitem><para>Mathew Hennessy</para></listitem>
+ <listitem><para>Johannes Kuehrer (Austrian World4You GmbH)</para></listitem>
+ <listitem><para>Marc van de Geijn (bHosted.nl)</para></listitem>
+ <listitem><para>Stefan Arentz</para></listitem>
+ <listitem><para>.. this list is far from complete yet .. </para></listitem>
+ </itemizedlist>
+
+ </para>
+ </section>
+ </chapter>
<chapter id="recursion"><title>Recursion</title>
<para>(only available from 1.99.8 and onwards, recursing component available since 2.9.5)</para>
<para>
projects / pdns / commitdiff