Multi-Signer DNSSEC Models
RFC 8901

Document Type RFC - Informational (September 2020; No errata)
Authors Shumon Huque  , Pallavi Aras  , John Dickinson  , Jan Včelák  , David Blacka 
Last updated 2020-09-24
Replaces draft-huque-dnsop-multi-provider-dnssec
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Benno Overeinder
Shepherd write-up Show (last changed 2019-12-24)
IESG IESG state RFC 8901 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Warren Kumari
Send notices to Benno Overeinder <benno@NLnetLabs.nl>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                          S. Huque
Request for Comments: 8901                                       P. Aras
Category: Informational                                       Salesforce
ISSN: 2070-1721                                             J. Dickinson
                                                              Sinodun IT
                                                               J. Vcelak
                                                                     NS1
                                                               D. Blacka
                                                                Verisign
                                                          September 2020

                       Multi-Signer DNSSEC Models

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
   describes 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 document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8901.

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
   2.  Deployment Models
     2.1.  Multiple-Signer Models
       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
   4.  Signing-Algorithm Considerations
   5.  Authenticated-Denial Considerations
     5.1.  Single Method
     5.2.  Mixing Methods
   6.  Key Rollover Considerations
     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
   8.  Use of CDS and CDNSKEY
   9.  Key-Management-Mechanism Requirements
   10. DNS Response-Size Considerations
   11. IANA Considerations
   12. Security Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction and Motivation

   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 it 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
   nonstandardized 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" [RFC8499].

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
Show full document text