AFRINIC manages and publishes Reverse DNS (RDNS) zone data for the IP space we allocate or assign to members.
| Zones includes | |
|
IPv4
|
IPv6
|
| Objective | |
|
DNSSEC deployment at AFRINIC aims to
|
|
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.
Members DS records publication
Tests
- DS processing and DS RRs signing
- Chain of trust validation from root to child zone (with DS records published)
- Conclusions and lessons learnt
DNSSEC Practice Statement - DPS
Zone Signing parameters - Key Lengths and Algorithms
- Key Signing Key: We use a key length of 2048 bits with RSA as the generation algorithm.
- Zone Signing Key: We use a key length of 1024 bits with RSA as the generation algorithm.
- Authenticated Denial of Existence: Authenticated denial of existence will be provided through the use of NSEC records as specified in RFC 4034.
- Signature Format: Our signatures are created with the SHA2-256 hash using RSA.
- Zone Signing Key Roll-over: We will roll the ZSK on a monthly basis with a pre-publishing scheme as described in RFC 4641, section 4.2.1.1.
- Key Signing Key Roll-over: We will roll the KSK on a yearly basis with a double-signing scheme as described in RFC 4641, section 4.2.1.2.
- Signature Life-time and Re-signing Frequency: We re-sign our zones once a new zone are generated with a signature lifetime of 15 days.
Resource Records Time-to-live - Record type TTL
- DNSKEY: Equal to the TTL used for the SOA record
- NSEC: Equal to the minimum field of the SOA record
- RRSIG: Equal to the lowest TTL of the record set covered
- DS: Equal to the TTL used for the NS record
DNSSEC delegations
Procedure for Requesting DNSSEC Delegations (Date: April 2012 - Version:1.0)
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.
domain: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
org: [optional] [multiple] [inverse key]
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- 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 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).
Ds-rdata: 55555 8 2 CABC3A8AF15E93741BF45096DB1D3451D93B2F541166EA44F2D4781753328CB8
3- Delegation Checks
When you submit your update through MyAFRINIC, the update engine will perform a number of check as shown by the picture below.
- Keep all the default checks MyAfrinic does on the reverse delegation
- Syntax check is done to ensure the DS entered is in the correct format:
- keytag: {0-65535}; Algorithm:{3|5|6|7|8|10|12|253|254}; Digest type:{1-3}; Digest:{alphanumeric}
- Digest length depends on digest type as follows: Type 1 (Sha1): 160 bit (40 Characters) / Type 2 (Sha256) or 3(gost): 256 bit (64 Characters)
- Check if a key exists in child zone with the key tag in the DS record
- 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 website. 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
Workshop Slides