Skip to main content

Procedure for Requesting DNSSEC 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 expiration of the signature validity period of a signed RRset as an upper bound for the TTL". As a result query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. We currently test on the TTL being at least 2 times smaller than the signature validity period. See [6].

These tests will only be done for "ds-rdata:" attributes using supported digest types [1 section 5.1.3]. Currently we support digest type 1(SHA1).

If the "ds-rdata:" attribute uses an unsupported digest type, you will see a warning message, however the "ds-rdata:" content will still be copied into the parent zone.

4.0 Web Interface Restrictions

The RIPE NCC e will develop a web interface to make it easy to create domain objects with the appropriate "ds-rdata:" attributes. It will have some operational restrictions

  • It will use the SEP flag to select the keys for which DSRRs are needed.
  • It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute.

If you find these conditions too restrictive, you can construct domain objects manually.

4.0 References

[1] DNS Security Introduction and Requirements, Arends et al, RFC4033"
http://www.ietf.org/rfc/rfc4033.txt

[2] Resource Records for the DNS Security Extensions, Arends et al, RFC4034:
http://www.ietf.org/rfc/rfc4034.txt

[3] Protocol Modifications for the DNS Security Extensions, Arends et al, RFC4035:
http://www.ietf.org/rfc/rfc4035.txt

[4] DNSSEC HOWTO, O.M. Kolkman, RIPE NCC:
http://www.amsterdamned.org/projects/disi/dnssec_howto/

[5] A DNSSEC information portal:
http://www.dnssec.net/

[6] draft-ietf-dnsop-dnssec-operational-practices-04.txt (work in progress).