DNSSEC High Level Architecture
Overview
This document 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 is carried out with a frequency detailed by the DNSSEC Practice Statement. 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.
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.