DNSSEC automation
The Swedish Internet Foundation
Box 92073
Stockholm
12007
SE
ulrich@wisser.se
https://www.internetstiftelsen.se
Salesforce
415 Mission Street, 3rd Floor
San Francisco
CA 94105
United States of America
shuque@gmail.com
Operations and Management Area
Domain Name System Operations (dnsop)
DNSSEC
Multi-Signer
This document describes an algorithm and a protocol to
automate DNSSEC Multi-Signer "Multi-Signer
DNSSEC Models" setup, operations and decomissioning.
Using Model 2 of the Multi-Signer specification, where each operator
has their own distinct KSK and ZSK sets (or CSK sets),
"Managing DS Records from the Parent via
CDS/CDNSKEY" and "Child-to-Parent
Synchronization in DNS" to accomplish this.
Introduction
describes the necessary steps and API for a
Multi-Signer DNSSEC configuration. In this document we will combine
with and
to define an automatable algorithm for
setting up, operating and decomissioning of a Multi-Signer
DNSSEC configuration.
One of the special cases of Multi-Signer DNSSEC is the secure
change of DNS operator. Using Multi-Signer Model 2 the secure change
of DNS operator can be accomplished.
Out-Of-Scope
In order for any Multi-Signer group to give consistent answers
across all nameservers, the data contents of the zone also have to
be synchronized (in addition to infrastructure records like NS,
DNSKEY, CDS etc). This content synchronization is out-of-scope
for this document (although there are a number of methods that
can be used, such as making the the same updates to each operator
using their respective APIs, using zone transfer in conjunction
with "inline signing" at each operator, etc.)
Notation
Short definitions of expressions used in this document
Signer
An entity signing a zone
Multi-Signer Group
A group of signers that sign the same zone
Controller
An entity controlling the multi-signer group. Used in
the decentralized model.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
.
Use Cases
Maintaining a Multi-Signer group
As described in a Multi-Signer DNSSEC
configuration has some challenges that can be overcome with the
right infrastructure and following a number of steps for setup
and operation.
In this document we describe, except for the initial trust, how
the steps in the Multi-Signer DNSSEC setup can be automated.
Secure Nameserver Operator Transition
Changing the nameserver operator of a DNSSEC signed zone can be
challenging. Currently the most common method is temporarily
"going insecure". This is poor for security, and for users
relying on the security of the zone. Furthermore, when DNSSEC
is being used for application security functions like DANE
, it is critical that the DNSSEC chain
of trust remain unbroken during the transfer.
Multi-Signer DNSSEC Model 2 provides a mechanism for transitioning
from one nameserver operator to another without "going insecure".
A new operator joins the current operator in a temporary
Multi-Signer group. Once that is accomplished and stable the old
operator leaves the Multi-Signer group completing the transition.
Automation Models
Automation of the necessary steps
can be categorized into two main models, centralized and decentralized.
Both have pros and cons, and a zone operator should carefully choose
the model that works best.
Centralized
In a centralized model the zone operator will run controller
that executes all steps necessary and controls all signers.
A centralized controller needs to have authorized access to all signers.
This can be achieved in a variety of different ways. For example will many
service providers offer access through a REST API. Another possibility
is access through Dynamic Update with TSIG authentication.
Decentralized
In the decentralized models all signers will communicate with
each other and execute the necessary steps on their instance
only. For this signers need a specialized protocol to
communicate configuration details that are not part of
the zone data.
Capabilities
In order for any of the models to work the signer must
support the following capabilities.
- Add DNSKEY records (without the private key)
- Remove (previously added) DNSKEY record(s)
- Add CDS and CDNSKEY records for keys not in the DNSKEY set
- Remove (previously added) CDS and CDNSKEY records
- Add CSYNC record
- Remove CSYNC record
Algorithms
Prerequisites
Each Signer to be added, including the initial Signer, must
meet the following prerequisites before joining the Multi-Signer
Group
-
A working setup of the zone, including DNSSEC signing.
-
Uses the same algorithm for DNSSEC signing as the Multi-Signer
group uses or will use.
-
Signer or controller must be able to differentiate between its own keys and
keys from others signers
-
Signer controller must be able to differentiate between NS records that
are updated by itself and NS
records that receive updates from other signers.
-
The domain must be covered by a CDS/CDNSKEY scanner and a
CSYNC scanner. Otherwise updates to the parent zone have to be
made manually.
Definitions
DS Waiting Time
Once the parent has picked up and published the new DS record
set, the any further changes MUST to be delayed until the
new DS set has propagated.
The minimum DS Waiting Time is the TTL of the DS RRset.
DNSKEY Waiting Time
Once the DNSKEY sets of all signers are updated, any further changes
MUST to be delayed until the new DNSKEY set has propagated.
The minimum DNSKEY Waiting Time is the maximum of all DNSKEYS TTL
values from all signers plus the time it takes to publish the zone on
all secondaries.
NS Waiting Time
Once the parent has picked up and published the new NS record set,
any further changes MUST be delayed until the new NS set has
propagated.
The minimum NS Waiting Time is the maximum of the TTL value of the
NS set in the parent zone and all NS sets from all signers.
Setting up a new Multi-Signer group
The zone is already authoritatively served by one DNS operator and is DNSSEC signed.
For full automation both the KSK and ZSK or CSK must be online.
This would be a special case, a Multi-Signer group with only one signer.
A Signer joins the Multi-Signer group
-
Confirm that the incoming Signer meets the prerequisites.
-
Establish a trust mechanism between the Multi-Signer group
and the Signer.
-
Add ZSK for each signer to all other Signers.
-
Calculate CDS/CDNSKEY Records for all KSKs/CSKs represented
in the Multi-Signer group.
-
Configure all Signers with the compiled CDS/CDNSKEY RRSET.
-
Wait for Parent to publish the combined DS RRset.
-
Remove CDS/CDNSKEY Records from all Signers. (optional)
-
Wait maximum of DS-Wait-Time and DNSKEY-Wait-Time
-
Compile NS RRSET including all NS records from all
Signers.
-
Configure all Signers with the compiled NS RRSET.
-
Compare NS RRSET of the Signers to the Parent, if there is a
difference publish CSYNC record with NS and A and AAAA bit
set on all signers.
-
Wait for Parent to publish NS.
-
Remove CSYNC record from all signers. (optional)
A signer leaves the Multi-Signer group
-
Remove exiting Signer's NS records from remaining Signers
-
Compare NS RRSET of the Signers to the Parent, if there
is a difference publish CSYNC record with NS and A and AAAA
bit set on remaining signers.
-
Wait for Parent to publish NS RRSET.
-
Remove CSYNC record from all signers. (optional)
-
Wait NS-Wait-Time
-
Stop the exiting Signer from answering queries.
-
Calculate CDS/CDNSKEY Records for KSKs/CSKs published by
the remaining Signers.
-
Configure remaining Signers with the compiled
CDS/CDNSKEY RRSET.
-
Remove ZSK of the exiting Signer from remaining Signers.
-
Wait for Parent to publish the updated DS RRset.
-
Remove CDS/CDNSKEY set from all signers. (Optional)
A Signer performs a ZSK rollover
-
The signer introduces the new ZSK in its own DNSKEY RRset.
-
Update all signers with the new ZSK.
-
Wait DNSKEY-Wait-Time
-
Signer can start using the new ZSK.
-
When the old ZSK is not used in any signatures by the signer,
the signer can remove the old ZSK from its DNSKEY RRset.
-
Remove ZSK from DNSKEY RRset of all signers.
A Signer performs a CSK or KSK rollover
-
Signer publishes new CSK / KSK in its own DNSKEY RRset.
-
In case of CSK, add CSK to DNSKEY set of all other Signers.
-
Signer signs DNSKEY RRset with old and new CSK / KSK.
-
Calculate new CDS/CDNSKEY RRset and publish on all signers.
-
Wait for parent to pickup and publish new DS RR set.
-
Wait DS-Wait-Time + DNSKEY-Wait-Time
-
Signer removes old CSK/KSK from its DNSKEY RR set. And removes all
signatures done with this key.
-
In case of CSK, remove old CSK from DNSKEY set of all other signers.
-
Calculate new CDS/CDNSKEY RRset and publish on all signers.
-
Wait for parent to pickup and publish new DS RR set.
-
Remove CDS/CDNSKEY RR sets from all signers.
Algorithm rollover for the whole Multi-Signer group.
- All signers publish KSK and ZSK or CSK using the new algorithm.
- All signers sign all zone data with the new keys.
- Wait until all signers have signed all data with the new key(s).
-
Add new ZSK of each signer to all other Signers.
-
Calculate new CDS/CDNSKEY RRset and publish on all signers.
-
Wait for parent to pickup and publish new DS RR set.
-
Wait DS-Wait-Time + DNSKEY-Wait-Time
-
Removes all keys and signatures which are using the old algorithm.
-
Calculate new CDS/CDNSKEY RRset and publish on all signers.
-
Wait for parent to pickup and publish new DS RR set.
-
Remove CDS/CDNSKEY RR sets from all signers.
Signers with different algorithms in one Multi-Signer group
states that
a signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone.
A setup where different signers use different key algorithms therefore
violates .
According to
validators SHOULD NOT insist that all algorithms signaled in the
DS RRset work, and they MUST NOT insist that all algorithms signaled
in the DNSKEY RRset work.
So a Multi-Signer setup where different signers use different key
algorithms should still validate.
This could be an acceptable risk in a situation where going insecure
is not desirable or impossible and name servers have to be changed
between operators which only support distinct set of key algorithms.
We have to consider the following scenarios
Validator supports both algorithms
Validation should be stable through all stages of the multi-signer
algorithms.
Validator supports none of the algorithms
The validator will treat the zone as unsigned. Resolution should
work through all stages of the multi-signer algorithms.
Validator supports only one of the algorithms
The validator will not be able to validate the DNSKEY RR set or
any data from one of the signers. So in some cases the validator
will consider the zone bogus and reply with a SERVFAIL response code.
The later scenario can be mitigated, but not fully eliminated, by
selecting two well supported algorithms.
Acknowledgements
The authors would like to thank the following for their review of
this work and their valuable comments: Steve Crocker, Eric Osterweil,
Roger Murray, Jonas Andersson, Peter Thomassen.
Implementation Status
One implementation of a centralized controller which supports updates
through Dynamic DNS or REST API's of several vendors has been implemented
by the Swedish Internet Foundation.
The code can be found as part of the Multi-Signer project on Github
Security Considerations
Every step of the multi-signer algorithms has to be carefully executed at the right time and date.
Any failure could resolve in the loss of resolution for the domain.
Independently of the chosen model, it is crucial that only authorized entities
will be able to change the zone data. Some providers or software installation allow to
make more specific configuration on the allowed changes. All extra steps to allows as little
access to change zone data as possible should be taken.
If used correctly the multi-signer algorithm will strengthen the DNS security
by avoiding "going insecure" at any stage of the domain life cycle.
- Trying to fix wording to be more precise
- Added algorithm for ZSK rollover
- Added algorithm for KSK rollover
- Added algorithm for algorithm rollover
- Fix sequnce of steps in the joining procedure
- Excplicit handling of CSK cases in CSK/ KSK rollover