draft-huque-dnsop-multi-provider-dnssec-03.txt   draft-huque-dnsop-multi-provider-dnssec-04.txt 
Internet Engineering Task Force S. Huque Internet Engineering Task Force S. Huque
Internet-Draft P. Aras Internet-Draft P. Aras
Intended status: Informational Salesforce Intended status: Informational Salesforce
Expires: January 2, 2019 J. Dickinson Expires: July 4, 2019 J. Dickinson
Sinodun Sinodun
J. Vcelak J. Vcelak
NS1 NS1
July 1, 2018 D. Blacka
Verisign
Jan 4, 2019
Multi Provider DNSSEC models Multi Provider DNSSEC models
draft-huque-dnsop-multi-provider-dnssec-03 draft-huque-dnsop-multi-provider-dnssec-04
Abstract Abstract
Many enterprises today employ the service of multiple DNS providers Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Deploying DNSSEC in to distribute their authoritative DNS service. Deploying DNSSEC in
such an environment can have some challenges depending on the such an environment may present some challenges depending on the
configuration and feature set in use. This document will present configuration and feature set in use. This document will present
several deployment models that may be suitable. several deployment models that may be suitable.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2019. This Internet-Draft will expire on July 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Serve Only model . . . . . . . . . . . . . . . . . . . . 3 2.1. Multiple Signer models . . . . . . . . . . . . . . . . . 3
2.2. Sign and Serve model . . . . . . . . . . . . . . . . . . 3 2.1.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4
2.2.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4 2.1.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4
2.2.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4 3. Validating Resolver Behavior . . . . . . . . . . . . . . . . 4
2.2.3. Model 3: Shared KSK/ZSK Signing Keys . . . . . . . . 5 4. Signing Algorithm Considerations . . . . . . . . . . . . . . 5
2.3. Inline Signing model . . . . . . . . . . . . . . . . . . 5 5. Authenticated Denial Considerations . . . . . . . . . . . . . 6
2.4. Hybrid model . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7
3. Signing Algorithm Considerations . . . . . . . . . . . . . . 5 5.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7
4. Authenticated Denial Considerations . . . . . . . . . . . . . 6 6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7
4.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 8
4.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7 6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 8
5. Validating Resolver Behavior . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction and Motivation 1. Introduction and Motivation
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at: The source for this draft is maintained in GitHub at:
https://github.com/shuque/multi-provider-dnssec https://github.com/shuque/multi-provider-dnssec
Many enterprises today employ the service of multiple DNS providers Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Two providers are to distribute their authoritative DNS service. This allows the DNS
fairly typical and this allows the DNS service to survive a complete service to survive a complete failure of any single provider.
failure of any single provider. This document outlines some possible Additionally, enterprises or providers occasionally have requirements
models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an that preclude standard zone transfer techniques [RFC1995] [RFC5936] :
environment. either non-standardized DNS features are in use that are incompatible
with zone transfer, or operationally a provider must be able to
(re)sign DNS records using their own keys. This document outlines
some possible models of DNSSEC [RFC4033] [RFC4034] [RFC4035]
deployment in such an environment.
2. Deployment Models 2. Deployment Models
The two main models discussed are (1) where the zone owner runs a If a zone owner is able to use standard zone transfer techniques,
master signing server and essentially treats the managed DNS then the presence of multiple providers does not present any need to
providers as secondary servers, the "Serve Only" model, and (2) where substantially modify normal deployment models. In these deployments
the managed DNS providers each act like primary servers, signing data there is a single signing entity (which may be the zone owner, one of
received from the zone owner and serving it out to DNS queriers, the the providers, or a separate entity), while the providers act as
"Sign and Serve" model. Inline signing and hybrid models are also secondary authoritative servers for the zone.
briefly mentioned. A large part of this document discusses the Sign
and Serve models, which present novel challenges and requirements.
2.1. Serve Only model
The most straightforward deployment model is one in which the zone
owner runs a primary master DNS server, and manages the signing of
zone data. The master server uses DNS zone transfer mechanisms
(AXFR/IXFR) [RFC5936] [RFC1995] to distribute the signed zone to
multiple DNS providers.
This is also arguably the most secure model because the zone owner
holds the private signing keys. The managed DNS providers cannot
serve bogus data (either maliciously or because of compromise of
their systems) without detection by validating resolvers.
One notable limitation of this model is that it may not work with DNS Occasionally, however, standard zone transfer techniques cannot be
authoritative server configurations that use certain non-standardized used. This could be due to the use of non-standard DNS features, or
DNS features. Some of these features like DNS based Global Server due to operational requirements of a given provider (e.g., a provider
Load Balancing (GSLB), dynamic failover pools, etc. rely on querier that only supports "online signing".) In these scenarios, the
specific responses, or responses based on real-time state multiple providers each act like primary servers, independently
examination, and so, the answer and corresponding signature has to be signing data received from the zone owner and serving it to DNS
determined at the authoritative server being queried, at the time of queriers. This configuration presents some novel challenges and
the query, or both. (If all possible answer sets for these features requirements.
are known in advance, it would be possible to pre-compute these
answer sets and signatures, but the DNS zone transfer protocol cannot
be used to distinguish or transfer such data sets, or the rules used
to select among the possible answers.)
2.2. Sign and Serve model 2.1. Multiple Signer models
In this category of models, multiple providers each independently In this category of models, multiple providers each independently
sign and serve the same zone. The zone owner typically uses sign and serve the same zone. The zone owner typically uses
provider-specific APIs to update zone content at each of the provider-specific APIs to update zone content at each of the
providers, and relies on the provider to perform signing of the data. providers, and relies on the provider to perform signing of the data.
A key requirement here is to manage the contents of the DNSKEY and DS A key requirement here is to manage the contents of the DNSKEY and DS
RRset in such a way that validating resolvers always have a viable RRset in such a way that validating resolvers always have a viable
path to authenticate the DNSSEC signature chain no matter which path to authenticate the DNSSEC signature chain no matter which
provider they query and obtain responses from. This requirement is provider is queried. This requirement is achieved by having each
achieved by having each provider import the Zone Signing Keys of all provider import the public Zone Signing Keys (ZSKs) of all other
other providers into their DNSKEY RRsets. providers into their DNSKEY RRsets.
These models can support DNSSEC even for the non-standard features These models can support DNSSEC even for the non-standard features
mentioned previously, if the DNS providers have the capability of mentioned previously, if the DNS providers have the capability of
signing the response data generated by those features. Since these signing the response data generated by those features. Since these
responses are often generated dynamically at query time, one method responses are often generated dynamically at query time, one method
is for the provider to perform online signing (also known as on-the- is for the provider to perform online signing (also known as online
fly signing). However, another possible approach is to pre-compute or on-the-fly signing). However, another possible approach is to
all the possible response sets and associated signatures and then pre-compute all the possible response sets and associated signatures
algorithmically determine at query time which response set needs to and then algorithmically determine at query time which response set
be returned. needs to be returned.
In the first two of these models, the function of coordinating the In the first two of these models, the function of coordinating the
DNSKEY or DS RRset does not involve the providers communicating DNSKEY or DS RRset does not involve the providers communicating
directly with each other, which they are unlikely to do since they directly with each other, which they are unlikely to do since they
typically have a contractual relationship only with the zone owner. typically have a contractual relationship only with the zone owner.
The following descriptions consider the case of two DNS providers, The following descriptions consider the case of two DNS providers,
but the model is generalizable to any number. but the model is generalizable to any number.
2.2.1. Model 1: Common KSK, Unique ZSK per provider 2.1.1. Model 1: Common KSK, Unique ZSK per provider
o Zone owner holds the KSK, manages the DS record, and is o Zone owner holds the KSK, manages the DS record, and is
responsible for signing the DNSKEY RRset and distributing the responsible for signing the DNSKEY RRset and distributing the
signed DNSKEY RRset to the providers. signed DNSKEY RRset to the providers.
o Each provider has their own ZSK which is used to sign data. o Each provider has their own ZSK which is used to sign data.
o Providers have an API that owner uses to query the ZSK public key, o Providers have an API that owner uses to query the ZSK public key,
and insert a combined DNSKEY RRset that includes both ZSKs and the and insert a combined DNSKEY RRset that includes both ZSKs and the
KSK, signed by the KSK. KSK, signed by the KSK.
o Key rollovers need coordinated participation of the zone owner to o Key rollovers need coordinated participation of the zone owner to
update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for
KSK). KSK).
2.2.2. Model 2: Unique KSK and ZSK per provider 2.1.2. Model 2: Unique KSK and ZSK per provider
o Each provider has their own KSK and ZSK. o Each provider has their own KSK and ZSK.
o Each provider offers an API that the Zone Owner uses to import the o Each provider offers an API that the Zone Owner uses to import the
ZSK of the other provider into their DNSKEY RRset. ZSK of the other provider into their DNSKEY RRset.
o DNSKEY RRset is signed independently by each provider using their o DNSKEY RRset is signed independently by each provider using their
own KSK. own KSK.
o Zone Owner manages the DS RRset that includes both KSKs. o Zone Owner manages the DS RRset that includes both KSKs.
o Key rollovers need coordinated participation of the zone owner to o Key rollovers need coordinated participation of the zone owner to
update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK). update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK).
2.2.3. Model 3: Shared KSK/ZSK Signing Keys 3. Validating Resolver Behavior
Other possible models could involve the KSK and/or ZSK signing keys The central requirement for both of the Multiple Signer models
shared across providers. Preliminary discussion with several (Section 2.1) is to ensure that the ZSKs from all providers are
providers has revealed that this is not a model they are comfortable present in each provider's apex DNSEY RRset, and is vouched for by
with, again because they want to be independently responsible for either the single KSK (in model 1) or each provider's KSK (in model
securing the signing keys without involvement of other parties they 2.) If this is not done, the following situation can arise (assuming
don't have contractual relationships with. A possible way to two providers A and B):
mitigate this concern might be for the zone owner to operate a
networked Hardware Security Module (HSM) which houses the shared
signing keys and performs the signing operations. The signing
instructions and results are communicated over a secure network
channel between the provider and HSM. This could work, but may also
pose performance bottlenecks, particularly for providers that perform
on-the-fly signing. Due to open questions about the operational
viability of this model, it is not discussed further.
2.3. Inline Signing model o The validating resolver follows a referral (delegation) to the
zone in question.
In this model, the zone owner runs a master server but does not o It retrieves the zone's DNSKEY RRset from one of provider A's
perform zone signing, instead pushing out the zone (typically via nameservers.
zone transfer mechanisms) to multiple providers, and relying on those
providers to sign the zone data before serving them out. This model
has to address the same set of requirements as the Sign-and-Serve
model regarding managing the DNSKEY and DS RRsets. However, assuming
standardized zone transfers mechanisms are being used to push out the
zone to the providers, it likely also has the limitation that non-
standardized DNS features cannot be supported or signed. This model
is not discussed further.
2.4. Hybrid model o At some point in time, the resolver attempts to resolve a name in
the zone, while the DNSKEY RRset received from provider A is still
viable in its cache.
In the hybrid model, the zone owner uses one provider as the primary, o It queries one of provider B's nameservers to resolve the name,
operating in Sign and Serve mode. The other providers operate in and obtains a response that is signed by provider B's ZSK, which
Serve Only mode, i.e., they are configured as secondary servers, it cannot authenticate because this ZSK is not present in its
obtaining the signed zone from the primary provider using the DNS cached DNSKEY RRset for the zone that it received from provider A.
zone transfer protocol. This model suffers from the same limitations
as the Serve-Only model. It additionally requires the signing keys
to be held by the primary provider.
3. Signing Algorithm Considerations o The resolver will not accept this response. It may still be able
to ultimately authenticate the name by querying other nameservers
for the zone until it elicits a response from one of provider A's
nameservers. But it has incurred the penalty of additional
roundtrips with other nameservers, with the corresponding latency
and processing costs. The exact number of additional roundtrips
depends on details of the resolver's nameserver selection
algorithm and the number of nameservers configured at provider B.
In the Serve Only and Hybrid models, one entity (the Zone Owner in o It may also be the case that a resolver is unable to provide an
the former, and the primary provider in the latter) performs the authenticated response because it gave up after a certain number
signing and hence chooses the signing algorithm to be deployed. The of retries or a certain amount of delay. Or that downstream
more interesting case is the Sign and Serve model (Section 2.2), clients of the resolver that originated the query timed out
where multiple providers independently sign zone data. waiting for a response.
Ideally, the providers should be using a common signing algorithm Zone owners will want to deploy a DNS service that responds as
efficiently as possible with validatable answers only, and hence it
is important that the DNSKEY RRset at each provider is maintained
with the active ZSKs of all participating providers. This ensures
that resolvers can validate a response no matter which provider's
nameservers it came from.
Details of how the DNSKEY RRset itself is validated differs. In
model 1 (Section 2.1.1), one unique KSK managed by the Zone Owner
signs an identical DNSKEY RRset deployed at each provider, and the
signed DS record in the parent zone refers to this KSK. In model 2
(Section 2.1.2), each provider has a distinct KSK and signs the
DNSKEY RRset with it. The Zone Owner deploys a DS RRset at the
parent zone that contains multiple DS records, each referring to a
distinct provider's KSK. Hence it does not matter which provider's
nameservers the resolver obtains the DNSKEY RRset from, the signed DS
record in each model can authenticate the associated KSK.
4. Signing Algorithm Considerations
It is RECOMMENDED that the providers use a common signing algorithm
(and common keysizes for algorithms that support variable key sizes). (and common keysizes for algorithms that support variable key sizes).
This ensures that the multiple providers have identical security This ensures that the multiple providers have identical security
postures and no provider is more vulnerable to cryptanalytic attack postures and no provider is more vulnerable to cryptanalytic attack
than the others. than the others.
It may however be possible to deploy a configuration where different It may however be possible to deploy a configuration where different
providers use different signing algorithms. The main impediment is providers use different signing algorithms. The main impediment is
that current DNSSEC specifications require that if there are multiple that current DNSSEC specifications require that if there are multiple
algorithms in the DNSKEY RRset, then RRsets in the zone need to be algorithms in the DNSKEY RRset, then RRsets in the zone need to be
signed with at least one DNSKEY of each algorithm, as described in signed with at least one DNSKEY of each algorithm, as described in
RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781], RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781],
Section 4.1.4, also describes both a conservative and liberal Section 4.1.4, also describes both a conservative and liberal
interpretation of this requirement. When validating DNS resolvers interpretation of this requirement. When validating DNS resolvers
follow the liberal approach, they do not expect that zone RRsets are follow the liberal approach, they do not expect that zone RRsets are
signed by every signing algorithm in the DNSKEY RRset, and responses signed by every signing algorithm in the DNSKEY RRset, and responses
with single algorithm signatures can be validated corectly assuming a with single algorithm signatures can be validated corectly assuming a
valid chain of trust exists. In fact, testing by the .BR Top Level valid chain of trust exists. In fact, testing by the .BR Top Level
domain for their planned algorithm rollover [BR-ROLLOVER], domain for their planned algorithm rollover [BR-ROLLOVER],
demonstrates that the liberal approach works. demonstrates that the liberal approach works.
4. Authenticated Denial Considerations 5. Authenticated Denial Considerations
Authentiated denial of existence enables a resolver to validate that Authentiated denial of existence enables a resolver to validate that
a record does not exist. For this purpose, an authoritative server a record does not exist. For this purpose, an authoritative server
presents in a response to the resolver special NSEC (Section 3.1.3 of presents in a response to the resolver special NSEC (Section 3.1.3 of
[RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3 [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3
method enhances NSEC by providing opt-out for signing insecure method enhances NSEC by providing opt-out for signing insecure
delegations and also adds limited protection against zone enumeration delegations and also adds limited protection against zone enumeration
attacks. attacks.
An authoritative server response carrying records for authenticated An authoritative server response carrying records for authenticated
skipping to change at page 7, line 8 skipping to change at page 7, line 5
Doing so however defeats the protection against zone enumeration Doing so however defeats the protection against zone enumeration
provided by NSEC3. A better configuration involves multiple provided by NSEC3. A better configuration involves multiple
providers using different authenticated denial of existence providers using different authenticated denial of existence
mechanisms that all provide zone enumeration defense, such as pre- mechanisms that all provide zone enumeration defense, such as pre-
computed NSEC3, NSEC3 White Lies [RFC7129], NSEC Black Lies computed NSEC3, NSEC3 White Lies [RFC7129], NSEC Black Lies
[BLACKLIES], etc. Note however that having multiple providers [BLACKLIES], etc. Note however that having multiple providers
offering different authenticated denial mechanisms may impact how offering different authenticated denial mechanisms may impact how
effectively resolvers are able to make use of the caching of negative effectively resolvers are able to make use of the caching of negative
responses. responses.
4.1. Single Method 5.1. Single Method
Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the
methods are not used at the same time by different servers). This methods are not used at the same time by different servers). This
configuration is prefered because the behavior is well-defined and configuration is prefered because the behavior is well-defined and
it's closest to the current operational practice. it's closest to the current operational practice.
4.2. Mixing Methods 5.2. Mixing Methods
Compliant resolvers should be able to serve zones when different Compliant resolvers should be able to serve zones when different
authoritative servers for the same zone respond with different authoritative servers for the same zone respond with different
authentiated denial methods because this is normally observed when authentiated denial methods because this is normally observed when
NSEC and NSEC3 are being switched or when NSEC3PARAM is updated. NSEC and NSEC3 are being switched or when NSEC3PARAM is updated.
Resolver software may be however designed to handle a single Resolver software may be however designed to handle a single
transition between two authenticated denial configurations more transition between two authenticated denial configurations more
optimally than permanent setup with mixed authenticated denial optimally than permanent setup with mixed authenticated denial
methods. This could make caching on the resolver side less efficient methods. This could make caching on the resolver side less efficient
skipping to change at page 7, line 37 skipping to change at page 7, line 34
This aspect should be considered especially in context of Aggresive This aspect should be considered especially in context of Aggresive
Use of DNSSEC-Validated Cache [RFC8198]. Use of DNSSEC-Validated Cache [RFC8198].
In case all providers cannot be configured for a matching In case all providers cannot be configured for a matching
authentiated denial, it is advised to find lowest number of possible authentiated denial, it is advised to find lowest number of possible
configurations possible across all used providers. configurations possible across all used providers.
Note that NSEC3 configuration on all providers with different Note that NSEC3 configuration on all providers with different
NSEC3PARAM values is considered a mixed setup. NSEC3PARAM values is considered a mixed setup.
5. Validating Resolver Behavior
From the point of view of the Validating Resolver, the Sign and Serve
models (Section 2.2), that employ multiple providers signing the same
zone data with distinct keys, are the most interesting. In these
models, for each provider, the Zone Signing Keys of the other
providers are imported into the DNSKEY RRset and the DNSKEY RRset is
re-signed. If this is not done, the following situation can arise
(assuming two providers A and B):
o The validating resolver follows a referral (delegation) to the
zone in question.
o It retrieves the zone's DNSKEY RRset from one of provider A's
nameservers.
o At some point in time, the resolver attempts to resolve a name in
the zone, while the DNSKEY RRset received from provider A is still
viable in its cache.
o It queries one of provider B's nameservers to resolve the name,
and obtains a response that is signed by provider B's ZSK, which
it cannot authenticate because this ZSK is not present in its
cached DNSKEY RRset for the zone that it received from provider A.
o The resolver will not accept this response. It may still be able
to ultimately authenticate the name by querying other nameservers
for the zone until it elicits a response from one of provider A's
nameservers. But it has incurred the penalty of additional
roundtrips with other nameservers, with the corresponding latency
and processing costs. The exact number of additional roundtrips
depends on details of the resolver's nameserver selection
algorithm and the number of nameservers configured at provider B.
o It may also be the case that a resolver is unable to provide an
authenticated response because it gave up after a certain number
of retries or a certain amount of delay. Or that downstream
clients of the resolver that originated the query timed out
waiting for a response.
Zone owners will want to deploy a DNS service that responds as
efficiently as possible with validatable answers only, and hence it
is important that the DNSKEY RRset at each provider is maintained
with the active ZSKs of all participating providers. This ensures
that resolvers can validate a response no matter which provider's
nameservers it came from.
Details of how the DNSKEY RRset itself is validated differs. In Sign
and Serve model 1 (Section 2.2.1), one unique KSK managed by the Zone
Owner signs an identical DNSKEY RRset deployed at each provider, and
the signed DS record in the parent zone refers to this KSK. In Sign
and Serve model 2 (Section 2.2.2), each provider has a distinct KSK
and signs the DNSKEY RRset with it. The Zone Owner deploys a DS
RRset at the parent zone that contains multiple DS records, each
referring to a distinct provider's KSK. Hence it does not matter
which provider's nameservers the resolver obtains the DNSKEY RRset
from, the signed DS record in each model can authenticate the
associated KSK.
6. Key Rollover Considerations 6. Key Rollover Considerations
The Sign-and-Serve (Section 2.2) models introduce some new The Multiple Signer (Section 2.1) models introduce some new
requirements for DNSSEC key rollovers. Since this process requirements for DNSSEC key rollovers. Since this process
necessarily involves co-ordinated actions on the part of providers necessarily involves coordinated actions on the part of providers and
and the Zone Owner, one reasonable strategy is for the Zone Owner to the Zone Owner, one reasonable strategy is for the Zone Owner to
initiate key rollover operations. But other operationally plausible initiate key rollover operations. But other operationally plausible
models may also suit, such as a DNS provider initiating a key models may also suit, such as a DNS provider initiating a key
rollover and signaling their intent to the Zone Owner in some manner. rollover and signaling their intent to the Zone Owner in some manner.
The descriptions in this section assume that KSK rollovers employ the The descriptions in this section assume that KSK rollovers employ the
commonly used Double Signature KSK Rollover Method, and that ZSK commonly used Double Signature KSK Rollover Method, and that ZSK
rollovers employ the Pre-Publish ZSK Rollover Method, as described in rollovers employ the Pre-Publish ZSK Rollover Method, as described in
detail in [RFC6781]. With minor modifications, they can also be detail in [RFC6781]. With minor modifications, they can also be
easily adapted to other models, such as Double DS KSK Rollover or easily adapted to other models, such as Double DS KSK Rollover or
Double Signature ZSK rollover, if desired. Double Signature ZSK rollover, if desired.
skipping to change at page 10, line 16 skipping to change at page 8, line 48
o Key Signing Key Rollover: In Model 2, each managed DNS provider o Key Signing Key Rollover: In Model 2, each managed DNS provider
has their own KSK. A KSK roll for provider A does not require any has their own KSK. A KSK roll for provider A does not require any
change in the DNSKEY RRset of provider B, but does require co- change in the DNSKEY RRset of provider B, but does require co-
ordination with the Zone Owner in order to get the DS record set ordination with the Zone Owner in order to get the DS record set
in the parent zone updated. The KSK roll starts with Provider A in the parent zone updated. The KSK roll starts with Provider A
generating a new KSK and including it in their DNSKEY RRSet. The generating a new KSK and including it in their DNSKEY RRSet. The
DNSKey RRset would then be signed by both the new and old KSK. DNSKey RRset would then be signed by both the new and old KSK.
The new KSK is communicated to the Zone Owner, after which the The new KSK is communicated to the Zone Owner, after which the
Zone Owner updates the DS RRset to replace the DS record for the Zone Owner updates the DS RRset to replace the DS record for the
old KSK with a DS record for the new ZSK. After the necessary DS old KSK with a DS record for the new KSK. After the necessary DS
RRset TTL period has elapsed, the old KSK can be removed from RRset TTL period has elapsed, the old KSK can be removed from
provider A's DNSKEY RRset. provider A's DNSKEY RRset.
o Zone Signing Key Rollover: In Model 2, each managed DNS provider o Zone Signing Key Rollover: In Model 2, each managed DNS provider
has their own ZSK. The ZSK roll for provider A would start with has their own ZSK. The ZSK roll for provider A would start with
them generating new ZSK and including it in their DNSKEY RRset and them generating new ZSK and including it in their DNSKEY RRset and
re-signing the new DNSKEY RRset with their KSK. The new ZSK of re-signing the new DNSKEY RRset with their KSK. The new ZSK of
provider A would then be communicated to the Zone Owner, who will provider A would then be communicated to the Zone Owner, who will
initiate the process of importing this ZSK into the DNSKEY RRsets initiate the process of importing this ZSK into the DNSKEY RRsets
of the other providers, using their respective APIs. Once the of the other providers, using their respective APIs. Once the
skipping to change at page 10, line 41 skipping to change at page 9, line 26
7. IANA Considerations 7. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
8. Security Considerations 8. Security Considerations
[TBD] [TBD]
9. Acknowledgments 9. Acknowledgments
This document benefited from discussions with and review from Duane The initial version of this document benefited from discussions with
Wessels and David Blacka. and review from Duane Wessels. Additional helpful comments were
provided by Steve Crocker, Ulrich Wisser, Tony Finch, and Olafur
Gudmundsson.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
editor.org/info/rfc1995>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, <https://www.rfc- DOI 10.17487/RFC6781, December 2012,
editor.org/info/rfc6781>. <https://www.rfc-editor.org/info/rfc6781>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
10.2. Informative References 10.2. Informative References
[BLACKLIES] [BLACKLIES]
Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Existence or Black Lies", <https://tools.ietf.org/html/ Existence or Black Lies", <https://tools.ietf.org/html/
draft-valsorda-dnsop-black-lies>. draft-valsorda-dnsop-black-lies>.
[BR-ROLLOVER] [BR-ROLLOVER]
Neves, F., ".br DNSSEC Algorithm Rollover Update", Neves, F., ".br DNSSEC Algorithm Rollover Update",
in ICANN 62 DNSSEC Workshop, June 2018, in ICANN 62 DNSSEC Workshop, June 2018,
<https://static.ptbl.co/static/ <https://static.ptbl.co/static/
attachments/179548/1529933472.pdf>. attachments/179548/1529933472.pdf>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>. February 2014, <https://www.rfc-editor.org/info/rfc7129>.
Authors' Addresses Authors' Addresses
Shumon Huque Shumon Huque
Salesforce Salesforce
Email: shuque@gmail.com Email: shuque@gmail.com
skipping to change at line 545 skipping to change at page 11, line 18
John Dickinson John Dickinson
Sinodun Sinodun
Email: jad@sinodun.com Email: jad@sinodun.com
Jan Vcelak Jan Vcelak
NS1 NS1
Email: jvcelak@ns1.com Email: jvcelak@ns1.com
David Blacka
Verisign
Email: davidb@verisign.com
 End of changes. 38 change blocks. 
197 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/