AFRINIC DNSSEC Service

AFRINIC manages and publishes Reverse DNS (RDNS) zone data for the IP space we allocate or assign to members.

Zones includes

IPv4

41.in-addr.arpa.

196.in-addr.arpa.

197.in-addr.arpa.

102.in-addr.arpa.

105.in-addr.arpa.

154.in-addr.arpa.

IPv6

0.c.2.ip6.arpa.

3.4.1.0.0.2.ip6.arpa.

2.4.1.0.0.2.ip6.arpa.

Objective

DNSSEC deployment at AFRINIC aims to

Sign these zones.

Publish DS record in parent zones

Accept DS records from our members

It allows the community to validate authoritative DNS data from AFRINIC's RDNS zones and members to publish DS records to build the chain of trust for their RDNS zones.

DNSSEC deployment is a NRO coordinated project as ERX blocks need coordinated actions. All communications regarding these projects should be sent to dnssec-ops[at]afrinic[dot]net

We have adopted a plan for a carefully incremental deployment of DNSSEC at AFRINIC.

Deployment Plan

Once the testing phase is completed, AFRINIC will integrate the Signer into the provisioning system in 3 phases. In this phase, the provisioning system continues to work as it is. When new zones are generated, copies of the distributed unsigned zones are passed to the signer to produce a signed zone.

Deployment Test Phases

Install the tools (Opendnssec, NSD, BIND, DSC, etc.)

Generate keys for the zones - KSK RSA 2048 / ZSK RSA 1024

Get Unsigned zone into OpenDNSSEC and sign

Publish the signed zones under the local DNS servers

Query and analyse response sizes over UDP and TCP

Validation using keys as trusted keys

Test Keys rollover: ZSK and KSK

Scheduled key rollovers and emergency key rollover

Conclusions and lessons learnt

Phase 1 - Published Unsigned Zones

The signed zone is checked and loaded on a public DNS server. All tests are conducted around the public DNS server. AFRINIC will evaluate here the operation of the signer and the updated provisioning system.

The new provisioning system: consistent signed zones generation

Consistency check for zones content: non DNSSEC queries on both (unsigned and signed)

DNSSEC queries to the signed zones

Conclusions and lessons learnt

Phase 2

Publish Signed Zones

With a successful previous stage, the next step will be to start publishing signed zones instead of unsigned zones. In this phase, the Reverse DNS provisioning system will start publishing signed zones with adequate notification and a rollback plan. Only zones produced by the signer are distributed to the NS servers.

Test

Zones transfer master/slaves consistency

Non dnssec queries on all NS

DNSsec queries on all NS

Conclusions and lessons learnt

Rollback Plan

Rollback from the phase where AfriNIC is publishing signed zones without DS in parent zones is as follows:

A maintenance window for the rollback is open.

Notice of the impending maintenance, with a technical description of the change, will be sent to the community.

During the maintenance window, AfriNIC will begin to serve an unsigned zones, stripped of all DNSSEC information. SOA serial increases in order to trigger the distribution of the unsigned zone.

A detailed technical report of the circumstances leading to the rollback, and the execution of the rollback itself are sent to the community.

Phase 3

DS publication in parent zones

With the publishing of signed zones completed, AFRINIC RDNS zones are not yet DNSSEC secured. DS records of KSKs have to be published in the parent zones. DS records will be generated and sent to IANA through their RDNS management system.

The provisioning will be configured to process DS records for sub-domains. The signer and the zones publication are not modified. With a full DNSSEC system tested and launched with measures in place to operate as per the DPS, the project will move to the normal AFRINIC operations. Monitoring and performance measurement will be constant activities.

Tests

Query for the DS record on all ip6.arpa and in-addr.arpa servers

DNSSEC validation of signed RRs in AFRINIC signed zones with root key as trusted key

Conclusions and lessons learnt

Rollback Plan

Rollback from the phase where AfriNIC is publishing signed zones with DS in parent zones is as follows:

A maintenance window for the rollback is open.

Notice of the circumstances and the remedial action intended, with technical detail, will be sent to the community.

AfriNIC will execute an emergency KSK rollover to remove the DS records from parent zones.

Public communication with the community will continue, with the goal of ensuring that news of the situation and the actions being taken are communicated to as wide a public audience as possible.

Following the appropriate publication delay, as specified by the DPS, AfriNIC will execute a transition to an unsigned zones as described in the phase where AfriNIC is publishing signed zones without DS in parent zones.

DNSSEC delegations

This section describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations.

Please note that until further notice from AfriNIC, DS RECORDS will not be visible in the DNS. Watch out for upcoming news from us.

1 - The DOMAIN Object

You can request reverse delegation by submitting domain objects via auto-dbm(e-mail) or via MyAFRINIC, which is the recommended method[1]. DNSSEC will not mean any change to the existing authorization mechanisms. To enable the DNSSEC delegation, the domain object now includes a "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 and signs the DS Resource Record. The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute).

Check if the algorithm of the key matches the key algorithm in the DS attributes

Check if the digest matches the Key with the corresponding tag in child zone

Check if there an RRSIG covering the DNSKEY corresponding to the DS submitted and is valid.

[1] Currently there is no check and validation for DS submitted through auto-dbm

AFRINIC DNSSEC Communication plan

Effective communication is critical for the success of this effort, the transition being undertaken having a potential impact AFRINIC RDNS services. Communication with AFRINIC members and the community at large is important. The staged deployment strategy allows time for the impact of these incremental steps to be communicated back to the team executing them. In order for the right decisions to be made it is vital that the appropriate channels are in place to encourage that communication to happen.

Announcements, releases and other pertinent information will be published on the AFRINIC. Periodic technical status updates will be sent to various mailing lists in order to keep technical and operational communities informed of developments.

The e-mail address dnssec-ops [at]AFRINIC.net will allow any interested party to communicate directly with the project team. A mailing list dnssec-discuss [at] afrinic.net will be used to discuss AFRINIC's DNSSEC deployment and services