DNSSEC Deployment at the RIPE NCC

Deployment of Domain Name System Security Extensions (DNSSEC) was the second (and last) phase of the Reverse DNS restructuring project.

During the first phase of this project we:

• modified internal databases to make the RIPE Whois Database the authoritative source for zone file generation
• changed the interface for creation and maintenance of delegation of reverse domains
• introduced the "mnt-domains:" attribute
• cleaned up inconsistent data
• simplified the requirements for reverse delegation

During the second phase of the project, we shifted the focus onto deployment of DNSSEC on the reverse tree. During this phase we:

• enabled DNSSEC support on our DNS server infrastructure
• introduced the infrastructure and procedures for maintaining the keys needed to sign DNS data
• introduced the mechanisms and tools for the exchange of key information between child and parent

Steps in Deployment

Zone Signing

Keypairs are needed to sign zones. The private keys must be protected, while the public keys must be added to the zones. The keys need to be maintained (2). We built a signer application that could be used to maintain the private keys and sign the zones. We based this on existing tools (4).

We produced a key maintenance procedure. It described how we would replace keys and how we would let people know about changes to the keys used.

DNS Server Architecture

Primary and secondary servers had to support the DNSSEC protocol (1). As we do not control most secondary servers we replied on the operators that do. We arranged an upgrade of the infrastructure.

Provisioning of Secure Delegations

Maintainers of reverse zones needed to get a secure delegation. These are represented through Delegation Signer Resource Records (DSRRs) that appear in the parent zone. The DSRRs point to DNSKEY Resource Records. Maintainers could get a secure delegation by submitting domain objects to the RIPE Whois Database.

We explained how to do this in the Registry Procedure.

We provided a web interface to help create domain objects. When you submit new domain objects with secure delegation requests, the delegation checker will look at them. We explain the requirements for this in the Registry Procedure. You can find more detailed information in the Delegation Checker modifications page.

There was no change to existing authentication mechanisms. Key exchange is based on the authentication of domain objects. For authentication mechanisms based on public key cryptography (PGP and X.509), we introduced additional checks on the timestamp of signatures.

Milestones

The rollout of DNSSEC mainly involved changes to our internal infrastructure, however there were a number of publicly visible milestones. We implemented DNSSEC one zone at a time.

• First Half of July 2005: We upgraded the RIPE NCC authoritative servers to BIND9.3.0 with dnssec-enable off or to NSD2.1 (or to other available DNSSEC aware implementations).
  o We also continued to upgrade slave servers.
• July 2005: We asked for comments on the draft policy procedure.
• August 2005: We made changes based on feedback from the community. We let everyone know the revised specification.
• Beginning Q3, 2005: We turned on 'dnssec awareness' (dnssec-enable on for BIND). We served all zones as they were previously (without DNSSEC Resource Records).
  o From this date, we started to support signed zones on our secondary servers.
• Beginning Q3, 2005: We deployed the signing infrastructure. We started by signing a forward zone that was not in production.
• Mid Q3 2005: We gradually introduced the signed versions of forward zones.
• End Q3 2005: We introduced signed reverse zones, one by one, to avoid any possible server load problems. (These zones did not contain secure delegations).
• Mid Q3 2005: The backend infrastructure was ready to deal with secure delegations.
• End Q3/Q4 2005: We introduced secure delegations. We offered these on a zone by zone basis.
  

We proposed a policy to extend the "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region" (5). You can read the draft policy proposal here. The DNS WG chairs invited feedback.

We also published the procedures for key maintenance and for for requesting secure delegations from the RIPE NCC.

References

(1) RFC4033, RFC4034 and RFC4035: The DNSSEC specifications.

(2) draft-ietf-dnsop-dnssec-operational-practices-04.txt

(3) DNSSEC HOWTO: The HOWTO describing how to deploy DNSSEC yourself

(4) Key maintenance tools: Beta version of the key maintenance tools that the RIPE NCC will use.

(5) Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region