Internet Engineering Task Force S. Huque
Internet-Draft P. Aras
Intended status: Informational Salesforce
Expires: September 20, 2018 J. Dickinson
Sinodun
J. Vcelak
NS1
March 19, 2018
Multi Provider DNSSEC models
draft-huque-dnsop-multi-provider-dnssec-02
Abstract
Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Deploying DNSSEC in
such an environment can have some challenges depending on the
configuration and feature set in use. This document will present
several deployment models that may be suitable.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 20, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Huque, et al. Expires September 20, 2018 [Page 1]
Internet-Draft Multi Provider DNSSEC models March 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Serve Only model . . . . . . . . . . . . . . . . . . . . 3
2.2. Sign and Serve model . . . . . . . . . . . . . . . . . . 3
2.2.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4
2.2.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4
2.2.3. Model 3: Shared KSK/ZSK Signing Keys . . . . . . . . 5
2.3. Inline Signing model . . . . . . . . . . . . . . . . . . 5
2.4. Hybrid model . . . . . . . . . . . . . . . . . . . . . . 5
3. Signing Algorithm Considerations . . . . . . . . . . . . . . 5
4. Validating Resolver Behavior . . . . . . . . . . . . . . . . 6
5. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction and Motivation
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at: https://
github.com/shuque/multi-provider-dnssec
Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Two providers are
fairly typical and this allows the DNS service to survive a complete
failure of any single provider. This document outlines some possible
models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an
environment.
2. Deployment Models
The two main models discussed are (1) where the zone owner runs a
master signing server and essentially treats the managed DNS
providers as secondary servers, the "Serve Only" model, and (2) where
the managed DNS providers each act like primary servers, signing data
received from the zone owner and serving it out to DNS queriers, the
"Sign and Serve" model. Inline signing and hybrid models are also
Huque, et al. Expires September 20, 2018 [Page 2]
Internet-Draft Multi Provider DNSSEC models March 2018
briefly mentioned. A large part of this document discusses the Sign
and Serve models, which present novel challenges.
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
authoritative server configurations that use certain non-standardized
DNS features. Some of these features like DNS based Global Server
Load Balancing (GSLB), dynamic failover pools, etc. rely on querier
specific responses, or responses based on real-time state
examination, and so, the answer and corresponding signature has to be
determined at the authoritative server being queried, at the time of
the query, or both. (If all possible answer sets for these features
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
In this category of models, multiple providers each independently
sign and serve the same zone. The zone owner typically uses
provider-specific APIs to update zone content at each of the
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
RRset in such a way that validating resolvers always have a viable
path to authenticate the DNSSEC signature chain no matter which
provider they query and obtain responses from.
Huque, et al. Expires September 20, 2018 [Page 3]
Internet-Draft Multi Provider DNSSEC models March 2018
These models can support DNSSEC even for the non-standard features
mentioned previously, if the DNS providers have the capability of
signing the response data generated by those features. Since these
responses are often generated dynamically at query time, one method
is for the provider to perform online signing (also known as on-the-
fly signing). However, another possible approach is to pre-compute
all the possible response sets and associated signatures and then
algorithmically determine at query time which response set needs to
be returned.
In the first two of these models, the function of coordinating the
DNSKEY or DS RRset does not involve the providers communicating
directly with each other, which they are unlikely to do since they
typically have a contractual relationship only with the zone owner.
The following descriptions consider the case of two DNS providers,
but the model is generalizable to any number.
2.2.1. Model 1: Common KSK, Unique ZSK per provider
o Zone owner holds the KSK, manages the DS record, and is
responsible for signing the DNSKEY RRset and distributing the
signed DNSKEY RRset to the providers.
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,
and insert a combined DNSKEY RRset that includes both ZSKs and the
KSK, signed by the KSK.
o Key rollovers need coordinated participation of the zone owner to
update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for
KSK).
2.2.2. Model 2: Unique KSK and ZSK per provider
o Each provider has their own KSK and ZSK.
o Each provider offers an API that the Zone Owner uses to import the
ZSK of the other provider into their DNSKEY RRset.
o DNSKEY RRset is signed independently by each provider using their
own KSK.
o Zone Owner manages the DS RRset that includes both KSKs.
o Key rollovers need coordinated participation of the zone owner to
update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK).
Huque, et al. Expires September 20, 2018 [Page 4]
Internet-Draft Multi Provider DNSSEC models March 2018
2.2.3. Model 3: Shared KSK/ZSK Signing Keys
Other possible models could involve the KSK and/or ZSK signing keys
shared across providers. Preliminary discussion with several
providers has revealed that this is not a model they are comfortable
with, again because they want to be independently responsible for
securing the signing keys without involvement of other parties they
don't have contractual relationships with. A possible way to
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
In this model, the zone owner runs a master server but does not
perform zone signing, instead pushing out the zone (typically via
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
In the hybrid model, the zone owner uses one provider as the primary,
operating in Sign and Serve mode. The other providers operate in
Serve Only mode, i.e., they are configured as secondary servers,
obtaining the signed zone from the primary provider using the DNS
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
In the Serve Only and Hybrid models, one entity (the Zone Owner in
the former, and the primary provider in the latter) performs the
signing and hence chooses the signing algorithm to be deployed. The
more interesting case is the Sign and Serve model (Section 2.2),
where multiple providers independently sign zone data.
Huque, et al. Expires September 20, 2018 [Page 5]
Internet-Draft Multi Provider DNSSEC models March 2018
Ideally, the providers should be using a common signing algorithm
(and common keysizes for algorithms that support variable key sizes).
This ensures that the multiple providers have identical security
postures and no provider is more vulnerable to cryptanalytic attack
than the others.
It may however be possible to deploy a configuration where different
providers use different signing algorithms. The main impediment is
that current DNSSEC specifications require that if there are multiple
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
RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781],
Section 4.1.4, also describes both a conservative and liberal
interpretation of this requirement. When validating DNS resolvers
follow the liberal approach, they do not expect that zone RRsets are
signed by every signing algorithm in the DNSKEY RRset, and responses
with single algorithm signatures can be validated corectly assuming a
valid chain of trust exists. [TODO: investigate resolver
implementations to see what they actually do.]
4. 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
Huque, et al. Expires September 20, 2018 [Page 6]
Internet-Draft Multi Provider DNSSEC models March 2018
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.
5. Key Rollover Considerations
TBD
6. IANA Considerations
This document includes no request to IANA.
7. Security Considerations
[TBD]
Huque, et al. Expires September 20, 2018 [Page 7]
Internet-Draft Multi Provider DNSSEC models March 2018
8. Acknowledgments
This document benefited from discussions with and review from Duane
Wessels.
9. References
9.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.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[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>.
9.2. Informative References
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, DOI 10.17487/
RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>.
Authors' Addresses
Shumon Huque
Salesforce
Email: shuque@gmail.com
Huque, et al. Expires September 20, 2018 [Page 8]
Internet-Draft Multi Provider DNSSEC models March 2018
Pallavi Aras
Salesforce
Email: paras@salesforce.com
John Dickinson
Sinodun
Email: jad@sinodun.com
Jan Vcelak
NS1
Email: jvcelak@ns1.com
Huque, et al. Expires September 20, 2018 [Page 9]