DNSSEC

DNSSEC is a set of DNS security extensions that add digital signatures to the data that we publish and a mechanism for finding and verifying the keys used to verify these signatures. We have been extensively involved in the development of DNSSEC standards and tools and the signing of the root nameservers. DNSSEC has been fully deployed for all our zones since late 2012.

DNSSEC Practice Statement

The InternetNZ DNSSEC Practice Statement (DPS) 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. The latest version of the DPS can be found here.

DNSSEC High Level Architecture

Overview

This section describes the architecture used to implement the DNS Security Extensions (DNSSEC) in the New Zealand top-level domain (.nz) and second level domains under .nz.

This architecture was designed following one main concept: the signing process will operate as a bump of the wire or black box, which receives unsigned zones and outputs signed zones. This approach allows an easier deployment, extensibility by the addition of extra signing boxes in case of need, and easy replacement with an equivalent solution.

Components

SRS Cluster: Set of servers providing the SRS service (registration data storage and handling).

DNS Primaries: Servers that build the zone data for the DNS from the registration data, and distribute it to the DNS Slaves.

DNS Secondaries: Set of servers answering DNS queries to the public using the authoritative data published by the primaries.

Signing box: Server that receives the unsigned zone file and generates a signed zone. Contains the HSM.

Key generator: Server where the key generation process is carried out.

HSM (Hardware Security Module): Device designed to protect the private component of cryptographic keys. Also operates as a Crypto Accelerator, speeding up crypto-operations such as data signing.

Online channel: Data is transferred through an unsecured public IP network.

Secure Offline channel: Data is transferred in encrypted form using a secure media that’s physically transported from place to place.

Secure online channel: Data is transferred using encrypted packets through an unsecured IP network.

Deployment

For redundancy purposes, there are two independent operational sites in different locations, each containing one SRS Cluster, one DNS Primary, and one Signing Box. There are several DNS Secondaries dispersed across the world.

The system is designed in a way that, if a component on one site fails, the equivalent on the other site can take its role.

Integration

The SRS Cluster sends the SRS data to the primaries in a plain text format through secure online channels.

The primaries communicate with the signing box using the standard zone transfer mechanism defined by the DNS (RFC 1995, 1996 and 5936), authenticated using TSIG (RFC 2845).

The signing box interacts with the HSM using the PKCS#11 API.

The signing box interacts back with the primary using the standard zone transfer mechanism defined by the DNS (RFC 1995, 1996 and 5936), authenticated using TSIG (RFC 2845). In a similar way the Primary interacts with the Slaves.

Scenarios

There are three main operation scenarios.

1. Signing Box Initialization

This procedure is carried out before putting a signing box in production, or within the recovery phase after a major disaster. No zone signing is carried out during this stage.

2. Key generation

This procedure generates keys to be used for zone signing during a certain period. For more information see the Key Generation Procedure section below.

3. Zone Signing

This is the more frequent operation scenario. At regular intervals, the SRS cluster produces a summary of the active domain names registered on the system. Then push the summary as a file into the primaries, which build new zone files. The zone files are loaded, generating notifications for the signing boxes of the existence of a new unsigned version of the production zones. The signing boxes fetch the zones, sign them using the corresponding allocated keys, and notify back the primaries. Then the primaries copy the signed zone over and notify the slaves, which will copy over the zone and serve it to the public.

Key Generation Procedure

Once a year the cryptographic keys used in the DNSSEC implementation for .nz for the next 12 months are created. As per our policy the procedure used follows a defined script which details the materials used, the participants, the time tracking and the technical steps taken to protect the key material. The console output is also captured as a text file.

During this stage, the zone signing is stopped. The system generates keys to be used for zone signing during a certain period. After the key generation finishes, various copies of the encrypted backups are created. One copy is transferred to the other signing box to import the new keys into the backup HSM. The rest of the copies are distributed as on-site and off-site backup copies for disaster recovery purposes. The copies are created using the HSM utilities for that purpose and stored in secure media.

The materials created during the procedure are available below:

For information related to previous keys, please check our document library.