On this page:

1. Introduction

• 1.1 Document Name and Identification
• 1.2 Community
• 1.3 Applicability
• 1.4 Document Management

2. Publication and Repositories

• 2.1 Official publication site
• 2.2 Publication of key signing keys

3. Operational Requirements

• 3.1 Activation of DNSSEC for child zone
• 3.2 Registration of delegation signer (DS) records
• 3.3 Method to prove possession of private key
• 3.4 Removal of DS record

4. Management, Operational and Physical Controls

• 4.1 Site Controls
• 4.2 Key Material Controls
• 4.3 Procedural Controls
• 4.4 Personnel Controls
• 4.5 Audit Logging Procedures
• 4.6 Compromise and Disaster Recovery
• 4.7 Entity Termination

5. Technical Security Controls

• 5.1 Key Pair Generation and Installation
• 5.2 Private key protection and Cryptographic Module Engineering Controls
• 5.3 Other Aspects of Key Pair Management
• 5.4 Activation data
• 5.5 Computer Security Controls
• 5.6 Network Security Controls
• 5.7 Time stamping
• 5.8 Life Cycle Technical Controls

6. Zone Signing

• 6.1 Key lengths and algorithms
• 6.2 Authenticated denial of existence
• 6.3 Signature format
• 6.4 Zone signing key roll-over
• 6.5 Key signing key roll-over
• 6.6 Signature life-time and resigning frequency
• 6.7 Verification of zone signing key set
• 6.8 Resource records time-to-live

7. Compliance Audit

• 7.1 Frequency of entity compliance audit
• 7.2 Identity/qualifications of auditor
• 7.3 Auditor’s relationship to audited party
• 7.4 Audit scope
• 7.5 Actions taken as a result of deficiency
• 7.6 Communication of results

1. Introduction

This document is the Government Registrar DNSSEC (DNS Security Extensions) Practice Statement (DPS). It defines the operational procedures for the management of DNSSEC in .govt.nz, .parliament.nz, and subordinate third level domains (3LDs).

This document draws on the Internet Engineering Task Force (IETF) RFC 6841 for DNSSEC Practice Statement construction, but has a number of significant differences to keep the Government Registrar DPS appropriate for .govt.nz and .parliament.nz 3LDs, and aligned with the .nz Registry Services (NZRS) DPS for the .nz name space.

The Government DNS Platform includes the management of .govt.nz and .parliament.nz 3LDs as stored on the Government Registrar’s name servers.

1.1 Document Name and Identification

Document title: DNSSEC Practice Statement

Version: 1.0

Last Update: 9 November 2015

1.2 Community

The following roles and delegation of liability with regard to DNSSEC have been identified:

• Registry: NZRS is the Registry, managing and operating the domain name register under the .nz name space.
• Zone Administrator: The Government Registrar is the Zone Administrator for third-level .govt.nz and .parliament.nz zones and so responsible for generating key pairs and protecting the confidentiality of the private component of the Key Signing Keys and Zone Signing Keys. The Government Registrar is responsible for the secure export and publication of trust anchors (TA) and the registration and maintenance of DS resource records in the .govt.nz and .parliament.nz zones. The Government Registrar employs an authorised external organisation as an additional Zone Administrator for third-level .govt.nz and .parliament.nz zones.
• Registrar: The authorised registrar for the .govt.nz and .parliament.nz name spaces is the Government Registrar, a function maintained by the Department of Internal Affairs (DIA). The Registrar is responsible for securely identifying the Registrant of a .govt.nz or .parliament.nz domain, among other responsibilities detailed in .nz Operations and Procedures and .nz Principle and Responsibilities. The Registrar is responsible for generating and protecting each .govt.nz and .parliament.nz domain’s keys, registering and maintaining the DS records for each domain, and issuing emergency key rollovers if keys are suspected of being compromised or have been lost.
• Moderators: DIA and the Association of Local Government Information Management (ALGIM) jointly serve as moderator for .govt.nz domain names. The Parliamentary Service serves as moderator for .parliament.nz domain names. The Moderators are responsible for the membership of 3LDs under the moderated domain, and for ensuring that registrants meet the specific additional criteria for registering a domain. Additional moderator responsibilities apply as detailed in the relevant .govt.nz moderation policy or .parliament.nz moderation policy
• Registrant: The Registrant is the eligible government organisation that has been granted the right to use a specific .govt.nz or .parliament.nz domain name.
• Relying Party: The Relying party is the entity relying on DNSSEC such as validating resolvers and other applications. The Relying party is responsible for configuring and updating the appropriate Trust Anchors. The Relying party must also stay informed of any relevant DNSSEC-related events in the .nz domain.

