From: Bert Hubert Date: Thu, 6 Jan 2011 20:41:19 +0000 (+0000) Subject: more docs X-Git-Tag: auth-3.0~426 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8a10e3b0e7b5fdc54ad121aec127c8232874fc36;p=pdns more docs git-svn-id: svn://svn.powerdns.com/pdns/trunk/pdns@1821 d19b8d6e-7fed-0310-83ef-9ca221ded41b --- diff --git a/pdns/docs/pdns.sgml b/pdns/docs/pdns.sgml index 0e28560d1..95d29da96 100644 --- a/pdns/docs/pdns.sgml +++ b/pdns/docs/pdns.sgml @@ -8801,12 +8801,12 @@ local0.err /var/log/pdns.err - Migrating to PDNS + Migrating to PowerDNS - Before migrating to PDNS a few things should be considered. + Before migrating to PowerDNS a few things should be considered. - PDNS does not operate as a 'slave' or 'master' server with all backends + PowerDNS does not operate as a 'slave' or 'master' server with all backends Only the Generic SQL, OpenDBX and BIND backends have the ability to act as master or slave. @@ -8960,7 +8960,346 @@ local0.err /var/log/pdns.err - + + Serving authoritative DNSSEC data + + (only available in PowerDNS 3.0 and beyond, not yet available in the PowerDNS Recursor) + + + PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data, + with minimal administrative overhead. + + + 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. + + + 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. + + + If a DNSSEC configuration is found for a domain, the PowerDNS daemon will provide keys, signatures and (hashed) + denials of existence automatically. + + + As an example, securing an existing zone can be as simple as: + +$ pdnssec secure-zone powerdnssec.org +$ pdnssec rectify-zone + + +
+ A brief introduction to DNSSEC + + 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. + + + 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. + + + 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. + + + Once the parent zone has the DS, and the zone is signed with the DNSSEC key, we are done in theory. + + + 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. + + + This setup allows us to change our keys without having to tell the zone operator about it. + + + 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. + + + 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. + + + 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. + + + A PowerDNSSEC zone can either be operated in NSEC or in one of two NSEC3 modes ('inclusive' and 'narrow'). + +
+
+ Migration + + 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. + + + 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. + + + 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. + + + 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. + + + In short, 'pdnssec secure-zone powerdnssec.org && pdnssec rectify-zone powerdnssec.org' will deliver a correctly NSEC signed zone. + +
+
+ Records, Keys, signatures, hashes within PowerDNSSEC + + 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. + + + 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. + + + 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. + + + 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. + + + In order to facilitate interoperability with existing technologies, PowerDNSSEC keys can be imported and exported in industry standard formats. + + + Keys and hashes are configured using the 'pdnssec' tool, which is described next. + +
+
+ 'pdnssec' for PowerDNSSEC command & control + + '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. + + + The following pdnssec commands are available: + + + + activate-zone-key ZONE KEY-ID + + + Activate a key with id KEY-ID within a zone called ZONE. + + + + + add-zone-key ZONE [ksk|zsk] [bits] + + + 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. + + + + + deactivate-zone-key ZONE KEY-ID + + + Deactivate a key with id KEY-ID within a zone called ZONE. + + + + + export-zone-dnskey ZONE KEY-ID + + + Export to standard output DNSKEY and DS of key with key id KEY-ID within zone called ZONE. + + + + + export-zone-dnskey ZONE KEY-ID + + + 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. + + + + + import-zone-dnskey ZONE filename [ksk|zsk] + + + 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. + + + + + rectify-zone ZONE + + + 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. + + + + + remove-zone-key ZONE KEY-ID + + + Remove a key with id KEY-ID from a zone called ZONE. + + + + + secure-zone ZONE + + + Configures a zone called ZONE with reasonable DNSSEC settings. You should manually run 'rectify-zone' afterwards. + + + + + set-nsec3 ZONE 'parameters' [narrow] + + + 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! + + + + + show-zone ZONE + + + Shows all DNSSEC related settings of a zone called ZONE. + + + + + unset-nsec3 ZONE + + + Converts a zone to NSEC operations. WARNING: This requires updating the 'DS" over at the parent zone! + + + + + +
+
+ Modes of operation + + 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. + +
PowerDNSSEC Front-signing + + 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. + +
+
PowerDNSSEC hybrid BIND-mode operation + + 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. + + + + 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. + + +
+
+
Security + + 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. + + + In some settings, having such (private) keying material available online is considered undesireable. + +
+
Performance + + 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. + +
+
Thanks to, acknowledgements + + PowerDNSSEC has been made possible by the help & contributions of many people. + We would like to thank: + + Peter Koch (DENIC) + Olaf Kolkman (NLNetLabs) + Wouter Wijngaards (NLNetLabs) + Marco Davids (SIDN) + Marcus Travaille (SIDN) + Antoin Verschuren (SIDN) + Olafur Guðmundsson (IETF) + Dan Kaminsky (Recursion Ventures) + Roy Arends (Nominet) + Peter van Dijk + Maik Zumstrull + Jose Arthur Benetasso Villanova + Stefan Schmidt (CCC ;-)) + Roland van Rijswijk (Surfnet) + Paul Bakker (Brainspark/Fox-IT) + Mathew Hennessy + Johannes Kuehrer (Austrian World4You GmbH) + Marc van de Geijn (bHosted.nl) + Stefan Arentz + .. this list is far from complete yet .. + + + +
+ Recursion (only available from 1.99.8 and onwards, recursing component available since 2.9.5)