3. Nameserver Predelegation Check DNSSEC

3.1 Technical Background

For validating DNSSEC, a chain of trust must be established. To meet this requirement, the DNSSEC protocol requires that a reference to the key(s) of the delegated zone is entered into the delegating zone. Thus, the chain of trust follows the delegation path.

The relevant key is the Key Signing Key of the delegated zone, which is usually flagged as Secure Entry Point (SEP). This information is available in a DNSKEY-RR in the delegated zone and is signed here (at least) by this very DNSKEY. It is not repeated in exactly the same way in the delegating zone for reasons of space. Instead of the actual key, a corresponding finger print is stored in a DS-RR (Delegation Signer).

Provisioning of the key material is effected by means of the DNSKEY-RR.

For each domain, up to five DNSKEY-RRs may be recorded. The corresponding DS records are generated together with the zone (currently precisely one DS-RR per communicated Trust Anchor), signed and distributed with the zone.

 

3.2 Structure of the Dnskey Record

The format of the Dnskey record is described in chapter 2 of RFC 4034:

Copy 
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Under the flags, you will find one entry respectively for the fields "Zone Key" and "Secure Entry Point". Additional extensions for an automated update of a Trust Anchor are described in RFC 5011. In the "Algorithm" field the applied public key algorithm is defined. This key determines the internal structure and the size of the actual key data. Additionally, this field is used to signal the use of NSEC3 by means of alias mechanisms.

 

3.3 Differentiating between KSK and ZSK

When the DS-RR was initially introduced by the RFC 3658, one started to differentiate between the Zone Signing Key (ZSK) and the Key Signing Key (KSK). While the first one sings the actual data (RRSets) in the zone, the latter serves exclusively for authenticating the ZSK. This differentiation allows for the different requirements made to the different keys.

To update the KSK, interaction with the delegating zone is required. Thus, it should not be made too often and needs a key with a longer term of validity (and, in most cases, consequently also more characters). Updating the ZSK is much easier. Thus, this key will usually be shorter. At least with regard to the RSA procedure a shorter key will entail shorter signatures and thus smaller zone files, which in turn will lead to smaller response packets. You will find information about key length and how to update a key in RFC 4641.

While the separation makes it easier to select the parameters on the one hand, it makes the protocol more complex on the other. However, separation of the keys is not mandatory. Using only one key instead of a KSK/ZSK key pair - putting up with the above described disadvantages - is consistent with the protocol. Sometimes this option is chosen in the practice. Theoretically, other indirections could be integrated in the key relations. However, since a signature always covers a complete RRSet, any signature on the DNSKEY-RRSet must always authenticate all the keys included in that set. Thus, only the two options ZSK+KSK and ZSK=KSK need to be taken into consideration.

 

3.4 Utilizing and Publishing Keys

A DNSKEY-RR provisioned for registration is called visible if it is included in the DNSKEY-RRSet of a zone.

 

3.5 Concept for Proof of Possession

For Certification Authorities (CAs), the concept of the proof-of-possession is of importance. This concept requires that a party requesting a certificate submits a proof showing that it actually has access to the private key associated with the public key for which the certificate is requested. For security reasons, it is recommended to employ this practice also for DNSSEC (cf. 3.6.3 Use of the DNSKEY Records).

 

3.6 Technical Prerequisites and Checks

Before recording the key material in the database, and to ensure correct further processing and proper operation, the key material is subjected to a multi-stage check. First of all, the transferred data itself is checked, subsequently, further tests including the information that can be called in the DNS are carried out.

 

3.6.1 Parameters of the Provisioned DNSKEY Records

The keys handed over for registration must be unique, i.e. they must differ from one another in at least one field [if not, output of ERROR message]. It may happen that keys (Public Key) are provisioned several times with varying flags. Key tags are not checked on uniqueness [if not, output of ERROR message].

 

3.6.1.1 DNSKEY: Flags

In the Flags field you must only use bits that are flagged as assigned in the IANA registry [if not, output of ERROR message].

The field is provisioned only as a numerical value (0-65535).

1. Bit 7 (ZONE) must be set. [if not, output of ERROR message].

Specified in RFC 4034, chapter 2.1.1.

2. Bit 8 (REVOKE) must not be set. [if not, output of ERROR message].

Follows from chapter 2.1 of RFC 5011. A called-back key cannot be used as Trust Anchor.

3. Bit 15 (SEP) should be set. [if not, output of WARNING message].