1.3 Applicability

The Registrar is responsible for determining the relevant level of security for each domain. This DPS is exclusively applicable to third-level domains under the .govt.nz and .parliament.nz domains and describes the procedures and security controls applicable when managing and employing keys and signatures for the signing of the third-level .govt.nz and .parliament.nz zones.

With the support of this DPS, the Relying party can determine the level of trust it may assign to DNSSEC in the .govt.nz and .parliament.nz domains and assess its own risk.

1.4 Document Management

The Government Registrar is responsible for keeping this document updated. For updated contact details, please refer to dns.govt.nz

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 dns.govt.nz

All new versions will be announced using the communication channels detailed in Section 2.1. Major revisions will also be announced to Registrants, and any other groups that express an interest in receiving such notifications.

Only the most recent version of this DPS is applicable.

2. Publication and Repositories

2.1 Official publication site

The Government Registrar publishes DNSSEC-relevant information on the Government Registrar website at dns.govt.nz

Notifications relevant to DNSSEC in .govt.nz and .parliament.nz 3LDs will be distributed by email to Registrants, and any other community-accepted forum.

2.2 Publication of key signing keys

NZRS, with authorisation from The Government Registrar, will publish KSKs in the form of DS records for govt.nz and .parliament.nz directly in the .nz zone when available, and for .govt.nz and .parliament.nz 3LDs directly in the .govt.nz and .parliament.nz zones, respectively, when available.

No other trust anchors or repositories are used.

3. Operational Requirements

3.1 Activation of DNSSEC for child zone

DNSSEC for a child zone is activated by publishing a signed DS record for that zone. The Registrar will automatically activate DNSSEC for each .govt.nz and .parliament.nz 3LD that uses the Registrar’s name servers.

3.2 Registration of delegation signer (DS) records

Through the Government DNS Platform, Registrants who wish to operate their own DNS and DNSSEC infrastructure may supply DS records for inclusion into the .nz registry. DS records need to be supplied in RFC5910 format, and up to 10 DS records per .govt.nz and .parliament.nz 3LD zone may be supplied for inclusion into the .nz registry.

Registrants using the Government DNS platform to host and manage their DNS zone data do not need to manage DS records. Controls are documented further in this document and scripts for system operation are provided within the DNSSEC Operating Procedures Manual.

3.3 Method to prove possession of private key

The Government Registrar is holder of the private key for the Government DNS Platform and is responsible for its protection and authentication.

Any Registrar not using the Government DNS Platform is responsible for conducting the appropriate controls required and those considered necessary.

3.4 Removal of DS record

The Government Registrar has the authority to remove DS records at their discretion. There is no process to support faster removal of DS records in an emergency.

4. Management, Operational and Physical Controls

4.1 Site Controls

The Government Registrar maintains two fully operational sites in New Zealand, located in Auckland and Wellington. Both contain a complete set of the Government Registrar’s critical systems, with updated information that’s replicated automatically during normal operation.

The Government Registrar maintains a third site off shore, located in Sydney, Australia. This site contains a set of the Government Registrar’s name servers, with updated information that’s replicated during normal operation.

The sites located in Auckland and Wellington are purpose built state-of-the-art data centres and have the following security features:

• 24/7 security presence on site;
• Concentric security levels limiting individuals’ access to specific security zones;
• All visitors to the facility are required to have requested prior approval in advance of arrival at the site;
• On arrival visitors are required to present proof of identity before being allowed to enter the facility;
• Once inside the facility, all visitors are escorted at all times;
• All racks are locked;
• Surveillance cameras operate within the data centre;
• All power supplied within the data centre is backed by both multiple UPS systems and regularly tested on-site generators capable of powering all services on the site in the event of power supply failure.

