Internet Engineering Task Force S. Huque
Internet-Draft P. Aras
Intended status: Informational Salesforce
Expires: October 21, 2020 J. Dickinson
Sinodun
J. Vcelak
NS1
D. Blacka
Verisign
April 19, 2020

Multi Signer DNSSEC models
draft-ietf-dnsop-multi-provider-dnssec-05

Abstract

Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describe these key management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key management requirements on authoritative servers not involved in multi signer configurations.

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 https://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 October 21, 2020.

Copyright Notice

Copyright (c) 2020 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 (https://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 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

RFC EDITOR: PLEASE REMOVE THIS 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 Domain Name System (DNS) [RFC1034] [RFC1035] providers to distribute their authoritative DNS service. This is primarily done for redundancy and availability, and allows the DNS service to survive a complete, catastrophic failure of any single provider. Additionally, enterprises or providers occasionally have requirements that preclude standard zone transfer techniques [RFC1995] [RFC5936] : 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.

This document assumes a reasonable level of familiarity with DNS operations and protocol terms. Much of the terminology is explained in further detail in DNS Terminology.

2. Deployment Models

If a zone owner can use standard zone transfer techniques, then the presence of multiple providers does not require modifications to the normal deployment models. In these deployments, there is a single signing entity (which may be the zone owner, one of the providers, or a separate entity), while the providers act as secondary authoritative servers for the zone.

Occasionally, however, standard zone transfer techniques cannot be used. This could be due to the use of non-standard DNS features, or due to operational requirements of a given provider (e.g., a provider that only supports "online signing".) In these scenarios, the multiple providers each act like primary servers, independently signing data received from the zone owner and serving it to DNS queriers. This configuration presents some novel challenges and requirements.

2.1. Multiple Signer models

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 identically 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 Delegation Signer (DS) RRsets in such a way that validating resolvers always have a viable path to authenticate the DNSSEC signature chain, no matter which provider is queried. This requirement is achieved by having each provider import the public Zone Signing Keys (ZSKs) of all other providers into their DNSKEY RRsets.

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 and signature needs to be returned.

In the models presented, the function of coordinating the DNSKEY or DS RRset does not involve the providers communicating directly with each other. Feedback from several commercial managed DNS providers indicates that they may be unlikely to directly communicate, since they typically have a contractual relationship only with the zone owner. However, if the parties involved are agreeable, it may be possible to devise a protocol mechanism by which the providers directly communicate to share keys. Details of such a protocol are deferred to a future specification document, should there be interest.

In the descriptions below, the Key Signing Key (KSK), and Zone Signing Key (ZSK), correspond to the definitions in [RFC8499], with the caveat that the KSK not only signs the zone apex DNSKEY RRset, but also serves as the Secure Entry Point (SEP) into the zone.

2.1.1. Model 1: Common KSK set, Unique ZSK set per provider

2.1.2. Model 2: Unique KSK set and ZSK set per provider

3. Validating Resolver Behavior

The central requirement for both of the Multiple Signer models is to ensure that the ZSKs from all providers are present in each provider's apex DNSKEY RRset, and is vouched for by either the single KSK (in model 1) or each provider's KSK (in model 2.) If this is not done, the following situation can arise (assuming two providers A and B):

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 differ. In model 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, 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

DNS providers participating in multi-signer models need to use a common DNSSEC signing algorithm (or a common set of algorithms if multiple are in use). This is because the current 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, Section 2.2. If providers employ distinct signing algorithms, then this requirement cannot be satisfied.

5. Authenticated Denial Considerations

Authenticated denial of existence enables a resolver to validate that a record does not exist. For this purpose, an authoritative server presents, in a response to the resolver, signed NSEC (Section 3.1.3 of [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records that provide cryptographic proof of this non-existence. The NSEC3 method enhances NSEC by providing opt-out for signing insecure delegations and also adds limited protection against zone enumeration attacks.

An authoritative server response carrying records for authenticated denial is always self-contained and the receiving resolver doesn't need to send additional queries to complete the proof of denial. For this reason, no rollover is needed when switching between NSEC and NSEC3 for a signed zone.

Since authenticated denial responses are self-contained, NSEC and NSEC3 can be used by different providers to serve the same zone. Doing so however defeats the protection against zone enumeration provided by NSEC3 (because an adversary can trivially enumerate the zone by just querying the providers that employ NSEC). A better configuration involves multiple providers using different authenticated denial of existence mechanisms that all provide zone enumeration defense, such as pre-computed NSEC3, NSEC3 White Lies, NSEC Black Lies, etc. Note however that having multiple providers offering different authenticated denial mechanisms may impact how effectively resolvers are able to make use of the caching of negative responses.

5.1. Single Method

Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the methods are not used at the same time by different servers). This configuration is preferred because the behavior is well-defined and is closest to current operational practice.

5.2. Mixing Methods

Compliant resolvers should be able to validate zone data when different authoritative servers for the same zone respond with different authenticated denial methods because this is normally observed when NSEC and NSEC3 are being switched or when NSEC3PARAM is updated.

Resolver software may, however, be designed to handle a single transition between two authenticated denial configurations more optimally than a permanent setup with mixed authenticated denial methods. This could make caching on the resolver side less efficient and the authoritative servers may observe higher number of queries. This aspect should be considered especially in the context of Aggressive Use of DNSSEC-Validated Cache.

In case all providers cannot be configured with the same authenticated denial mechanism, it is recommended to limit the distinct configurations to the lowest number feasible.

Note that NSEC3 configuration on all providers with different NSEC3PARAM values is considered a mixed setup.

6. Key Rollover Considerations

The Multiple Signer models introduce some new requirements for DNSSEC key rollovers. Since this process necessarily involves coordinated actions on the part of providers and the zone owner, one reasonable strategy is for the zone owner to initiate key rollover operations. But other operationally plausible models may also suit, such as a DNS provider initiating a key rollover and signaling their intent to the zone owner in some manner. The mechanism to communicate this intent could be some secure out-of-band channel that has been agreed upon, or the provider could offer an API function that could be periodically polled by the zone owner.

The descriptions in this section assume two DNS providers for simplicity. They also assume that KSK rollovers employ the commonly used Double Signature KSK Rollover Method, and that ZSK rollovers employ the Pre-Publish ZSK Rollover Method, as described in detail in [RFC6781]. With minor modifications, they can be easily adapted to other models, such as Double DS KSK Rollover or Double Signature ZSK rollover, if desired. Key use timing should follow the recommendations outlined in [RFC6781], but taking into account the additional operations needed by the multi signer models. For example, "time to propagate data to all the authoritative servers" now includes the time to import the new ZSKs into each provider.

6.1. Model 1: Common KSK, Unique ZSK per provider

6.2. Model 2: Unique KSK and ZSK per provider

7. Using Combined Signing Keys

A Combined Signing Key (CSK) is one in which the same key serves the purpose of being both the secure entry point (SEP) key for the zone, and also for signing all the zone data including the DNSKEY RRset (i.e., there is no KSK/ZSK split).

Model 1 is not compatible with CSKs because the zone owner would then hold the sole signing key, and providers would not be able to sign their own zone data.

Model 2 can accommodate CSKs without issue. In this case, any or all of the providers could employ a CSK. The DS record in the parent zone would reference the provider's CSK instead of KSK, and the public CSK will need to be imported into the DNSKEY RRsets of all of the other providers. A CSK key rollover for such a provider would involve the following: The provider generates a new CSK, installs the new CSK into the DNSKEY RRset, and signs it with both the old and new CSK. The new CSK is communicated to the zone owner. The zone owner exports this CSK into the other provider's DNSKEY RRsets and replaces the DS record referencing the old CSK with one referencing the new one in the parent DS RRset. Once all the zone data has been re-signed with the new CSK, the old CSK is removed from the DNSKEY RRset, and the latter is re-signed with only the new CSK. Finally, the old CSK is removed from the DNSKEY RRsets of the other providers.

8. Use of CDS and CDNSKEY

CDS and CDNSKEY records [RFC7344] [RFC8078] are used to facilitate automated updates of DNSSEC secure entry point keys between parent and child zones. Multi-signer DNSSEC configurations can support this too. In Model 1, CDS/CDNSKEY changes are centralized at the zone owner. However, the zone owner will still need to push down updated signed CDNS/DNSKEY RRsets to the providers via the key management mechanism. In Model 2, the key management mechanism needs to support cross importation of the CDS/CDNSKEY records, so that a common view of the RRset can be constructed at each provider, and is visible to the parent zone attempting to update the DS RRset.

9. Key Management Mechanism Requirements

Managed DNS providers typically have their own proprietary zone configuration and data management APIs, commonly utilizing HTTPS/REST interfaces. So, rather than outlining a new API for key management here, we describe the specific functions that the provider API needs to support in order to enable the multi-signer models. The zone owner is expected to use these API functions to perform key management tasks. Other mechanisms that can partly offer these functions, if supported by the providers, include the DNS UPDATE protocol and EPP.

In model 2, once initially bootstrapped with each other's zone signing keys via these API mechanisms, providers could, if desired, periodically query each other's DNSKEY RRsets, authenticate their signatures, and automatically import or withdraw ZSKs in the keyset as key rollover events happen.

10. DNS Response Size Considerations

The Multi-Signer models result in larger DNSKEY RRsets, so the size of a response to a query for the DNSKEY RRset will be larger. The actual size increase depends on multiple factors: DNSKEY algorithm and keysize choices, the number of providers, whether additional keys are pre-published, how many simultaneous key rollovers are in progress etc. Newer elliptic curve algorithms produce keys small enough that the responses will typically be far below the common Internet path MTU. Thus operational concerns related to IP fragmentation or truncation and TCP fallback are unlikely to be encountered. In any case, DNS operators need to ensure that they can emit and process large DNS UDP responses when necessary, and a future migration to alternative transports like DNS over TLS or DNS over HTTPS may make this topic moot.

11. IANA Considerations

This document includes no request to IANA.

12. Security Considerations

The Multi Signer models necessarily involve 3rd party providers holding the private keys that sign the zone owner's data. Obviously this means that the zone owner has decided to place a great deal of trust in these providers. By contrast, the more traditional model in which the zone owner runs a hidden master and uses the zone transfer protocol with the providers, is arguably more secure, because only the zone owner holds the private signing keys, and the 3rd party providers cannot serve bogus data without detection by validating resolvers.

The Zone key import and export APIs required by these models need to be strongly authenticated to prevent tampering of key material by malicious third parties. Many providers today offer REST/HTTPS APIs, where the HTTPS layer provides transport security and server authentication, and that utilize a number of client authentication mechanisms (username/password, API keys etc). If DNS protocol mechanisms like UPDATE are being used for key insertion and deletion, they should similarly be strongly authenticated, e.g. by employing Transaction Signatures (TSIG). Multi-factor authentication could be used to further strengthen security. Key Generation and other general security related operations should follow the guidance specified in [RFC6781].

13. Acknowledgments

The initial version of this document benefited from discussions with and review from Duane Wessels. Additional helpful comments were provided by Steve Crocker, Ulrich Wisser, Tony Finch, Olafur Gudmundsson, Matthijs Mekking, Daniel Migault, and Ben Kaduk.

14. References

14.1. Normative References

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R. and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008.
[RFC6781] Kolkman, O., Mekking, W. and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012.
[RFC7344] Kumari, W., Gudmundsson, O. and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017.
[RFC8198] Fujiwara, K., Kato, A. and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017.

14.2. Informative References

[BLACKLIES] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Existence or Black Lies"
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D. and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018.
[RFC8499] Hoffman, P., Sullivan, A. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019.

Authors' Addresses

Shumon Huque Salesforce EMail: shuque@gmail.com
Pallavi Aras Salesforce EMail: paras@salesforce.com
John Dickinson Sinodun EMail: jad@sinodun.com
Jan Vcelak NS1 EMail: jvcelak@ns1.com
David Blacka Verisign EMail: davidb@verisign.com