From: Bert Hubert Date: Mon, 10 Jan 2011 11:03:34 +0000 (+0000) Subject: more dnssec docs X-Git-Tag: auth-3.0~394 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=3dd06e53892535d5ff143d6eb261e5f45bf519e9;p=pdns more dnssec docs git-svn-id: svn://svn.powerdns.com/pdns/trunk/pdns@1853 d19b8d6e-7fed-0310-83ef-9ca221ded41b --- diff --git a/pdns/docs/pdns.xml b/pdns/docs/pdns.xml index 4d00affc6..f1e1561f5 100644 --- a/pdns/docs/pdns.xml +++ b/pdns/docs/pdns.xml @@ -9063,7 +9063,7 @@ $ pdnssec rectify-zone NSEC3 - NSEC-narrow + NSEC3-narrow DS (digest type 1, digest type 2) @@ -9080,7 +9080,7 @@ $ pdnssec rectify-zone This corresponds to: - RFC 4033: DNS Security Introduction and Requirements,Resource Records for the DNS Security Extensions, Protocol Modifications for the DNS Security Extensions + RFC 4033: DNS Security Introduction and Requirements RFC 4034: Resource Records for the DNS Security Extensions, Protocol Modifications for the DNS Security Extensions @@ -9104,28 +9104,55 @@ $ pdnssec rectify-zone
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 or the PowerDNSSEC wiki 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. - - - In addition, so will the 'zone2sql' import tool when run with the '--dnssec' flag. + This chapter discusses various migration strategies, from existing PowerDNS setups, from existing unsigned installations + and finally from previous non-PowerDNS DNSSEC deployents. +
From an existing PowerDNS installation + + 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. + + + Once the database schema has been updated, and the relevant 'gsql-dnssec' switch has been set, stricter + rules apply for filling out the database! The short version is: run pdnssec rectify-zone on all zones, even + those not secured with DNSSEC! + + + 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 or the PowerDNSSEC wiki 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. + + + In addition, so will the 'zone2sql' import tool when run with the '--dnssec' flag. + +
+
From existing non-DNSSEC non-PowerDNS setups + TBD +
+
From existing DNSSEC non-PowerDNS setups + + The 'pdnssec' tool features the option to import zone keys in the industry standard private key format, + version 1.2. To import an existing KSK, use 'pdnssec import-zone-key zonename filename KSK', replace KSK + by ZSK for a Zone Signing Key. + + + If all keys are imported using this tool, a zone will serve mostly identical records to before, with + the important change that the RRSIG inception dates will be different. + + Within PowerDNS, the 'algorithm' for RSASHA1 keys is modulated based on the NSEC3 setting. So + if an algoritm=7 key is imported in a zone with no configured NSEC3, it will appear as algorithm 5! +
Records, Keys, signatures, hashes within PowerDNSSEC @@ -9152,7 +9179,7 @@ $ pdnssec rectify-zone Keys and hashes are configured using the 'pdnssec' tool, which is described next. -
(Hashed) Denial of Existence +
(Hashed) Denial of Existence PowerDNS supports unhashed secure denial of existence using NSEC records. These are generated with the help of the (database) backend, which needs to be able to supply the 'previous' and 'next' records @@ -9174,6 +9201,25 @@ $ pdnssec rectify-zone without further involving the database.
+ +
Signatures + + In PowerDNS, signatures, as served through RRSIG records, are calculated on the fly, and heavily cached. All CPU cores + are used for the calculation. + + + RRSIGs have a validity period, in PowerDNS by default this period starts at most a week in the past, and continues + at least a week into the future. + + + Precisely speaking, the time period used is always from the start of the previous Thursday until the Thursday two weeks later. + This two-week interval jumps with one-week increments every Thursday. + + Why Thursday? POSIX-based operating systems count the time since GMT midnight January 1st of 1970, + which was a Thursday. + +
+
'pdnssec' for PowerDNSSEC command & control @@ -12318,6 +12364,7 @@ end SuperslaveNo AutoserialNo CaseDepends + DNSSECPartial, no delegation, no key storage Module namepipe Launch namepipe @@ -12649,6 +12696,7 @@ while(<>) SuperslaveNo AutoserialYes CaseInsensitive + DNSSECNo (but see Generic backend!) Module namemysql Launch namemysql @@ -12763,6 +12811,7 @@ while(<>) SuperslaveNo AutoserialNo CaseDepends + DNSSECYes, no key storage Module namebuilt in Launch namerandom @@ -12798,10 +12847,10 @@ while(<>) - MySQL PDNS backend + MySQL PowerDNS backend - MySQL backend capabilities + MySQL PowerDNS backend capabilities NativeYes @@ -12810,6 +12859,7 @@ while(<>) SuperslaveNoAutoserialYesCaseInsensitive + DNSSECNoModule namepdnsLaunch namepdns @@ -13007,6 +13057,7 @@ CREATE TABLE Zones ( SuperslaveYesAutoserialNOCaseAll lower + DNSSECYesModule name < 2.9.3pgmysqlModule name > 2.9.2gmysql and gpgsqlLaunch namegmysql and gpgsql2 and gpgsql @@ -13645,6 +13696,7 @@ insert into domains (id,name,type) values (domains_id_sequence.nextval,'netherla SlaveNoSuperslaveNoAutoserialYes + DNSSECNoModule nameoracleLaunch nameoracle @@ -13851,6 +13903,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE MasterYesSlaveYesSuperslaveYes + DNSSECYesModule namegsqlite and gsqlite3Launch namegsqlite and gsqlite3 @@ -13966,6 +14019,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE SlaveNoSuperslaveNoAutoserialYes + DNSSECNoModule namedb2Launch namedb2 @@ -14056,6 +14110,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE SlaveYesSuperslaveExperimentalAutoserialNo + DNSSECYes, but no key storageModule namenone (built in)Launchbind @@ -14344,6 +14399,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE SlaveNoSuperslaveNoAutoserialNo + DNSSECNo
@@ -14372,6 +14428,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE SlaveYes SuperslaveYes AutoserialYes (since 2.9.22) + DNSSECNo @@ -14399,6 +14456,7 @@ insert into Records (id,ZoneId, name,type,content,TimeToLive,Priority) select RE SlaveNo SuperslaveNo AutoserialNo + DNSSECYes (no key storage)