You are here: Home > RIPE Community > RIPE Document Store > Other Documents > Procedure for Requesting DNSSEC Delegations

Procedure for Requesting DNSSEC Delegations

Sep 2005 —
This document describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations..

Olaf Kolkman

Document ID: TBD
Date: September 2005

Abstract

This document describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations..

Contents

1.0 The DOMAIN Object
2.0 The "ds-rdata:" Attribute
3.0 Delegation Checks
4.0 Web Interface Restrictions
5.0 References

1.0 The DOMAIN Object

You can request reverse delegation by submitting domain objects. DNSSEC will not mean any change the existing authorisation mechanisms. The delegation checker will only carry out DNSSEC specific tests if DNSSEC related information is being exchanged.

To allow for the exchange of DNSSEC related information, the domain object now includes a "ds-rdata:" attribute.

domain:        [mandatory]  [single]     [primary/look-up key]      
descr:         [mandatory]  [multiple]   [ ]
admin-c:       [mandatory]  [multiple]   [inverse key]
tech-c:        [mandatory]  [multiple]   [inverse key]
zone-c:        [mandatory]  [multiple]   [inverse key]
nserver:       [optional]   [multiple]   [inverse key]
ds-rdata:      [optional]   [multiple]   [inverse key]
sub-dom:       [optional]   [multiple]   [inverse key]
dom-net:       [optional]   [multiple]   [ ]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]         
mnt-by:        [optional]   [multiple]   [inverse key]
mnt-lower:     [optional]   [multiple]   [inverse key]
refer:         [optional]   [single]     [ ]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

2.0 The "ds-rdata:" Attribute

In DNSSEC the Delegation Signer (DS) Resource Record is created from a DNSKEY Resource Record by comparing it with the public key. The parent publishes the DS Resource Record (see [2]).

The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute).

ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA

The tools provided with BIND (version 9.3.0 and later) will generate a "ds set" during signing. Before an update, you can copy the DS Rdata into the attributes.

The RIPE NCC will also provide a web interface to help with creation of domain objects.

 

3.0 Delegation Checks

When it receives an update, the update engine will perform a number of checks. These are the most important:

  • Is there a matching DNSKEY available in the DNS for each "ds-rdata:" attribute that is submitted in the domain object?

  • Is there a valid RRSIG made with the DNSKEY matching the "ds-rdata:"? - The resolution protocol [3] needs this, without it the update will fail.

  • Does the DNSKEY has its "SEP" flag set? Setting the SEP flag is not mandatory. If it is not set, a warning will be produced, however the "ds-rdata:" content will still be copied to the zone.

  • Is the signature validity period close to expiring and are the Times To Live (TTLs) a reasonable fraction of the signature validity period? We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period. If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [2] suggests that "the resolver may use the time remaining before