DS Resource Record
DS-RR (Delegation Signer Resource Record ) are used to concatenate DNSSEC -signed zones . This allows several DNS zones to be combined into a chain of trust and validated using a single public key.
background
Today, public key systems are considered to be powerful and versatile encryption methods . The owner of a key, for example, signs a message with the private key known only to himself . A recipient can verify this signature with the aid of the corresponding public key and thus ensure that the message actually originates from the sender and that it is unadulterated.
A basic problem of public key systems is the distribution of public keys: How does a user make his public key known to the world? The real problem with using DNSSEC is that the number of zones (and thus the number of keys) can be as large as desired. In addition, such keys must be renewed regularly.
The basic idea is to link all the zones involved and only use the top one as a secure entry point . The propagation of the public key is only required for this one zone.
construction
A DS record always occurs together with an NS resource record . Both refer to a subzone. The hash of the secure entry point of the subzone is in the DS record. Each DS entry is digitally signed with the zone key of the zone in which it is located. This can be used to validate the public key of this subzone. A subzone can in turn contain DS records that refer to further subzones. This creates a chain starting from the top zone, the so-called Chain of Trust .
A DS-RR consists of the following fields:
- Label
- Name of the subzone to be chained
- Type
- DS (type code 43)
- ID
- Identification number (key tag)
- Encryption method
- 3 = DSA / SHA1 , 5 = RSA / SHA1, 6 = DSA-NSEC3-SHA1, 7 = RSASHA1-NSEC3-SHA1, 8 = RSA / SHA-256 , 10 = RSA / SHA-512, 12 = GOST R 35.10- 2001, 13 = ECDSA- P256 / SHA256, 14 = ECDSA-P384 / SHA384, 15 = ED 25519, 16 = ED448
- The procedure mentioned is not used to cryptographically secure the hash, but rather specifies the signing procedure used for the referenced key.
- Methods 1, 2 and 4 are not approved for zone signatures. All other procedures are either not defined or not approved.
- Hash type
- 1 = SHA-1, 2 = SHA-256, 3 = GOST R 34.11-94, 4 = SHA-384
- Hash
Hash type 1 ( SHA-1 ) is still allowed for reasons of backward compatibility, but is not recommended.
Calculation of the DS
The DS record can be calculated from the DNSKEY, but not the other way around. For this purpose, the hash is calculated using the following values of the DNSKEY.
Example:
SHA_256(DNSKEY owner name | Flags | Protocol | Algorithm | Public Key)
The sign | stands for the sequence of values. The public key must not contain any spaces and must be decoded from the Base64 format.
example
In this example, a delegation refers to the subzone filiale1.example.org from the example.org zone. The hash value listed in the DS-record corresponds to the key signature key of the filiale1.example.org subzone.
filiale1.example.org. NS nsf
filiale1.example.org. DS ; Typ
52037 ; Identifikationsnummer
1 ; Verschlüsselungsverfahren
1 ; Hash-Typ
378929E92D7DA04267EE87E802D75C5CA1B5D280
weak spot
In order to be included in a chain of trust, the public key of a zone of the higher-level zone must be transmitted. This can be difficult if it is managed by an entity outside of one's own sphere of influence and therefore offers points of attack.
Web links
- RFC 4034 - Resource Records for the DNS Security Extension
- RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
- RFC 6605 - ECDSA for DNSSEC