diff options
Diffstat (limited to 'NSEC3-NOTES')
| -rw-r--r-- | NSEC3-NOTES | 128 |
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. |