Chapter 12. Serving authoritative DNSSEC data

Table of Contents

1. A brief introduction to DNSSEC
2. Profile, Supported Algorithms, Record Types & Modes of operation
2.1. DNSSEC: live-signed vs orthodox 'pre-signed' mode
3. Migration
3.1. From an existing PowerDNS installation
3.2. From existing non-DNSSEC non-PowerDNS setups
3.3. From existing DNSSEC non-PowerDNS setups, pre-signed
3.4. From existing DNSSEC non-PowerDNS setups, live signing
4. Records, Keys, signatures, hashes within PowerDNSSEC in online signing mode
4.1. (Hashed) Denial of Existence
4.2. Signatures
5. 'pdnssec' for PowerDNSSEC command & control
6. DNSSEC advice & precautions
6.1. Packet sizes, fragments, TCP/IP service
7. Operational instructions
7.1. Publishing a DS
7.2. ZSK rollover
7.3. KSK rollover
7.4. Going insecure
7.5. NSEC(3) change
8. Modes of operation
8.1. PowerDNSSEC Pre-signed records
8.2. PowerDNSSEC Front-signing
8.3. PowerDNSSEC BIND-mode operation
8.4. PowerDNSSEC hybrid BIND-mode operation
8.5. Rules for filling out fields in database backends
9. PKCS#11 support
10. Secure transfers
11. Security
12. Performance
13. Thanks to, acknowledgements

(only available in PowerDNS 3.0 and beyond, not yet available in the PowerDNS Recursor)

PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data, with minimal administrative overhead.

In PowerDNSSEC, DNS and signatures and keys are (usually) treated as separate entities. The domain & record storage is thus almost completely devoid of DNSSEC record types.

Instead, keying material is stored separately, allowing operators to focus on the already complicated task of keeping DNS data correct. In practice, DNSSEC related material is often stored within the same database, but within separate tables.

If a DNSSEC configuration is found for a domain, the PowerDNS daemon will provide keys, signatures and (hashed) denials of existence automatically.

As an example, securing an existing zone can be as simple as:

$ pdnssec secure-zone
$ pdnssec rectify-zone

Alternatively, PowerDNS can serve pre-signed zones, without knowledge of private keys.

1. A brief introduction to DNSSEC

DNSSEC is a complicated subject, but it is not required to know all the ins and outs of this protocol to be able to use PowerDNSSEC. In this section, we explain the core concepts that are needed to operate a PowerDNSSEC installation.

Zone material is enhanced with signatures using 'keys'. Such a signature (called an RRSIG) is a cryptographic guarantee that the data served is the original data. DNSSEC keys are asymmetric (RSA, DSA or GOST), the public part is published over DNS and is called a DNSKEY record, and is used for verification. The private part is used for signing and is never published.

To make sure that the internet knows that the key that is used for signing is the authentic key, confirmation can be gotten from the parent zone. This means that to become operational, a zone operator will have to publish a representation of the signing key to the parent zone, often a ccTLD or a gTLD. This representation is called a DS record, and is a shorter (hashed) version of the DNSKEY.

Once the parent zone has the DS, and the zone is signed with the DNSSEC key, we are done in theory.

However, for a variety of reasons, most DNSSEC operations run with another layer of keys. The so called 'Key Signing Key' is sent to the parent zone, and this Key Signing Key is used to sign a new set of keys called the Zone Signing Keys.

This setup allows us to change our keys without having to tell the zone operator about it.

A final challenge is how to DNSSEC sign the answer 'no such domain'. In the language of DNS, the way to say 'there is no such domain' (NXDOMAIN) or there is no such record type is to send an empty answer. Such empty answers are universal, and can't be signed.

In DNSSEC parlance we therefore sign a record that says 'there are no domains between and'. This securely tells the world that does not exist. This solution is called NSEC, and is simple but has downsides - it also tells the world exactly which records DO exist.

So alternatively, we can say that if a certain mathematical operation (an 'iterated salted hash') is performed on a question, that no valid answers exist that have as outcome of this operation an answer between two very large numbers. This leads to the same 'proof of non-existence'. This solution is called NSEC3.

A PowerDNSSEC zone can either be operated in NSEC or in one of two NSEC3 modes ('inclusive' and 'narrow').