| Internet-Draft | Initialisation of DNSSEC Policy for DNS | April 2025 |
| Dyson | Expires 27 October 2025 | [Page] |
This document describes an update to "DNS Catalog Zones" ([RFC9432]) that facilitates a method to signal DNSSEC policy to DNSSEC signers for member zone(s) using information contained within a catalog zone.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 October 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document is a companion to draft-dyson-primary-zonefile-initialisation in that between them, and in conjunction with "DNS Catalog Zones" ([RFC9432]) and "Dynamic Updates in the Domain Name System (DNS UPDATE)" ([RFC2136]), it becomes possible to complete the end to end initialisation of the provisioning, distribution, signing and serving of a new zone using standards-defined mechanisms.¶
The key steps covered are:¶
Dynamically add a new zone to a catalog ("DNS Dynamic Updates" ([RFC2136]), "DNS Catalog Zones" ([RFC9432]))¶
Have a designated primary server initialise the zone and serve it (draft-dyson-primary-zonefile-initialisation)¶
Have secondary servers automatically add and transfer the zone ("DNS Catalog Zones" ([RFC9432]))¶
Have designated DNSSEC signer(s) initialise keys and signing policy for the zone (this document)¶
Operators of large scale DNS systems may want to be able to signal the creation of keys as well as key lifetime and other DNSSEC related policy parameters as part of an end-to-end automated mechanism. Further, they may want to avoid the need or overhead of engineering a bespoke solution with the ongoing need to support and maintain it.¶
This document defines a vendor-independent mechanism of signalling DNSSEC policy parameters to DNSSEC signer(s) consuming a catalog zone.¶
Broader provisioning of the base nameserver configuration is beyond the scope of this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following is in addition to the conventions and definitions as defined in "DNS Catalog Zones" ([RFC9432]).¶
The use of parenthesis in the examples is as described in "Domain Names - Implementation and Specification" ([RFC1035]) Section 5.1.¶
This section specifies new Catalog Zone level properties, additional to those defined in "DNS Catalog Zones" ([RFC9432]).¶
For this memo, the value of the version.$CATZ TXT resource record is unchanged.¶
"DNS Catalog Zones" ([RFC9432]) Section 3 is clear that "Catalog consumers MUST ignore any RRs in the catalog zone for which no processing is specified or which are otherwise not supported by the implementation." and as such the addition of the records outlined in this document will be ignored by implementations that do not recognise them.¶
If the catalog zone consumer is configured to be a signer of the member zone being processed, the server MUST apply the policy in the catalog. This action does not have to be constrained to the point at which a member zone is newly added to the catalog zone. If a catalog zone is re-configured such that signing is added or updated, the policy MUST be applied to existing members zones within the catalog.¶
If the server consuming the catalog zone is not configured to be a signer for the member zones in the catalog, records within the bailiwick of the dnssec property record MUST be ignored.¶
The "dnssec" property and labels within that bailiwick are OPTIONAL and if absent then no special processing relating to DNSSEC should occur.¶
A number of sub-properties, expressed as labels within the bailiwick of the "dnssec" label, define the initialisation parameters.¶
The "enabled" property is used to signal whether zones should be signed.¶
It is OPTIONAL and if absent, defaults to "1".¶
This can be configured at both the catalog zone level, as well as at the member zone level. As such, it facilitates the ability to set policy parameters at the catalog level, and then override that setting on a per member zone level.¶
The only parameter is a boolean, stored as a character-string in the RDATA of a TXT resource record.¶
If the implementation has the concept of pre-configured DNSSEC policy, the "policy" property can be used to indicate the name of such a policy.¶
The "policy" property is OPTIONAL. If present, then its value takes priority over policy defined in the catalog.¶
If the named policy is not configured on the designated signing server, then an error SHOULD be logged. DNSSEC related processing MAY continue if the other dnssec properties are present and correct. Otherwise, processing SHOULD continue as if the entire dnssec property section was absent.¶
Note that the member zone section permits the catalog zone level settings to be overridden. A global policy can be overridden with either a different policy, or with key details at the member zone level (see Section 4).¶
The only parameter is a character-string in the RDATA of a TXT resource record containing name of the pre-configured policy.¶
The "key" property is used to configure keys that will be applied to the member zone(s) in the catalog.¶
In the case of a single combined key (type csk), at least one key MUST be defined.¶
In the case of split keys (types zsk, ksk), at least one key of each type MUST be defined.¶
If parameters are omitted, such as key sizes or timing parameters, sensible defaults following the guidance of "DNSSEC Operational Practices, Version 2" ([RFC6781]) MUST be used.¶
The "type" parameter MUST be present, and is used to convey the key type. It MUST be one of csk, zsk or ksk¶
The "alg" parameter MUST be present, and is used to convey the key algorithm. Algorithms can be specified by name or number (see IANA Registry "DNS Security Algorithm Numbers").¶
The "bits" parameter is OPTIONAL, depending on whether this is relevant to the algorithm being used.¶
The "lifetime" parameter is OPTIONAL and is used to specify how long the key should be published for before being rolled.¶
A value of zero (0) is used to indicate "unlimited" whereby the key will not be rolled. This is also the default if unspecified.¶
Combined Key¶
key.dnskey.$CATZ IN TXT "type=csk alg=RSASHA256 bits=2048 lifetime=0"¶
Split Key. The KSK will have unlimited lifetime due to the omitted lifetime parameter defaulting to zero (0). The ZSK will have a lifetime of 90 days.¶
key.dnssec.$CATZ IN TXT "type=ksk alg=ECDSAP256SHA256" key.dnssec.$CATZ IN TXT "type=zsk alg=ECDSAP256SHA256 lifetime=90D"¶
The nsec parameter is OPTIONAL.¶
If absent, it defaults to the value "nsec".¶
The only parameter is a character-string in the RDATA of a TXT resource record containing the preferred NSEC mechanism.¶
If the desired mechanism is NSEC3, the NSEC3 parameters MAY be supplied immediately after, separated by a space. If supplied, they MUST be compliant with "DNSSEC Security (DNSSEC) Hashed Authenticated Denial of Existence" ([RFC5155]) Section 3.3.¶
If the value is set to "nsec3" and the NSEC3 parameters are omitted, the values MUST default to "1 0 0 -" as per "Guidance for NSEC3 Parameter Setting" ([BCP236]) Section 3.1.¶
The default properties outlined above can be overridden per member zone. If properties are specified in a more specific scope than the defaults, the most specific scope MUST be used.¶
A subset MAY be specified in a more specific scope, for example, the SOA could be omitted, and just the NS records or DNSSEC parameters specified.¶
The omitted properties would be inherited from the catalog level values.¶
Similarly, if parameters for a property are defined at the catalog zone level, and only some parameters are overridden at the member zone level, the other parameters SHOULD be inherited from the catalog zone level.¶
<unique-N>.zones.$CATZ 0 PTR example.com.
enabled.dnssec.<unique-N>.zones.$CATZ IN TXT "1"
key.dnssec.<unique-N>.zones.$CATZ IN TXT ( "type=csk"
"alg=ECDSAP256SHA256" )
nsec.dnssec.<unique-N>.zones.$CATZ IN TXT "nsec3"
¶
There is no change to the coo property; if the member zone changes ownership to another catalog, fundamentally, the zone's master file already exists.¶
The scope of this document is solely concerned with the initialisation of a new zone's master file, and so in the case of the zone changing ownership, the initialisation parameters MUST NOT be processed.¶
Noting that the primary server for a given catalog's member zones may not be the primary server for the catalog zone itself, nor the primary server for another catalog's member zones, operators should consider their implementation's configuration when planning a change of ownership operation.¶
If the member zone is removed from the catalog zone, then any data or configuration related to the DNSSEC signing of the zone MUST also be removed unless the implementation provides a configuration option that facilitates retention.¶
In the event of a zone state reset being carried out, the state of the zone's master file MUST be reset as if the file was being initialised for the first time per this document.¶
When configuring the use of catalog zones, implementations should give the operator the ability to indicate whether the catalog zone consumer is a DNSSEC signer of the catalog's member zones.¶
This document does not alter the security considerations outlined in "DNS Catalog Zones" ([RFC9432]).¶
IANA is requested to add the following entries to the registry:¶
Registry Name: DNS Catalog Zones Properties¶
Reference: this document¶
| Property Prefix | Description | Status | Reference |
|---|---|---|---|
| dnssec | DNSSEC Properties | Standards Track | this document |
| enabled.dnssec | Enable/Disable DNSSEC Signing | Standards Track | this document |
| policy.dnssec | DNSSEC Policy | Standards Track | this document |
| key.dnssec | DNSSEC Keys | Standards Track | this document |
| nsec.dnssec | DNSSEC Proof of Non Existence | Standards Track | this document |
Field meanings are unchanged from the definitions in "DNS Catalog Zones" ([RFC9432]).¶
The following is an example catalog zone showing some of the additional properties and parameters as outlined in this document.¶
By default, zones are signed with ECDSAP256SHA256, and NSEC is used for proof of non existence.¶
The example.com zone is not signed at all.¶
The example.org zone is signed with RSASHA256 with 2048 bit keys.¶
The example.net zone is signed with NSEC3 with OptOut set.¶
catz.invalid. 0 SOA invalid. invalid. (
1 3600 600 2419200 3600 )
catz.invalid. 0 NS invalid.
enabled.dnssec.catz.invalid. 0 TXT "1"
key.dnssec.catz.invalid. 0 TXT ( "type=zsk"
"alg=ECDSAP256SHA256" )
key.dnssec.catz.invalid. 0 TXT ( "type=ksk"
"alg=ECDSAP256SHA256" )
nsec.dnssec.catz.invalid. 0 TXT "nsec"
kahdkh6f.zones.catz.invalid. 0 PTR example.com.
hajhsjha.zones.catz.invalid. 0 PTR example.net.
ytrytryt.zones.catz.invalid. 0 PTR example.org.
enabled.dnssec.kahdkh6f.zones.catz.invalid. 0 TXT "0"
key.dnssec.ytrytryt.zones.catz.invalid. 0 TXT ( "type=zsk"
"alg=RSASHA256 bits=2048" )
key.dnssec.ytrytryt.zones.catz.invalid. 0 TXT ( "type=ksk"
"alg=RSASHA256 bits=2048" )
nsec.hajhsjha.zones.catz.invalid. 0 TXT "nsec3 1 1 0 -"
¶
NB: To be removed by the RFC Editor prior to publication.¶
TODO acknowledge.¶