DNSSEC-SIGNZONE(1) | BIND 9 | DNSSEC-SIGNZONE(1) |
When BIND 9 is built with OpenSSL, this needs to be set to the OpenSSL engine identifier that drives the cryptographic accelerator or hardware service module (usually pkcs11).
As with end-time, an absolute time is indicated in YYYYMMDDHHMMSS notation. A time relative to the start time is indicated with +N, which is N seconds from the start time. A time relative to the current time is indicated with now+N. If no extended end-time is specified, the value of end-time is used as the default. (end-time, in turn, defaults to 30 days from the start time.) extended end-time must be later than start-time.
The default cycle interval is one quarter of the difference between the signature end and start times. So if neither end-time nor start-time is specified, dnssec-signzone generates signatures that are valid for 30 days, with a cycle interval of 7.5 days. Therefore, if any existing RRSIG records are due to expire in less than 7.5 days, they are replaced.
Signature lifetime jitter also, to some extent, benefits validators and servers by spreading out cache expiration, i.e., if large numbers of RRSIGs do not expire at the same time from all caches, there is less congestion than if all validators need to refetch at around the same time.
The post-sign verification tests ensure that for each algorithm in use there is at least one non-revoked self-signed KSK key, that all revoked KSK keys are self-signed, and that all records in the zone are signed by the algorithm. This option skips these tests.
Normally, when a previously signed zone is passed as input to the signer, and a DNSKEY record has been removed and replaced with a new one, signatures from the old key that are still within their validity period are retained. This allows the zone to continue to validate with cached copies of the old DNSKEY RRset. The -Q option forces dnssec-signzone to remove signatures from keys that are no longer active. This enables ZSK rollover using the procedure described in RFC 4641#4.2.1.1 ("Pre-Publish Key Rollover").
This option is similar to -Q, except it forces dnssec-signzone to remove signatures from keys that are no longer published. This enables ZSK rollover using the procedure described in RFC 4641#4.2.1.2 ("Double Signature Zone Signing Key Rollover").
When a key is found, its timing metadata is examined to determine how it should be used, according to the following rules. Each successive rule takes priority over the prior ones:
If the key's publication date is set and is in the past, the key is published in the zone.
If the key's activation date is set and is in the past, the key is published (regardless of publication date) and used to sign the zone.
If the key's revocation date is set and is in the past, and the key is published, then the key is revoked, and the revoked key is used to sign the zone.
If either the key's unpublication or deletion date is set and in the past, the key is NOT published or used to sign the zone, regardless of any other metadata.
If the key's sync publication date is set and is in the past, synchronization records (type CDS and/or CDNSKEY) are created.
If the key's sync deletion date is set and is in the past, synchronization records (type CDS and/or CDNSKEY) are removed.
NOTE:
WARNING:
WARNING:
% dnssec-signzone -g -o example.com db.example.com \ Kexample.com.+013+17247 db.example.com.signed %
In the above example, dnssec-signzone creates the file db.example.com.signed. This file should be referenced in a zone statement in the named.conf file.
This example re-signs a previously signed zone with default parameters. The private keys are assumed to be in the current directory.
% cp db.example.com.signed db.example.com % dnssec-signzone -o example.com db.example.com db.example.com.signed %
@PACKAGE_VERSION@ |