6318052d9e
lots of new features compared to 9.4.x, including: Full NSEC3 support Automatic zone re-signing New update-policy methods tcp-self and 6to4-self DHCID support. More detailed statistics counters including those supported in BIND 8. Faster ACL processing. Efficient LRU cache-cleaning mechanism. NSID support.
129 lines
5.2 KiB
Plaintext
129 lines
5.2 KiB
Plaintext
|
|
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.
|