Requesting Secure Delegation in the ENUM Domain
Example of an ENUM domain object, including a "ds-rdata:" attribute
domain: 1.3.e164.arpa descr: Stichting ENUM Nederland org: ORG-SEN3-RIPE admin-c: MD6066-RIPE tech-c: ENT6-RIPE zone-c: ENT6-RIPE nserver: ns1.enum.nl nserver: ns7.domain-registry.nl ds-rdata: 10567 5 1 8f138cd3e55db6590f51fe47e390a2d1743b5bd4 mnt-by: ENUM-NL-MNT source: RIPE # Filtered
The four steps to updating an ENUM delegation to have a secure DS record in e164.arpa
Step 1: Setup your servers to serve a secure zone.
Ensure that the zone you are serving is signed and it contains a Key Signing Key (KSK) marked with the SEP flag.
Step 2: Create your domain object.
The "ds-rdata:" attribute of your domain object should be created by performing a hash over the SEP KSK key. An easy way to create a domain object which includes the ds-rdata: hash is to visit the RIPE NCC Delegation Checker, input your zone name and follow the instructions provided. The end result will be a domain object you can use in Step 3.
Step 3: Submitting the domain object
Once you have set up your server(s) to serve the ENUM zones you are ready to request delegation by submitting a domain object:
1. By using webupdates
- First authorise yourself in the authorisation section. Then go to the add section
- Select domain, by clicking on 'Create a New Object' and then click on 'Add Object'
- Fill in all the available fields
- Use the 'Add New Field' feature to add at least two "nserver:" attributes. Here, you supply the names of the name servers that are serving the zones as set up in Step 3 and that you have specified in the NS resource records of those zones
- For the "mnt-by:" attribute use the mntner you prepared in Step 1
2: By email
You need to create a domain object containing information about the zone you need reverse delegation for. For details on creation and authorisation please refer to the RIPE Database Reference Manuals.
These are the basic steps:
Obtain a template using whois -t domain and fill in the details.
domain: [mandatory] [single] [primary/look-up key]
(1)
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]
(2)
sub-dom: [optional] [multiple] [inverse key]
dom-net: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
(3)
mnt-by: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
refer: [optional] [single] [ ]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
(1) Here you put the name of your domain.
(2) Enter the names of your name servers which correspond to the name servers as used in Step 3; use multiple lines, one nserver: name server name per line. Do not forget to include ns.ripe.net if you request reverse delegation for a IPv4/16 domain. Do not include ns.ripe.net in other cases.
(3) For the "mnt-by:" attribute you use the mntner you prepared in Step 1
Send your domain object to [email protected].
Step 3: Verifying the setup
Once you have submitted the domain object you will receive a notification.
You should then be able to query for your object in the RIPE Database (e.g whois -h whois.ripe.net 1.3.e164.arpa). After the object appears in the RIPE Database it may take between 15 and 60 minutes before the delegation information is available in the DNS.
The ultimate test is to query a recursive name server that is not authoritative for your zone for a record from your zone.
Please contact us if, six hours after the appearance of your domain object in the database, your delegation does not appear. Include the details such as name server addresses and the domain object in your request. Also include the full response, including headers, as received from the database.
Any resolver which has the DNSSEC public key for e164.arpa configured should now return DNS answers which have the authenticated data bit set.
Additional Notes
From time to time, you may have to roll the keys in your zone. When you do this, make sure that you also update the ds-rdata information. This places a new DS record in the parent zone.
For further details on rolling keys and other important information on DNSSEC operational practices we recommend reading RFC 4641.