Olaf Kolkman
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..
1.0 The DOMAIN Object
2.0 The "ds-rdata:" Attribute
3.0 Delegation Checks
4.0 Web Interface Restrictions
5.0 References
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 [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.
When it receives an update, the update engine will perform a number of checks. These are the most important:
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.
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
If you find these conditions too restrictive, you can construct domain objects manually.
[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).