KASP stands for "Key and Signature Policy"
kasp.xml (found by default in /etc/opendnssec) is the file that defines policies used to sign zones. Each policy comprises a series of parameters that define the way the zone is signed. This section explains the parameters by referring to the example kasp.xml file supplied with the OpenDNSSEC distribution.
Date/time durations are as specified here.
Each XML file starts with a standard element "<?xml...". As with any XML file, comments are included between the delimiters "<!--"
The enclosing element of the XML file is the element <KASP> which, with the closing element </KASP>, brackets one or more policies.
Each policy is included in the <Policy>...</Policy> elements. Each policy has a "name" attribute giving the name of the policy. The name is used to link a policy and the zones signed using it; each policy must have a unique name.
The policy named "default" is special, as it is associated with all zones that do not have a policy explicitly associated with them.
A policy can have a description associated with it. Unlike XML comments, the description can be understood by programs and may be used to document the policy, e.g. a future GUI may display a list of policies along with their description and ask you to select one for editing.
The next section of the file is the Signatures section, which lists the parameters for the signatures created using the policy.
The relationship between these elements is shown below.
Authenticated denial of existence - proving that domain names do not exist in the zone - is handled by the <Denial> section, as shown below:
<Denial> includes one element, either <NSEC3> (as shown above) or <NSEC>.
<TTL> - if present, this is the time-to-live value for the NSEC3PARAM resource records. If not present, PT0S (0) will be used as TTL (included since version 1.4.3).
This will only affect the time-to-live value for the NSEC3PARAM resource records. The time-to-live value for NSEC3 records is set to the value of the SOA <Minimum>.
Should, instead, NSEC be used as the authenticated denial of existence scheme, the <Denial> element will contain the single element
<NSEC/> - there are no other parameters.
Parameters relating to keys can be found in the <Keys> section.
The section starts with a number of parameters relating to both zone-signing keys (ZSK) and key-signing keys (KSK):
If multiple zones are associated with a policy, the presence of <ShareKeys/> indicates that a key can be shared between zones. E.g. if you have 10 zones then you will only use one set of keys instead of 10 sets. This will save space in your HSM. If this tag is absent, keys are not shared between zones.
If <Purge> is present, keys marked as dead will be automatically purged from the database after this interval.
Parameters for key-signing keys are held in the <KSK> section:
<Algorithm> determines the algorithm used for the key (the numbers reserved for each algorithm can be found in the appropriate IANA registry).
Once a zone is signed, changes to the algorithm require a rollover which is not currently handled by OpenDNSSEC. Attempts to change the algorithm on a policy will result in a warning message and a request for confirmation.
Parameters for zone-signing keys are held in the <ZSK> section, and have the same meaning as for the KSK:
The ZSK information completes the contents of the <Keys> section.
General information concerning the zones can be found in the <Zone> section:
The <SOA> element gives values of parameters for the SOA record in the signed zone.
These values will override values set for the SOA record in the input zone file and the serial in signed and unsigned zone is likely to go out of sync.
The values are:
If a DNSSEC zone is in a chain of trust, digest information about the KSKs used in the zone will be stored in DS records in the parent zone. To properly roll keys, timing information about the parent zone must be configured in the <Parent> section:
This is the last section of the policy specification, so the next element is the policy closing tag:
If there are any additional policies, they could be entered here, starting with <Policy> and ending with </Policy>. However, in this case there are no additional policies, so the file is ended by closing the <KASP> tag: