Procedure for Requesting DNSSEC Delegations
Document ID: TBD
Date: September 2005
This document describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations..
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] [ ]
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 ).
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.
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  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  suggests that "the resolver may use the time remaining before