4.2 Key Material Controls

Security of key material at these sites is ensured by the following means:

• DNSSEC key material is stored in a FIPS 140-2 Level 4 compliant HSM.
• All key related operations require the use of the HSM.
• Access to the private component of the keys is only possible as part of a backup. Exporting of keys in plain text is not possible.
• Media and other materials containing sensitive information are destroyed in a secure manner, by shredding in the case of documents or rendering unreadable in the case of media.
• Backups of key material are stored encrypted on removable media, stored inside a safe in a secure location in secured bag, which is sealed during the Key Generation procedure. Integrity of backups is verified by checking the backup files’ cryptographic hash prior to every Key Generation procedure.
• Backup and restoration of key material can only be initiated with the presence of two HSM Crypto Officers and one System Administrator. Access to the backup media is restricted to the Government Registrar personnel in trusted roles only as specified in Section 4.3.1. The backup storage facility is administratively separated from the Government Registrar facilities.
• A stolen key cannot be accessed, restored or used without the presence of two HSM Crypto Officers and an HSM.

4.3 Procedural Controls

4.3.1 Trusted roles

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:

• System Administrator (SA)
  • Has full administration rights to the signing servers
  • Can access to the facility without escort
  • Cannot access nor generate DNSSEC signing keys in HSM keystore
  • Cannot enable HSM interface to signing servers
  • Cannot initialise HSM, nor create/modify HSM Smartcards
  • Cannot access HSM Smartcards
  • The minimum number of SAs appointed will be 2 and the maximum will be 8
• HSM Operator (HO)
  • In conjunction with another HO, can enable HSM interface to signing servers
  • Can access their own HSM Operator Smartcards
  • Can access to the facility without escort
  • Cannot access nor generate DNSSEC signing keys in HSM keystore
  • Cannot initialise HSM, or create/modify HSM Smartcards
  • Cannot backup or restore HSM keystore
  • Does not have access to the signing servers
  • The minimum number of HOs appointed will be 2 and the maximum will be 9
• HSM Crypto Officer (HCO)
  • In conjunction with another HCO, can generate DNSSEC signing keys in HSM keystore
  • In conjunction with another HCO, can backup or restore HSM keystore
  • Cannot access facility – except when escorted by the KGA
  • Cannot access HSM Crypto Officer Smartcards – must obtain their Smartcard from the Safe Access Officer
  • Does not have access to the signing servers
  • The minimum number of HSOs appointed will be 2 and the maximum will be 12
• HSM Security Officer (HSO)
  • In conjunction with another HSO, can initialise the HSM
  • In conjunction with another HSO, can create or modify HSM Smartcards
  • Cannot access facility – except when escorted by the KGA
  • Cannot access HSM Security Officer Smartcards – must obtain their Smartcard from the Safe Access Officer
  • Does not have access to the signing servers
  • The minimum number of HSOs appointed will be 2 and the maximum will be 9
• Key Generation Administrator (KGA)
  • Verifies the Key Generation procedure is executed according to the script and produces the execution log
  • Has access to HSM Smartcard PINs for HSM Crypto and HSM Security Officers
  • Cannot access facility – except when escorted by SA or HO
  • Does not have access to HSM
  • Does not have access to the signing servers
  • The minimum number of KGAs appointed will be 2 and the maximum will be 8
• Equipment Officer (EO)
  • Supervises the secure use of all equipment during Key Generation procedures.
  • Has access to the HSM Smartcards for HSM Crypto and HSM Security Officers
  • Cannot access facility – except when escorted by the KGA
  • Does not have access to HSM
  • Does not have access to the signing servers
  • The minimum number of SAOs appointed will be 2 and the maximum will be 12

All individuals who hold a trusted role are required to sign a confidentiality agreement and an agreement to acknowledge their responsibilities with the Government Registrar. 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, with the exception that System Administrators may also hold the HSM Operator role, provided that they do not act in both roles for any one operation or process.

4.3.2 Other roles

