DNSSEC Practice Statement
This document is the .nz Registry Services (NZRS) DNSSEC Practice Statement (DPS). It defines the operational procedures for the management of DNS Security Extensions (DNSSEC) in the New Zealand top-level domain (.nz) and second level domains under .nz.
This document draws on the Internet Engineering Task Force (IETF) RFC 6841 for DNSSEC Practices Statement construction, but has a number of significant differences to keep the .nz DPS appropriate for .nz.
Document title: DNSSEC Practice Statement
Last Update: Aug 11, 2011 13:46
The following roles and delegation of liability with regard to DNSSEC have been identified:
Each Registrant is responsible for determining the relevant level of security for their domain. This DPS is exclusively applicable to the top-level .nz and second level domains and describes the procedures and security controls applicable when managing and employing keys and signatures for the signing of the .nz zone.
With the support of this DPS, the relying party can determine the level of trust they may assign to DNSSEC in the .nz domain and assess their own risk.
NZRS is responsible for keeping this document updated. For updated contact details, please refer to http://www.nzrs.net.nz/contact.
This DPS is a living document and it will be updated when necessary, such as in the event of system or procedure modifications affecting the contents of this document.
Updates to this DPS will be made in the form of the publication of a new version of this document. Previous versions and changes will be made available with this document. This DPS and amendments to it are published at http://www.nzrs.net.nz/dns/dnssec/dps.
All new versions will be announced using the communication channels detailed in Section 2.1. Major revisions will also be announced to Registrars, NZNOG and any other groups that express an interest in receiving such notifications.
Only the most recent version of this DPS is applicable.
NZRS publishes DNSSEC-relevant information on NZRS's website at http://www.nzrs.net.nz/dns/dnssec.
Notifications relevant to DNSSEC in .NZ will be distributed by e-mail through the email@example.com mailing list and any other community-accepted forum.
To subscribe to the tech-announce mailing list please go to:
NZRS will publish the .nz KSK in the form of DS records directly in the root zone when available. No other trust anchors or repositories are used.
DNSSEC for a child zone is activated by publishing a signed DS record for that zone. Activation of DNSSEC must be explicitly requested by the registrant by submitting the DS records.
It is the responsibility of the Registrar to securely identify and authenticate the registrant through a suitable method for the task, and in compliance with their existing obligations in the agreement between .NZ and the Registrar.
NZRS accepts DS records through the SRS/EPP interface from each Registrar. The DS record must be valid and sent in the format indicated in the SRS protocol specification if using the SRS or according to RFC 5910 if using EPP. Up to 10 DS records can be registered per domain name.
NZRS does not validate if the Registrant is the holder of the private key. The Registrar is responsible for conducting the appropriate controls required and those considered necessary.
Only the Registrant has the authority to request the removal of the DS records.
A DS record is removed by Registrars sending a SRS/EPP request to the SRS to remove the DS record. The removal of all DS records for a domain name will cancel the DNSSEC security mechanism for the zone in question.
The Registrant tasks the Registrar with implementing the removal. The Registrar may only do this on behalf of the Registrant. Upon receipt of the removal request by the SRS, it takes no longer than until the next zone generation for the change to be recorded in the zone file. Hence, it takes up to two times the TTL plus the distribution time before the changes have been deployed. The whole procedure may take a maximum of five hours to complete.
There is no process to support faster removal of DS records in an emergency.
NZRS maintains two fully operational sites in New Zealand, located in Auckland and Wellington. Both contain a complete set of NZRS's critical systems, with updated information that's replicated automatically during normal operation.
The site located in Auckland is a purpose built state-of-the-art data centre and has the following security features:
The site located in Wellington is in a private server room operated by a Wellington IT Services company. It is not located at the NZRS office. The server room has the following security features:
Note: Rack security and rack access controls are currently being reviewed.
In addition to the above:
Security of key material at these sites is ensured by the following means:
Persons that are able to affect the zone file’s content, delivery of trust anchors or the generation or use of private keys, hold the following trusted roles:
The following trusted role is held by persons that are allowed to be present for the generation of private keys:
All individuals who hold a trusted role are required to sign a confidentiality agreement and an agreement to acknowledge their responsibilities with NZRS. Before a person receives their credentials for system access, a valid form of identification must be presented.
The separation of duties is enforced by the access rules for each role. A Systems Administrator is not allowed to be a Key Security Officer and vice versa.
All witnesses are required to present a valid form of photo identification.
For the above tasks the Witness will be invited to attend.
None of the operations previously described may be carried out in the presence of unauthorized people.
All individuals with a KSO or KGA trusted role are permanent employees or directors of NZRS and have been subject to the background checks specified in Section 4.4.2.
All individuals with a SA or DSO trusted role are permanent employees of NZRS or outsourced partners and have been subject to the background checks specified in Section 4.4.2.
NZRS requires that personnel seeking to become Trusted Individuals present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities adequately.
For the trusted roles in Section 4.3.1, the following background checks are included:
Using this information, the NZRS CE would then decide on a case by case basis if the individual considered for a trusted role is suitable or not.
Outsourced partners, contractors and sub-contractors performing work on the NZRS account are required to:
Every person with a trusted role in the Key Generation procedure must be trained in the Key Generation procedure and have taken part in the procedure training.
NZRS takes all care to ensure that no person outside the Trusted Roles specified in Section 4.3.1 can get access to the signer or signing material such as backups.
NZRS supplies the necessary documentation to each employee to perform their work task in a secure and satisfactory manner.
Logging is automatically carried out and involves the continuous collection of information regarding the activities that take place in an IT system. This logged information is used in the monitoring of operations, for statistical purposes and for investigation purposes in suspected cases of violation of .nz's policies and regulations.
Logging information also includes the journals, checklists and other paper documents that are vital to security and that are required for auditing.
The following events are included in logging:
Logs are systematically analyzed through automated and manual processes. Regular controls are applied, specifically around key generation, login attempts and detected anomalies.
Log information is stored in log servers for 4 months. Afterwards, the log information is archived for at least 2 years.
Log files are backed up into tape, and later transferred to a secure location. Paper logs are protected by copying and storing them in a secure fire-proof location.
Daily internal and external scans are performed using a third party vulnerability assessment tool.
In addition to the daily checks mention above on the logs, every two months the events registered in the logs are processed and analyzed to monitor for potential system vulnerabilities.
For the purpose of this document an incident is any event that caused or could have caused an outage, disruption, information corruption or security breaches.
All incidents are handled in accordance with NZRS's Security Incident Detection and Response Manual. This document indicates the cause of the incident has to be investigated, identify the effects, measures to prevent the recurrence of the event and channels and mechanism to report this information.
The NZRS core systems are designed with a multi-layer approach to security. NZRS use a number of specific incident prevention methods:
NZRS have also implemented a range of general security practices that will help ensure that appropriate measures are taken to maintain business continuity, prevent, minimize the risk, and minimize the impact of security breaches.
In the event of corruption, the procedures detailed in the Business Continuity Management Manual shall be followed.
NZRS has a contingency plan that ensures the operation of critical production systems can be relocated between the two operation facilities within minutes. The facilities are equivalent in terms of physical and logistical protection. Information is replicated between the facilities.
The contingency plan and routines are regularly tested. The completed tests and trials are recorded and subsequently evaluated.
The contingency plan includes:
If NZRS must discontinue DNSSEC for the .nz zone for any reason and return to an unsigned position, this will take place in an orderly manner in which the general public will be informed. If operations are to be transferred to another party, NZRS will participate in the transition to make it as smooth as possible.
Key generation takes place in a hardware security module (HSM) that is managed by trained personnel in trusted roles.
Key generation takes place when the initial signing setup is being prepared and during the execution of the Key Generation Procedure. One SA, and two KSO working coordinately and present during the entire operation must perform these processes.
The entire key generation procedure is logged, part of which is done electronically and part of which is done manually on paper by the KGA. Both components of the execution log will be published afterwards according to Section 2.2.
The public component of each generated KSK is exported from the signing system using a PGP-signed message and verified by the KSO and SA. The KSO is responsible for publishing the public component of the KSK in a secure manner as per Section 2.2. The SA is responsible for ensuring that the keys that are published are the same as those that were generated, by comparing a cryptographic hash.
Key parameters are regulated by .NZ's KASP (Key and Signature Policy) and quality control includes checking the key length.
Keys generated for DNSSEC are not used for any other purpose or outside the signing system. The maximum validity period for a signature created by a DNSSEC key is 16 days, and this validity period always begins when the signature has been established. Signatures are recalculated 3 days before their expiration.
All cryptographic functions involving the private component of the ZSK and KSK are to be performed within the HSM; that is, the private component cannot be exported from the HSM except in encrypted form for purposes of key backup.
The system uses a hardware security module (HSM) which conforms to the requirements in FIPS 140-2 Level 3.
During the HSM activation, all Keystore Security Officers and Device Security Officers need to be present to be enrolled as such and activate the HSM. One System Administrator is required to get logical access. Multi-person control will be applied during the creation of a key backup and restoration.
Private components of .nz Zone and Key Signing Keys are not escrowed.
NZRS creates backup copies of .nz ZSK and KSK private keys for routine recovery and disaster recovery purposes. One copy will be held on each production site, plus a copy in an off site location. All backup copies are encrypted.
Keys are stored in an encrypted format on the signing module's hard drive. The encrypted key archive is securely backed up and synchronized between the operations facilities shortly after key generation.
Private keys held on hardware cryptographic modules are stored in encrypted form.
ZSK key pairs do not expire. Superseded key pairs will be securely retained for a period of at least 7 days using hardware security modules that meet the requirements of this DPS. These key pairs will not be used for any signing events after their supersession.
For Disaster Recovery Policy, the private keys are copied from one facility to the other in encrypted form. The key export and import process must be executed by one at least one System Administrator and at least two Keystore Security Officers working coordinately.
After their useful life, keys are removed from the signing system. Where required, NZRS destroys the keys utilizing the zeroize function of its HSM.
Public keys are archived in accordance with the archiving of other information relevant to traceability in the system, such as log data.
Keys become invalid as they are taken out of production. Old keys are not reused.
Private keys are put in production during the Key Generation Procedure, requiring the presence of at least one System Administrator and two Keystore Security Officers to proceed.
In the event of a crisis situation, there is a sealed envelope in a secure location that contains activation information as part of a Disaster Recovery Kit. NZRS contingency plan procedures indicate the conditions in which this shall be applied.
All critical components of NZRS's systems are placed in the organizations secure facilities in accordance with NZRS Security Policy and Procedures. Access to the server's operating systems is limited to individuals that require this for their work, such as system administrators and operators.
NZRS has logically separated networks that are divided into various security zones with secured communications in-between. Logging is conducted in the firewalls. All sensitive information that is transferred over the communication networks is always protected by strong encryption.
NZRS retrieves time from trusted Stratum 1 NTP timeservers. Time stamps are conducted using UTC and are standardized for all log information and validity time for signatures.
All applications are developed and implemented by NZRS in compliance with NZRS Change Policy.
NZRS has mechanisms to control and monitor the configuration of its systems and to validate the software packages installed preserve their integrity.
The signing process is conducted automatically each hour on the hour. If no changes are produced between hours, the previous zone is preserved and only the signatures close to expiration will be regenerated.
Key pairs are required to be of sufficient length to prevent others from determining the key pair's private key using cryptanalysis during the period of expected utilization of such key pairs.
The current KSK key pair(s) is an RSA key pair, with a modulus size of 2048 bits.
Signatures are generated using RSA operation over a cryptographic hash function using SHA-256 (RSA/SHA-256, RFC 5702).
ZSK rollover is carried out every 3 months in a semi-automated procedure.
Each KSK will be scheduled to be rolled over through a key ceremony each year, and extraordinarily when needed as described in Section 4.6.3.
RRsets are signed with the ZSKs with a validity period of 12 to 16 days. Resigning takes place every hour, but only signatures close to expiration will be regenerated. Signatures are recalculated when their expiration date is less than 3 days in the future.
Security controls are conducted on the DNSKEY records before publishing to ensure correct signatures and validity periods. This is done by verifying the chain from DS in the parent zone to KSK, ZSK and the signature over the .nz SOA.
NZRS verifies that all resource records are valid according to the current standards prior to distribution.
NZRS annually engages external auditors to check on compliance with the security policy and procedures. The annual security audit work item is detailed in the NZRS Board Audit & Risk Committee annual work program and the terms of reference for each audit are signed off by the committee.
Additional audits may be required at any time under the following circumstances:
The auditor must be able to demonstrate proficiency with IT security tools, security auditing, DNS and DNSSEC.
An external auditor will be appointed for the audit. When necessary the auditor shall be able to recruit specific expert knowledge. The auditor is responsible during the entire auditing process.
The scope of the audit will always include the following DNSSEC components:
The following items have been performed in previous audits and will continue to be included on a regular basis with future audits:
If any anomaly or deficiency is detected, the auditor shall immediately notify NZRS verbally. NZRS Management then will determine the course of action to prepare and execute a corrective action plan.
The auditor shall provide a written report of the audit results to NZRS not later than 30 days after the audit.