mirror of
https://github.com/isc-projects/bind9.git
synced 2026-03-30 06:16:12 -04:00
148 lines
6 KiB
Text
148 lines
6 KiB
Text
|
|
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. The NSEC record at the
|
|
apex will be added last to signal that there is a complete NSEC chain.
|
|
Additionally when the zone is fully signed the private type (default
|
|
TYPE65534) records will have a non zero value for the final octet for
|
|
those record with a none zero initial octet.
|
|
|
|
The private type record format:
|
|
If the first octet is non-zero then the record indicates that the zone needs
|
|
to be signed with the key matching the record or that all signatures that
|
|
match the record should be removed.
|
|
|
|
algorithm (octet 1)
|
|
key id in network order (octet 2 and 3)
|
|
removal flag (octet 4)
|
|
complete flag (octet 5)
|
|
|
|
Only records with the complete flag set can be removed via nsupdate.
|
|
Attempts to remove other private type records will be silently ignored.
|
|
|
|
If the first octet is zero (this is a reserved algorithm number
|
|
that should never appear in a DNSKEY record) then the record indicates
|
|
changes to the NSEC3 chains are in progress. The rest of the record
|
|
contains a NSEC3PARAM record. The flag field tells what operation
|
|
to perform based on the flag bits.
|
|
|
|
0x01 OPTOUT
|
|
0x80 CREATE
|
|
0x40 REMOVE
|
|
0x20 NONSEC
|
|
|
|
If you wish to go straight to a secure zone using NSEC3 you should
|
|
also add a NSEC3PARAM 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 record won't show up or be deleted until named has had a chance
|
|
to build/remove the relevent chain. A private type record will be
|
|
created to record the operatation and will be removed once the
|
|
operation completes.
|
|
|
|
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. This requires
|
|
secure-to-insecure to be set in named.conf.
|
|
|
|
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.
|