• Witness (WI)
  • May be present
  • Does not have access to the keys
  • Does not have physical access or logical access to the operational facilities

All witnesses are required to present a valid form of photo identification.

4.3.3 Number of persons required per task

• HSM initialisation, creation or modification of HSM Smartcards
  • ALL HSM Security Officers (HSO)
  • ALL HSM Crypto Officers (HCO)
  • ALL HSM Operators (HO)
  • One Key Generation Administrator (KGA)
  • One Equipment Officer (EO)
• Key generation
  • One System Administrator (SA) and
  • Two HSM Crypto Officers (HCO) and
  • Two HSM Officers (HO) and
  • One Key Generation Administrator (KGA)
  • One Equipment Officer (EO)
• Backup or restore of HSM keystores requires:
  • Two HSM Crypto Officers (HCO) and
  • Two HSM Officers (HO) and
  • One Key Generation Administrator (KGA)
  • One Equipment Officer (EO)
• Enabling HSM interface to signing servers
  • One System Administrator (SA) and
  • Two HSM Operators (HO)

None of the operations previously described may be carried out in the presence of unauthorised people.

4.3.4 Trusted individuals

All individuals with an HSO, HCO, KGA or EO trusted role are permanent employees of the New Zealand Government and have been subject to the background checks specified in Section 4.4.2.

All individuals with a SA or HO trusted role are permanent employees of the New Zealand Government or outsourced partners and have been subject to the background checks specified in Section 4.4.2.

4.4 Personnel Controls

4.4.1 Qualifications, experience, and clearance requirements

The Government Registrar 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.

4.4.2 Background check procedures

For the trusted roles in Section 4.3.1 and outsourced partners performing work on the Government Registrar DNSSEC implementation, the following background checks are included:

• Candidate resume
• Previous employments
• Reference check
• Criminal convictions check

Using this information, the Government Registrar would then decide on a case by case basis if the individual considered for a trusted role is suitable or not.

4.4.3 Training requirements

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.

4.4.4 Contracting personnel requirements

The Government Registrar 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.

4.4.5 Documentation supplied to personnel

The Government Registrar supplies the necessary documentation to each employee to perform their work task in a secure and satisfactory manner.

4.5 Audit Logging Procedures

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 the policies and regulations applicable to the Government Registrar and its operations.

Logging information also includes the journals, checklists and other paper documents that are vital to security and that are required for auditing.

4.5.1 Types of events recorded

The following events are included in logging:

• All Key Generation Procedures will be logged in electronic and handwritten logbook and copies will be stored in a safe location.
• All types of activities involving HSM, such as key generation and activation, key removal, exporting and restoration.
• Successful and unsuccessful remote access attempts
• The processing of security-sensitive information
• Entry to a facility

4.5.2 Frequency of processing log

Logs are systematically analysed through automated and manual processes. Regular controls are applied, specifically around key generation, login attempts and detected anomalies.

4.5.3 Retention period for audit log information

Log information is stored in log servers for six months. Afterwards, the log information is archived for at least six months.

4.5.4 Protection of audit log

Log files are backed up onto disk, and replicated to disks stored in a secure location. Paper logs are protected by scanning, storing them in a secure EDRMS location, and securely shredding the original paper copies.

4.5.5 Vulnerability assessments

Annual vulnerability assessment will be performed by a third party assessor appointed by the Government Registrar.

4.6 Compromise and Disaster Recovery

4.6.1 Incident Detection and compromise handling procedures

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 the Government Registrar’s Security Incident 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 Government DNS Platform is designed with a multi-layer approach to security and employs a number of specific incident prevention or detection methods:

• Web Application Firewall (WAF)

The Government Registrar has also implemented a range of general security practices that will help ensure that appropriate measures are taken to maintain business continuity, prevent, minimise the risk, and minimise the impact of security breaches.

Some of the security measures implemented by the Government Registrar include:

• Security Risk Management Plan
• Incident Response Plan
• Business Continuity Plan
• Disaster Recovery Plan
• Cyber Security Policy
• System Security Plan
• Backup Operations Systems Support and Activation Plans
• Patch Management
• Risk Management
• Security Policy
• Security Procedures
• Firewalls, secure configurations, passwords etc
• Monitoring of Security Advisories
• Scan external hosts for vulnerabilities
• Server hardening – disable services that are not required etc
• Comparison and reporting of changes/differences to configuration files
• Quality Assurance procedures