This field is intended to identify the KSK in the DNSKEY-RRSet. It is considered good practice to set this field for KSKs or for Trust Anchor, even if validators shall not evaluate it.

Thus, you can currently use the values 256 (ZONE) and 257 (ZONE, SEP). However, only the latter is accepted without warning.

 

3.6.1.2 DNSKEY: Protocol

The Protocol field must have the value "3". Section 2.1.2 of RFC 4034 stipulates this value as mandatory.

 

3.6.1.3 DNSKEY: Algorithm

The Algorithm field may contain the values included in the IANA registry and marked there as available values not reserved for private use. At present, the values 3, 5, 6, 7, 8, 10, 12, 13 and 14 are supported. The only cryptographic algorithms defined are RSA, DSA, ECDSA and GOST in combination with various hash methods.

The algorithms 15 (ED25519) and 16 (ED448), which are also included in the IANA registry, are not currently supported.

 

3.6.1.4 DNSKEY: Public Key

The Public Key field contains the Base64-encoded version of the public key11. The internal structure is determined by the applied algorithm, and so are the corresponding checks:

 

RSA (relevant for the values 5, 7, 8, 10)

1. The modulus must be 512 to 4096 bit (stated numbers included) long [if not, output of ERROR message].

2. The exponent must not be longer than 128 bit [if not, output of ERROR message].

The limit values are defined in RFC 3110. As to the exponent, they are also defined by the restrictions to the line length applicable for provisioning.

The key size is not evaluated.

 

DSA (relevant for the values 3,6)

3. The T-parameter may have values between 0 and 8 (both values included) [if not, output of ERROR message].

4. The length must be 213 + T * 24 [if not, output of ERROR message].

These limit values are defined in RFC 2536.

The key size is not evaluated.

 

ECDSA (relevant for the values 13, 14)

5. If the algorithm ECDSAP256SHA256 (13) is used, the key length must be 512 bit [if not, output of ERROR message].

6. If the algorithm ECDSAP384SHA384 (14) is used, the key length must be 768 bit [if not, output of ERROR message].

These values can be deduced from RFC 6605, chapter 4.

 

GOST (relevant for the value 12)

7. The key length must be 512 bit bit [if not, output of ERROR message].

This value can be deduced from RFC 5933, chapter 2.

 

3.6.2 Visibility and Status of the DNSKEY Records

The DNSKEY-RRSet must be identical for all authoritative servers [if not, output of ERROR message].

At least one of the keys provided for registration must be visible [if not, output of ERROR message]. For every invisible key a WARNING will be issued. Possibly existing additional keys of the DNSKEY-RRSet will not be taken into consideration. It is generally assumed that the signatures obtained from the various servers are identical. However, this is neither explicitly requested nor verified. In particular for the DSA method, this approach makes online signing possible.

 

3.6.3 Use of the DNSKEY Records

At least one visible key provisioned for registration must validly sign the DNSKEY-RRSet [if not, output of ERROR message].

This requirement helps to implement the Proof of Possession.

 

3.6.4 Validating with DNSKEY Records

There must be a currently valid validation chain for the SOA-RR of the delegated zone with at least on visible key provisioned for registration [if not, output of ERROR message].

Every zone has a SOA-RR, which is checked by default within the scope of the predelegation check. The validation check is carried out to prevent security lameness.

 

3.6.5 Comprehensive Rules

Due to the DNSSEC requirements, the authoritative servers and the related infrastructure must satisfy additional needs not covered by the checks of the zone data:

1. All authoritative servers must support DNSSEC, i.e. they must deliver responses consistent with DNSSEC to DO-bit-signed requests [if not, output of ERROR message].

2. All authoritative servers should support TCP and EDNS0 of adequate packet sizes [otherwise a WARNING message will be output].

3. It must be possible to call the signed DNSKEY-RRSet at least via one of these channels (either via TCP or via EDNS0) [if not, output of ERROR message].

The predelegation checks already include a verification of DNS support via TCP. Here, the EDNS0 variant is added to cover DNSSEC. As described in 2. Nameserver Predelegation Check, initially only one of the two check variants must be supported. However, a warning is issued if a second variant is missing. This is to account for the potential consequences with regard to operation and the infringement of chapter 3 of the RFC 4035 (formerly RFC 3226). Item 3 finally stipulates the requirement that must be met anyway with regard to the aforementioned checks: access to the signed DNSKEY-RRSet.