In 2010, it was an easy decision to use a commercial DNSSEC signer to deploy DNSSEC on APNIC’s reverse zones. Because much of the signer’s management was automated, we only had to worry about updating the parent delegation signer (DS) record separately.

So, even though we had to consider the scheduled Key Signing Key (KSK) rollover, updating the parent DS record on time was never an issue, since it would not roll-off the old key unless the new DS record had been updated in the parent zone.

In 2019, RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) was released. The minimum recommended DNSKEY algorithm changed to RSASHA256, and there was a strong recommendation to use ECDSAP256SHA256 as it provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512.

RSASHA1 was APNIC’s DNSKEY algorithm for almost 10 years, so the need to upgrade was it was inevitable. When it was time to upgrade, algorithm rollover was supported and well documented.

Following the recommendations in RFC 8624, we decided to migrate APNIC’s existing DNSKEY algorithm from RSASHA1 to ECDSAP256SHA256. The whole process took about a week to complete, without breaking the DNSSEC chain of trust.

Once we’d migrated, it was great to see the new (short) signatures from our zones.

What else could we ask for?

This is an introductory howto to get DNSSEC running with BIND >=9.9 on Debian >=8 (jessie). We assume an "clean", freshly installed bind9 here.

This document provides introductory information on how DNSSEC works, how to configure BIND 9 to support some commonDNSSEC features, as well as some basic troubleshooting tips. The chapters are organized as such:

Chapter 1 covers the intended audience for this document, assumed background knowledge, and a basic introduction to
the topicof DNSSEC.
Chapter 2 covers various requirements that are needed before implementing DNSSEC, such as software
versions, hardwarecapacity, network requirements, and security changes.
Chapter 3 walks through setting up a validating resolver, more information on the validation process, as well as
examples ofusing tools to verify that the resolver is validating answers.
Chapter 4 walks through setting up a basic signed authoritative zone, explains the relationship with the parent zone,
and on-goingmaintenance tasks.
Chapter 5 provides some tips on how to analyze and diagnose DNSSEC-related problems.
Chapter 6 covers several topics, from key generation, key storage, key management, NSEC and NSEC3, to
disadvantages ofDNSSEC.
Chapter 7 provides several working examples of common solutions, with step-by-step details

This Open Source Guide is about DNS and (mostly) BIND 9.x on Linux (Fedora Core), BSD's (FreeBSD, OpenBSD and NetBSD) and Windows (Windows 7 and 10). It is meant for newbies, Rocket Scientist wannabees and anyone in between.

This Guide was born out of our first attempts a number of years ago at trying to install a much needed DNS service on an early Redhat Linux system. We completed the DNS 'rite of passage' and found it a pretty unedifying and pointless experience.

Health Warning: This is still a work-in-progress. If you find errors don't grumble - tell us. Look at our to do list and if you want to contribute something please do so.

<gratuitous publicity> The newly published book Pro DNS and BIND was largely based on this material but significantly extends it - including DNS security (including DNSSEC.bis), IPv6, DNS APIs and complete reference sections on named.conf and RR types. We are outrageously biased but think it is an essential addition to the DNS admin's library. </gratuitious publicity>

Ein Ansatz, den Schlüsselaustausch im PGP-System sicherer und für den Benutzer einfacher zu gestalten, ist der OPENPGPKEY-Draft der IETF. Mit der dort beschriebenen Methode kann der Besitzer einer E-Mailadresse den zur Adresse passenden (öffentlichen) PGP-Schlüssel im DNS veröffentlichen.