4.6.2 Corrupted computing resources, software, or information

In the event of corruption, the procedures detailed in the Business Continuity Plan shall be followed.

4.6.3 Procedures in the event of suspicion of a compromised or incorrectly used private key.

Suspicion that a private key has been compromised or misused leads to a controlled key rollover as follows:

• If a ZSK is suspected of having been compromised, it will immediately be removed from production and stopped being used. If necessary, a new ZSK will be generated and the old key will be removed from the key set as soon as its signatures have expired or timed out. If a ZSK is suspected of having been compromised or revealed to unauthorised parties, this will be notified through the communication channels indicated in the Incident Management Plan.
• If a KSK is suspected of having been compromised, a new key will be generated and put into immediate use, in parallel with the old key. The old KSK will remain in place and be used to sign key sets until such time as it can be considered sufficiently safe to remove the key taking into account the risk for system disruption in relation to the risk that the compromised key presents. A KSK rollover in progress is always notified through the channels indicated in Incident Management Plan.
• If a KSK is lost, a new key will be generated and a key exchange will take place without an overlap between the lost and the new KSK. At such time, that will be announced through the channels indicated in Incident Management Plan. During the time until the rollover, the key set will remain static and any scheduled ZSK rollover will be postponed until after the KSK exchange.

4.6.4 Business Continuity and IT Disaster Recovery Capabilities

The Government DNS Platform has a contingency plan that ensures the operation of critical production systems can be relocated between the two operation facilities within a few hours. 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:

• Who decides on the activation of an emergency recovery procedure
• How and where the crisis management shall convene
• Activation of backup operations
• Criteria for restoring normal operations

4.7 Entity Termination

If the Government Registrar must discontinue DNSSEC for the .govt.nz and. parliament.nz 3LD zones for any reason and return to an unsigned position, this will take place in an orderly manner in which the Registrants will be informed. If operations are to be transferred to another party, the Government Registrar will participate in the transition to make it as smooth as possible.

5. Technical Security Controls

5.1 Key Pair Generation and Installation

5.1.1 Key pair generation

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, two HO, and two HCO working co-ordinately 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 available on request to Registrants.

5.1.2 Public key distribution

DS records are automatically published to the .nz registry using the NZRS XML API, secured via PGP signatures and privacy provided via TLS.

5.1.3 Public key parameters generation and quality checking

Key parameters are regulated by the Government DNS Platform KASP (Key and Signature Policy) and quality control includes checking the key length.

5.1.4 Key usage purposes

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 15 days, and this validity period always begins when the signature has been established. Signatures are recalculated 3 days before their expiration.

5.2 Private key protection and Cryptographic Module Engineering Controls

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.

5.2.1 Cryptographic module standards and controls

The system uses a hardware security module (HSM) which conforms to the requirements in FIPS 140-2 Level 4.

5.2.2 Private key (m-of-n) multi-person control

During the HSM activation, all HSM Security Officers, HSM Crypto Officers and HSM Operators need to be present to be enrolled as such. One System Administrator is required to get logical access. Multi-person control will be applied during the creation of a key backup and restoration.

5.2.3 Private key escrow

Private components of the Government DNS Platform Zone and Key Signing Keys are not escrowed.

5.2.4 Private key backup

The Government Registrar creates backup copies of .govt.nz and .parliament.nz ZSK and KSK private keys for routine recovery and disaster recovery purposes. Three copies will be held in an off site location within the city of each production site location. All backup copies are encrypted.

Keys are stored in an encrypted format in the signing module’s internal storage. The encrypted key archive is securely backed up and synchronised between the operations facilities shortly after key generation.

5.2.5 Private key storage on cryptographic module

Private keys held on hardware cryptographic modules are stored in encrypted form.

5.2.6 Private key archival

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.

5.2.7 Private key transfer into or from a cryptographic module

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 at least one System Administrator, two HSM Operators, and two HSM Crypto Officers working co-ordinately.

