summaryrefslogtreecommitdiffstats
path: root/NSEC3-NOTES
diff options
context:
space:
mode:
authorMartin Nagy <mnagy@redhat.com>2009-02-11 20:37:59 +0100
committerMartin Nagy <mnagy@redhat.com>2009-02-11 20:37:59 +0100
commitf50ae72ec3417cae55dd4e085991c01af9fdc5f1 (patch)
tree0e36c9a3320f6d068df93d3ff6d84b821d23db40 /NSEC3-NOTES
downloadbind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.zip
bind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.tar.gz
bind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.tar.xz
Initial commitstart
Diffstat (limited to 'NSEC3-NOTES')
-rw-r--r--NSEC3-NOTES128
1 files changed, 128 insertions, 0 deletions
diff --git a/NSEC3-NOTES b/NSEC3-NOTES
new file mode 100644
index 0000000..d23b20e
--- /dev/null
+++ b/NSEC3-NOTES
@@ -0,0 +1,128 @@
+
+ DNSSEC and UPDATE
+
+ Converting from insecure to secure
+
+As of BIND 9.6.0 it is possible to move a zone between being insecure
+to secure and back again. A secure zone can be using NSEC or NSEC3.
+
+To move a zone from insecure to secure you need to configure named
+so that it can see the K* files which contain the public and private
+parts of the keys that will be used to sign the zone. These files
+will have been generated by dnssec-keygen. You can do this by
+placing them in the key-directory as specified in named.conf.
+
+ zone example.net {
+ type master;
+ allow-update { .... };
+ file "dynamic/example.net/example.net";
+ key-directory "dynamic/example.net";
+ };
+
+Assuming one KSK and one ZSK DNSKEY key have been generated. Then
+this will cause the zone to be signed with the ZSK and the DNSKEY
+RRset to be signed with the KSK DNSKEY. A NSEC chain will also be
+generated as part of the initial signing process.
+
+ % nsupdate
+ > ttl 3600
+ > update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
+ > update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
+ > send
+
+While the update request will complete almost immediately the zone
+will not be completely signed until named has had time to walk the
+zone and generate the NSEC and RRSIG records. Initially the NSEC
+record at the zone apex will have the OPT bit set. When the NSEC
+chain is complete the OPT bit will be cleared. Additionally when
+the zone is fully signed the private type (default TYPE65535) records
+will have a non zero value for the final octet.
+
+The private type record has 5 octets.
+ algorithm (octet 1)
+ key id in network order (octet 2 and 3)
+ removal flag (octet 4)
+ complete flag (octet 5)
+
+If you wish to go straight to a secure zone using NSEC3 you should
+also add a NSECPARAM record to the update request with the flags
+field set to indicate whether the NSEC3 chain will have the OPTOUT
+bit set or not.
+
+ % nsupdate
+ > ttl 3600
+ > update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
+ > update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
+ > update add example.net NSEC3PARAM 1 1 100 1234567890
+ > send
+
+Again the update request will complete almost immediately however the
+NSEC3PARAM record will have additional flag bits set indicating that the
+NSEC3 chain is under construction. When the NSEC3 chain is complete the
+flags field will be set to zero.
+
+While the initial signing and NSEC/NSEC3 chain generation is happening
+other updates are possible.
+
+ DNSKEY roll overs via UPDATE
+
+It is possible to perform key rollovers via update. You need to
+add the K* files for the new keys so that named can find them. You
+can then add the new DNSKEY RRs via update. Named will then cause
+the zone to be signed with the new keys. When the signing is
+complete the private type records will be updated so that the last
+octet is non zero.
+
+If this is for a KSK you need to inform the parent and any trust
+anchor repositories of the new KSK.
+
+You should then wait for the maximum TLL in the zone before removing the
+old DNSKEY. If it is a KSK that is being updated you also need to wait
+for the DS RRset in the parent to be updated and its TTL to expire.
+This ensures that all clients will be able to verify at least a signature
+when you remove the old DNSKEY.
+
+The old DNSKEY can be removed via UPDATE. Take care to specify
+the correct key. Named will clean out any signatures generated by
+the old key after the update completes.
+
+ NSEC3PARAM rollovers via UPDATE.
+
+Add the new NSEC3PARAM record via update. When the new NSEC3 chain
+has been generated the NSEC3PARAM flag field will be zero. At this
+point you can remove the old NSEC3PARAM record. The old chain will
+be removed after the update request completes.
+
+ Converting from NSEC to NSEC3
+
+To do this you just need to add a NSEC3PARAM record. When the
+conversion is complete the NSEC chain will have been removed and
+the NSEC3PARAM record will have a zero flag field. The NSEC3 chain
+will be generated before the NSEC chain is destroyed.
+
+ Converting from NSEC3 to NSEC
+
+To do this remove all NSEC3PARAM records with a zero flag field. The
+NSEC chain will be generated before the NSEC3 chain is removed.
+
+ Converting from secure to insecure
+
+To do this remove all the DNSKEY records. Any NSEC or NSEC3 chains
+will be removed as well as associated NSEC3PARAM records. This will
+take place after the update requests completes.
+
+ Periodic re-signing.
+
+Named will periodically re-sign RRsets which have not been re-signed
+as a result of some update action. The signature lifetimes will
+be adjusted so as to spread the re-sign load over time rather than
+all at once.
+
+ NSEC3 and OPTOUT
+
+Named only supports creating new NSEC3 chains where all the NSEC3
+records in the zone have the same OPTOUT state. Named supports
+UPDATES to zones where the NSEC3 records in the chain have mixed
+OPTOUT state. Named does not support changing the OPTOUT state of
+an individual NSEC3 record, the entire chain needs to be changed if
+the OPTOUT state of an individual NSEC3 needs to be changed.