5.2.8 Method of destroying private key

After their useful life, keys are removed from the signing system. Where required, Government DNS Platform administrators destroy the keys utilising the zeroise function of its HSM.

5.3 Other Aspects of Key Pair Management

5.3.1 Public key archival

Public keys are archived in accordance with the archiving of other information relevant to traceability in the system, such as log data.

5.3.2 Key usage periods

Keys become invalid as they are taken out of production. Old keys are not reused.

5.4 Activation data

Private keys are put in production during the Key Generation Procedure, requiring the presence of at least one System Administrator, two HSM Operators, and two HSM Crypto Officers to proceed.

5.4.1 Other aspects of activation data

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. The Government Registrar contingency plan procedures indicate the conditions in which this shall be applied.

5.5 Computer Security Controls

All critical components of the Government DNS Platform systems are placed in the organisations secure facilities in accordance with Government DNS Platform 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.

5.6 Network Security Controls

The Government DNS Platform 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.

5.7 Time stamping

The Government DNS Platform retrieves time from trusted Stratum 1 NTP timeservers. Time stamps are conducted using NZT.

5.8 Life Cycle Technical Controls

5.8.1 System development controls

All applications supporting the Government DNS Platform are developed in compliance with Government DNS Platform Operator Change Policy.

This includes mandatory use of version control system, regression testing, and isolated testing environment.

5.8.2 Security management controls

The Government DNS Platform Operator has mechanisms to control and monitor the configuration of its systems and to validate the software packages installed preserve their integrity.

6. Zone Signing

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.

6.1 Key lengths and algorithms

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 utilisation of such key pairs.

The current KSK key pair(s) is an RSA key pair, with a modulus size of 2048 bits.

The current ZSK key pair(s) is an RSA key pair, with a modulus size of 1024 bits.

6.2 Authenticated denial of existence

Authenticated denial of existence will be provided through the use of NSEC records as specified in RFC 4034 for the .nz zone, and NSEC3 records as specified in RFC 5155 for govt.nz, parliament.nz, all third-level zones and their subordinate hosted DNS records on the Government DNS Platform.

6.3 Signature format

Signatures are generated using RSA operation over a cryptographic hash function using SHA-256 (RSA/SHA-256, RFC 5702).

6.4 Zone signing key roll-over

ZSK rollover is carried out every 3 months in an automated procedure.

6.5 Key signing key roll-over

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.

6.6 Signature life-time and resigning frequency

RRsets are signed with the ZSKs with a validity period of 13 to 15 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.

6.7 Verification of zone signing key set

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.

6.8 Resource records time-to-live

RR type TTL
DNSKEY 1 hour
NSEC3 0 seconds
Delegation Signer (DS) Published by .nz servers – 24 hours
RRSIG Varies, depending on the RRset signed

7. Compliance Audit

7.1 Frequency of entity compliance audit

The Government Registrar annually engages external auditors to check on compliance with the security policy and procedures. The annual security audit work item is detailed in the Service Security roadmap.

Additional audits may be required at any time under the following circumstances:

Recurring anomalies
Newly discovered vulnerabilities
Major changes to management, organisation or processes
The Government Registrar requests reassurance with the security posture of the service

7.2 Identity/qualifications of auditor

The auditor must be able to demonstrate proficiency with IT security tools, security auditing, DNS and DNSSEC.

7.3 Auditor’s relationship to audited party

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.

7.4 Audit scope

The scope of the audit will always include the following DNSSEC components:

Key Management Operation
Infrastructure Controls
Signing Lifecycle
Practices Disclosure
The following items have been performed in previous audits and will continue to be included on a regular basis with future audits:

Internal security control evaluation
Penetration testing
Procedural compliance
Security culture evaluation
Application vulnerability assessment
Offsite backup procedures

7.5 Actions taken as a result of deficiency

If any anomaly or deficiency is detected, the auditor shall immediately notify the Government Registrar verbally. The Government Registrar will then determine the course of action to prepare and execute a corrective action plan.

7.6 Communication of results

The auditor shall provide a written report of the audit results to the Government Registrar not later than 30 days after the audit.