Diff: rfc8901xml2.original.xml

	rfc8901xml2.original.xml	rfc8901.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->


	<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	.1034.xml">
	<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.1035.xml">
	<!ENTITY RFC1995 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.1995.xml">
	<!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2136.xml">
	<!ENTITY RFC2845 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2845.xml">
	<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4033.xml">
	<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4034.xml">
	<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4035.xml">
	<!ENTITY RFC5155 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5155.xml">
	<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5731.xml">
	<!ENTITY RFC5936 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5936.xml">
	<!ENTITY RFC6781 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6781.xml">
	<!ENTITY RFC7129 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7129.xml">
	<!ENTITY RFC7344 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7344.xml">
	<!ENTITY RFC7858 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7858.xml">
	<!ENTITY RFC8078 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8078.xml">
	<!ENTITY RFC8198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8198.xml">
	<!ENTITY RFC8484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8484.xml">
	<!ENTITY RFC8499 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8499.xml">
	<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.o
	rg/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
	]>


	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	<!-- used by XSLT processors -->	docName="draft-ietf-dnsop-multi-provider-dnssec-05" number="8901"
	<!-- For a complete list and description of processing instructions (PIs),	ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
	please see http://xml.resource.org/authoring/README.html. -->	category="info" consensus="true" xml:lang="en" tocInclude="true"
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds	tocDepth="4" symRefs="true" sortRefs="true" version="3">
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc category="info" docName="draft-ietf-dnsop-multi-provider-dnssec-05" ipr="tr
	ust200902">
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: full3667, noModification3667, noDerivatives3667
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->


	<!-- *** FRONT MATTER *** -->	<!-- xml2rfc v2v3 conversion 2.44.0 -->

	<front>	<front>

	<title abbrev="Multi Signer DNSSEC models">Multi Signer DNSSEC models</title >


		<title abbrev="Multi-Signer DNSSEC Models">Multi-Signer DNSSEC Models</title
		>
		<seriesInfo name="RFC" value="8901"/>
	<author fullname="Shumon Huque" initials="S." surname="Huque">	<author fullname="Shumon Huque" initials="S." surname="Huque">
	<organization>Salesforce</organization>	<organization>Salesforce</organization>
	<address>	<address>

		<postal>
		<street>415 Mission Street, 3rd Floor</street>
		<city>San Francisco</city>
		<region>CA</region>
		<code>94105</code>
		<country>United States of America</country>
		</postal>
	<email>shuque@gmail.com</email>	<email>shuque@gmail.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="Pallavi Aras" initials="P." surname="Aras">	<author fullname="Pallavi Aras" initials="P." surname="Aras">
	<organization>Salesforce</organization>	<organization>Salesforce</organization>
	<address>	<address>

		<postal>
		<street>415 Mission Street, 3rd Floor</street>
		<city>San Francisco</city>
		<region>CA</region>
		<code>94105</code>
		<country>United States of America</country>
		</postal>
	<email>paras@salesforce.com</email>	<email>paras@salesforce.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="John Dickinson" initials="J." surname="Dickinson">	<author fullname="John Dickinson" initials="J." surname="Dickinson">

	<organization>Sinodun</organization>	<organization>Sinodun IT</organization>
	<address>	<address>

		<postal>
		<street>Magdalen Centre</street>
		<street>Oxford Science Park</street>
		<city>Oxford</city>
		<code>OX4 4GA</code>
		<country>United Kingdom</country>
		</postal>
	<email>jad@sinodun.com</email>	<email>jad@sinodun.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="Jan Vcelak" initials="J." surname="Vcelak">	<author fullname="Jan Vcelak" initials="J." surname="Vcelak">
	<organization>NS1</organization>	<organization>NS1</organization>
	<address>	<address>

		<postal>
		<street>55 Broad Street, 19th Floor</street>
		<city>New York</city>
		<region>NY</region>
		<code>10004</code>
		<country>United States of America</country>
		</postal>
	<email>jvcelak@ns1.com</email>	<email>jvcelak@ns1.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="David Blacka" initials="D." surname="Blacka">	<author fullname="David Blacka" initials="D." surname="Blacka">
	<organization>Verisign</organization>	<organization>Verisign</organization>
	<address>	<address>

		<postal>
		<street>12061 Bluemont Way</street>
		<city>Reston</city>
		<region>VA</region>
		<code>20190</code>
		<country>United States of America</country>
		</postal>
	<email>davidb@verisign.com</email>	<email>davidb@verisign.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

		<date month="September" year="2020"/>
	<date month="April" year="2020" />

	<!-- Meta-data Declarations -->

	<area>General</area>	<area>General</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>Internet Engineering Task Force</workgroup>

	<keyword>Internet-Draft</keyword>
	<keyword>DNSSEC</keyword>	<keyword>DNSSEC</keyword>
	<keyword>Multiple</keyword>	<keyword>Multiple</keyword>
	<keyword>Provider</keyword>	<keyword>Provider</keyword>
	<keyword>Signer</keyword>	<keyword>Signer</keyword>
	<keyword>Models</keyword>	<keyword>Models</keyword>


	<abstract>	<abstract>
	<t>	<t>
	Many enterprises today employ the service of multiple DNS	Many enterprises today employ the service of multiple DNS
	providers to distribute their authoritative DNS service.	providers to distribute their authoritative DNS service.
	Deploying DNSSEC in such an environment may present some	Deploying DNSSEC in such an environment may present some

	challenges depending on the configuration and feature set	challenges, depending on the configuration and feature set
	in use. In particular, when each DNS provider independently	in use. In particular, when each DNS provider independently

	signs zone data with their own keys, additional key management	signs zone data with their own keys, additional key-management
	mechanisms are necessary. This document presents deployment	mechanisms are necessary. This document presents deployment

	models that accommodate this scenario and describe these key	models that accommodate this scenario and describes these
	management requirements. These models do not require any changes	key-management requirements. These models do not require any changes
	to the behavior of validating resolvers, nor do they impose the	to the behavior of validating resolvers, nor do they impose the

	new key management requirements on authoritative servers not	new key-management requirements on authoritative servers not
	involved in multi signer configurations.	involved in multi-signer configurations.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

		<section numbered="true" toc="default">
	<section title="Introduction and Motivation">	<name>Introduction and Motivation</name>
	<t>
	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
	</t>
	<t>	<t>
	Many enterprises today employ the service of multiple Domain Name	Many enterprises today employ the service of multiple Domain Name

	System (DNS) <xref target="RFC1034" /> <xref target="RFC1035" />	System (DNS) <xref target="RFC1034" format="default"/> <xref target="RFC 1035" format="default"/>
	providers to distribute their authoritative DNS service. This is	providers to distribute their authoritative DNS service. This is

	primarily done for redundancy and availability, and allows the DNS	primarily done for redundancy and availability, and it allows the DNS
	service to survive a complete, catastrophic failure of any single	service to survive a complete, catastrophic failure of any single
	provider. Additionally, enterprises or providers occasionally have	provider. Additionally, enterprises or providers occasionally have

	requirements that preclude standard zone transfer techniques	requirements that preclude standard zone-transfer techniques
	<xref target="RFC1995" /> <xref target="RFC5936" />	<xref target="RFC1995" format="default"/><xref target="RFC5936"
	: either non-standardized DNS features are in use that are	format="default"/>: either nonstandardized DNS features are in use
	incompatible with zone transfer, or operationally a provider	that are incompatible with zone transfer, or operationally a provider
	must be able to (re)sign DNS records using their own keys.	must be able to (re-)sign DNS records using their own keys.
	This document outlines some possible models of DNSSEC	This document outlines some possible models of DNSSEC

	<xref target="RFC4033" /> <xref target="RFC4034" />	<xref target="RFC4033" format="default"/> <xref target="RFC4034"
	<xref target="RFC4035" /> deployment in such an environment.	format="default"/> <xref target="RFC4035" format="default"/> deployment
		in such an environment.
	</t>	</t>
	<t>	<t>
	This document assumes a reasonable level of familiarity with	This document assumes a reasonable level of familiarity with
	DNS operations and protocol terms. Much of the terminology	DNS operations and protocol terms. Much of the terminology

	is explained in further detail in <xref target="RFC8499">	is explained in further detail in <xref target="RFC8499" format="default
	DNS Terminology</xref>.	">
		"DNS Terminology"</xref>.
	</t>	</t>


	</section>	</section>

		<section anchor="models" numbered="true" toc="default">
	<section title="Deployment Models" anchor="models">	<name>Deployment Models</name>

	<t>	<t>

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


	<t>	<t>

	Occasionally, however, standard zone transfer techniques	Occasionally, however, standard zone-transfer techniques
	cannot be used. This could be due to the use of non-standard	cannot be used. This could be due to the use of nonstandard
	DNS features, or due to operational requirements of a given	DNS features or the operational requirements of a given
	provider (e.g., a provider that only supports "online	provider (e.g., a provider that only supports "online

	signing".) In these scenarios, the multiple providers each act	signing"). In these scenarios, the multiple providers each act
	like primary servers, independently signing data received from	like primary servers, independently signing data received from
	the zone owner and serving it to DNS queriers. This configuration	the zone owner and serving it to DNS queriers. This configuration
	presents some novel challenges and requirements.	presents some novel challenges and requirements.
	</t>	</t>

		<section anchor="multi-sign" numbered="true" toc="default">
	<section title="Multiple Signer models" anchor="multi-sign">	<name>Multiple-Signer Models</name>

	<t>	<t>
	In this category of models, multiple providers each	In this category of models, multiple providers each
	independently sign and serve the same zone. The zone owner	independently sign and serve the same zone. The zone owner
	typically uses provider-specific APIs to update zone content	typically uses provider-specific APIs to update zone content

	identically at each of the providers, and relies on the provider	identically at each of the providers and relies on the provider
	to perform signing of the data. A key requirement here is to	to perform signing of the data. A key requirement here is to
	manage the contents of the DNSKEY and Delegation Signer (DS) RRsets	manage the contents of the DNSKEY and Delegation Signer (DS) RRsets
	in such a way that validating resolvers always have a viable path	in such a way that validating resolvers always have a viable path
	to authenticate the DNSSEC signature chain, no matter which	to authenticate the DNSSEC signature chain, no matter which
	provider is queried. This requirement is achieved by having	provider is queried. This requirement is achieved by having
	each provider import the public Zone Signing Keys (ZSKs) of	each provider import the public Zone Signing Keys (ZSKs) of
	all other providers into their DNSKEY RRsets.	all other providers into their DNSKEY RRsets.
	</t>	</t>


	<t>	<t>

	These models can support DNSSEC even for the non-standard	These models can support DNSSEC even for the nonstandard
	features mentioned previously, if the DNS providers have the	features mentioned previously, if the DNS providers have the
	capability of signing the response data generated by those	capability of signing the response data generated by those
	features. Since these responses are often generated	features. Since these responses are often generated
	dynamically at query time, one method is for the provider to	dynamically at query time, one method is for the provider to
	perform online signing (also known as on-the-fly signing). However,	perform online signing (also known as on-the-fly signing). However,

	another possible approach is to pre-compute all the possible	another possible approach is to precompute all the possible
	response sets and associated signatures, and then algorithmically	response sets and associated signatures and then algorithmically
	determine at query time which response set and signature needs	determine at query time which response set and signature need
	to be returned.	to be returned.
	</t>	</t>


	<!-- davib: unsure if this paragraph is needed -->
	<t>	<t>
	In the models presented, the function of coordinating the DNSKEY or	In the models presented, the function of coordinating the DNSKEY or
	DS RRset does not involve the providers communicating directly with	DS RRset does not involve the providers communicating directly with

	each other. Feedback from several commercial managed DNS providers	each other. Feedback from several commercial managed-DNS providers
	indicates that they may be unlikely to directly communicate, since	indicates that they may be unlikely to directly communicate, since
	they typically have a contractual relationship only with the zone	they typically have a contractual relationship only with the zone
	owner. However, if the parties involved are agreeable, it may be	owner. However, if the parties involved are agreeable, it may be
	possible to devise a protocol mechanism by which the providers	possible to devise a protocol mechanism by which the providers
	directly communicate to share keys. Details of such a protocol are	directly communicate to share keys. Details of such a protocol are
	deferred to a future specification document, should there be interest.	deferred to a future specification document, should there be interest.
	</t>	</t>


	<t>	<t>

	In the descriptions below, the Key Signing Key (KSK), and Zone	In the descriptions below, the Key Signing Key (KSK) and Zone
	Signing Key (ZSK), correspond to the definitions in	Signing Key (ZSK) correspond to the definitions in
	<xref target="RFC8499" />, with the caveat that the KSK not	<xref target="RFC8499" format="default"/>, with the caveat that the KSK
	only signs the zone apex DNSKEY RRset, but also serves as the	not
		only signs the zone apex DNSKEY RRset but also serves as the
	Secure Entry Point (SEP) into the zone.	Secure Entry Point (SEP) into the zone.
	</t>	</t>

		<section anchor="model1" numbered="true" toc="default">
	<section title="Model 1: Common KSK set, Unique ZSK set per provider" an	<name>Model 1: Common KSK Set, Unique ZSK Set per Provider</name>
	chor="model1">	<ul spacing="normal">
	<t>	<li>The zone owner holds the KSK set, manages the DS record set,
	<list style="symbols">
	<t>The zone owner holds the KSK set, manages the DS record set,
	and is responsible for signing the DNSKEY RRset and distributing	and is responsible for signing the DNSKEY RRset and distributing

	it to the providers.</t>	it to the providers.</li>
	<t>Each provider has their own ZSK set which is used to sign data	<li>Each provider has their own ZSK set, which is used to sign data
	in the zone.</t>	in the zone.</li>
	<t>The providers have an API that the zone owner uses to query the ZSK	<li>The providers have an API that the zone owner uses to query the
	public keys, and insert a combined DNSKEY RRset that includes	ZSK
	the ZSK sets of each provider, and the KSK set, signed by the KSK.</t	public keys and insert a combined DNSKEY RRset that includes
	>	the ZSK sets of each provider and the KSK set, signed by the KSK.</li
	<t>Note that even if the contents of the DNSKEY RRset do not change,	>
		<li>Note that even if the contents of the DNSKEY RRset do not change
		,
	the zone owner needs to periodically re-sign it as signature	the zone owner needs to periodically re-sign it as signature
	expiration approaches. The provider API is also used	expiration approaches. The provider API is also used

	to thus periodically redistribute the refreshed DNSKEY RRset.</t>	to thus periodically redistribute the refreshed DNSKEY RRset.</li>
	<t>Key rollovers need coordinated participation of the zone	<li>Key rollovers need coordinated participation of the zone
	owner to update the DNSKEY RRset (for KSK or ZSK), and the	owner to update the DNSKEY RRset (for KSK or ZSK) and the
	DS RRset (for KSK).</t>	DS RRset (for KSK).</li>
	<t>(One specific variant of this model that may be interesting is	<li>(One specific variant of this model that may be interesting is
	a configuration in which there is only a single provider. A	a configuration in which there is only a single provider. A
	possible use case for this is where the zone owner wants to	possible use case for this is where the zone owner wants to
	outsource the signing and operation of their DNS zone to a single	outsource the signing and operation of their DNS zone to a single

	3rd party provider, but still control the KSK, so that they can	third-party provider but still control the KSK, so that they can
	authorize and/or revoke the use of specific zone signing keys.)</t>	authorize and/or revoke the use of specific zone signing keys.)</li>
	</list>	</ul>
	</t>
	</section>	</section>

		<section anchor="model2" numbered="true" toc="default">
	<section title="Model 2: Unique KSK set and ZSK set per provider" anchor	<name>Model 2: Unique KSK Set and ZSK Set per Provider</name>
	="model2">	<ul spacing="normal">
	<t>	<li>Each provider has their own KSK and ZSK sets.</li>
	<list style="symbols">	<li>Each provider offers an API that the zone owner uses to import
	<t>Each provider has their own KSK and ZSK sets.</t>	the ZSK sets of the other providers into their DNSKEY RRset.</li>
	<t>Each provider offers an API that the zone owner uses to import	<li>The DNSKEY RRset is signed independently by each provider using
	the ZSK sets of the other providers into their DNSKEY RRset.</t>	their own KSK.</li>
	<t>The DNSKEY RRset is signed independently by each provider using	<li>The zone owner manages the DS RRset located in the parent zone.
	their own KSK.</t>
	<t>The zone owner manages the DS RRset located in the parent zone.
	This is comprised of DS records corresponding to the KSKs of	This is comprised of DS records corresponding to the KSKs of

	each provider.</t>	each provider.</li>
	<t>Key rollovers need coordinated participation of the zone	<li>Key rollovers need coordinated participation of the zone
	owner to update the DS RRset (for KSK), and the DNSKEY	owner to update the DS RRset (for KSK) and the DNSKEY
	RRset (for ZSK).</t>	RRset (for ZSK).</li>
	</list>	</ul>
	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="resolver" numbered="true" toc="default">
	<section title="Validating Resolver Behavior" anchor="resolver">	<name>Validating Resolver Behavior</name>

	<t>	<t>

	The central requirement for both of the <xref	The central requirement for both of the <xref target="multi-sign"
	target="multi-sign">Multiple Signer models</xref> is to ensure	format="default">multiple-signer models</xref> is to ensure
	that the ZSKs from all providers are present in each	that the ZSKs from all providers are present in each

	provider's apex DNSKEY RRset, and is vouched for by either the	provider's apex DNSKEY RRset and vouched for by either the
	single KSK (in model 1) or each provider's KSK (in model 2.)	single KSK (in Model 1) or each provider's KSK (in Model 2.)

	If this is not done, the following situation can arise (assuming	If this is not done, the following situation can arise (assuming

	two providers A and B):	two providers, A and B):


	<list style="symbols">	</t>
	<t>The validating resolver follows a referral (i.e. secure delegation)	<ul spacing="normal">
	to the zone in question.</t>	<li>The validating resolver follows a referral (i.e., secure delegation)
	<t>It retrieves the zone's DNSKEY RRset from one of provider	to the zone in question.</li>
		<li>It retrieves the zone's DNSKEY RRset from one of Provider
	A's nameservers, authenticates it against the parent DS RRset,	A's nameservers, authenticates it against the parent DS RRset,

	and caches it.</t>	and caches it.</li>
	<t>At some point in time, the resolver attempts to resolve a	<li>At some point in time, the resolver attempts to resolve a
	name in the zone, while the DNSKEY RRset received from provider A	name in the zone while the DNSKEY RRset received from Provider A
	is still viable in its cache.</t>	is still viable in its cache.</li>
	<t>It queries one of provider B's nameservers to resolve the	<li>It queries one of Provider B's nameservers to resolve the
	name, and obtains a response that is signed by provider B's	name and obtains a response that is signed by Provider B's
	ZSK, which it cannot authenticate because this ZSK is not present	ZSK, which it cannot authenticate because this ZSK is not present
	in its cached DNSKEY RRset for the zone that it received from	in its cached DNSKEY RRset for the zone that it received from

	provider A.</t>	Provider A.</li>
	<t>The resolver will not accept this response. It may still	<li>The resolver will not accept this response. It may still
	be able to ultimately authenticate the name by querying other	be able to ultimately authenticate the name by querying other
	nameservers for the zone until it elicits a response from one	nameservers for the zone until it elicits a response from one

	of provider A's nameservers. But it has incurred the penalty	of Provider A's nameservers. But it has incurred the penalty
	of additional roundtrips with other nameservers, with the	of additional round trips with other nameservers, with the
	corresponding latency and processing costs. The exact number	corresponding latency and processing costs. The exact number

	of additional roundtrips depends on details of the resolver's	of additional round trips depends on details of the resolver's
	nameserver selection algorithm and the number of nameservers	nameserver-selection algorithm and the number of nameservers
	configured at provider B.</t>	configured at Provider B.</li>
	<t>It may also be the case that a resolver is unable to	<li>It may also be the case that a resolver is unable to
	provide an authenticated response because it gave up after	provide an authenticated response, because it gave up after
	a certain number of retries or a certain amount of delay, or	a certain number of retries or a certain amount of delay; or it is
	that downstream clients of the resolver that originated the	possible that downstream clients of the resolver that originated the
	query timed out waiting for a response.	query timed out waiting for a response.

	</t>	</li>
	</list>	</ul>
		<t>

	Hence, it is important that the DNSKEY RRset at each provider is	Hence, it is important that the DNSKEY RRset at each provider is
	maintained with the active ZSKs of all participating providers.	maintained with the active ZSKs of all participating providers.
	This ensures that resolvers can validate a response no matter	This ensures that resolvers can validate a response no matter
	which provider's nameservers it came from.	which provider's nameservers it came from.
	</t>	</t>


	<t>	<t>
	Details of how the DNSKEY RRset itself is validated differ.	Details of how the DNSKEY RRset itself is validated differ.

	In <xref target="model1">model 1</xref>, one unique KSK	In <xref target="model1" format="default">Model 1</xref>, one unique KSK
	managed by the zone owner signs an identical DNSKEY RRset	managed by the zone owner signs an identical DNSKEY RRset
	deployed at each provider, and the signed DS record in the	deployed at each provider, and the signed DS record in the

	parent zone refers to this KSK. In <xref	parent zone refers to this KSK. In <xref target="model2" format="default
	target="model2">model 2</xref>, each provider has a	">Model 2</xref>, each provider has a
	distinct KSK and signs the DNSKEY RRset with it. The zone	distinct KSK and signs the DNSKEY RRset with it. The zone
	owner deploys a DS RRset at the parent zone that contains	owner deploys a DS RRset at the parent zone that contains
	multiple DS records, each referring to a distinct provider's	multiple DS records, each referring to a distinct provider's

	KSK. Hence it does not matter which provider's nameservers the	KSK. Hence, it does not matter which provider's nameservers the
	resolver obtains the DNSKEY RRset from, the signed DS record	resolver obtains the DNSKEY RRset from; the signed DS record
	in each model can authenticate the associated KSK.	in each model can authenticate the associated KSK.
	</t>	</t>


	</section>	</section>

		<section anchor="algorithms" numbered="true" toc="default">
	<section title="Signing Algorithm Considerations" anchor="algorithms">	<name>Signing-Algorithm Considerations</name>

	<t>	<t>
	DNS providers participating in multi-signer models need to use	DNS providers participating in multi-signer models need to use
	a common DNSSEC signing algorithm (or a common set of algorithms	a common DNSSEC signing algorithm (or a common set of algorithms

	if multiple are in use). This is because the current specifications	if several are in use). This is because the current specifications
	require that if there are multiple algorithms in the DNSKEY RRset,	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	then RRsets in the zone need to be signed with at least one DNSKEY

	of each algorithm, as described in	of each algorithm, as described in <xref target="RFC4035"
	<xref target="RFC4035">RFC 4035</xref>, Section 2.2. If providers	sectionFormat="comma" section="2.2"/>. If providers
	employ distinct signing algorithms, then this requirement cannot	employ distinct signing algorithms, then this requirement cannot
	be satisfied.	be satisfied.
	</t>	</t>


	</section>	</section>

		<section anchor="nsec" numbered="true" toc="default">
	<section title="Authenticated Denial Considerations" anchor="nsec">	<name>Authenticated-Denial Considerations</name>
	<t>	<t>
	Authenticated denial of existence enables a resolver to validate that	Authenticated 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, signed NSEC (Section 3.1.3 of	presents, in a response to the resolver, signed NSEC (<xref
	<xref target="RFC4035" />) or NSEC3 (Section 7.2 of <xref	target="RFC4035" sectionFormat="of" section="3.1.3"/>) or NSEC3
	target="RFC5155" />) records that provide cryptographic proof of	(<xref target="RFC5155" sectionFormat="of" section="7.2"/>) records
	this non-existence. The NSEC3 method enhances NSEC by	that provide cryptographic proof of
		this nonexistence. The NSEC3 method enhances NSEC by
	providing opt-out for signing insecure delegations and also adds	providing opt-out for signing insecure delegations and also adds

	limited protection against zone enumeration attacks.	limited protection against zone-enumeration attacks.
	</t>	</t>


	<t>	<t>
	An authoritative server response carrying records for authenticated	An authoritative server response carrying records for authenticated

	denial is always self-contained and the receiving resolver doesn't	denial is always self-contained, and the receiving resolver doesn't
	need to send additional queries to complete the proof of denial.	need to send additional queries to complete the proof of denial.
	For this reason, no rollover is needed when switching between NSEC	For this reason, no rollover is needed when switching between NSEC
	and NSEC3 for a signed zone.	and NSEC3 for a signed zone.
	</t>	</t>


	<t>	<t>

	Since authenticated denial responses are self-contained, NSEC and	Since authenticated-denial responses are self-contained, NSEC and
	NSEC3 can be used by different providers to serve the same zone.	NSEC3 can be used by different providers to serve the same zone.

	Doing so however defeats the protection against zone enumeration	Doing so, however, defeats the protection against zone enumeration
	provided by NSEC3 (because an adversary can trivially enumerate	provided by NSEC3 (because an adversary can trivially enumerate
	the zone by just querying the providers that employ NSEC). A	the zone by just querying the providers that employ NSEC). A
	better configuration involves multiple providers using different	better configuration involves multiple providers using different

	authenticated denial of existence mechanisms that all provide zone	authenticated denial-of-existence mechanisms that all provide
	enumeration defense, such as pre-computed NSEC3,	zone-enumeration defense, such as precomputed NSEC3,
	<xref target="RFC7129">NSEC3 White Lies</xref>,	<xref target="RFC7129" format="default">NSEC3 white lies</xref>,
	<xref target="BLACKLIES">NSEC Black Lies</xref>, etc. Note however	<xref target="I-D.valsorda-dnsop-black-lies" format="default">NSEC
	that having multiple providers offering different authenticated denial	black lies</xref>, etc. Note, however,
		that having multiple providers offering different authenticated-denial
	mechanisms may impact how effectively resolvers are able to make	mechanisms may impact how effectively resolvers are able to make
	use of the caching of negative responses.	use of the caching of negative responses.
	</t>	</t>

		<section numbered="true" toc="default">
	<section title="Single Method">	<name>Single Method</name>
	<t>	<t>

	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 preferred because the behavior is well-defined and	configuration is preferred, because the behavior is well defined and
	is closest to current operational practice.	closest to current operational practice.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Mixing Methods">	<name>Mixing Methods</name>
	<t>	<t>
	Compliant resolvers should be able to validate zone data when	Compliant resolvers should be able to validate zone data when
	different authoritative servers for the same zone respond with	different authoritative servers for the same zone respond with

	different authenticated denial methods because this is normally	different authenticated-denial methods, because this is normally
	observed when NSEC and NSEC3 are being switched or when NSEC3PARAM	observed when NSEC and NSEC3 are being switched or when NSEC3PARAM
	is updated.	is updated.
	</t>	</t>
	<t>	<t>
	Resolver software may, however, be designed to handle a single	Resolver software may, however, be designed to handle a single
	transition between two authenticated denial configurations more	transition between two authenticated denial configurations more

	optimally than a permanent setup with mixed authenticated denial	optimally than a permanent setup with mixed authenticated-denial
	methods. This could make caching on the resolver side less	methods. This could make caching on the resolver side less

	efficient and the authoritative servers may observe higher number	efficient, and the authoritative servers may observe a higher number
	of queries. This aspect should be considered especially in the	of queries. This aspect should be considered especially in the

	context of <xref target="RFC8198" >Aggressive Use of DNSSEC-Validated	context of <xref target="RFC8198" format="default">"Aggressive Use of
	Cache</xref>.	DNSSEC-Validated
		Cache"</xref>.
	</t>	</t>
	<t>	<t>
	In case all providers cannot be configured with the same	In case all providers cannot be configured with the same

	authenticated denial mechanism, it is recommended to limit	authenticated-denial mechanism, it is recommended to limit
	the distinct configurations to the lowest number feasible.	the distinct configurations to the lowest number feasible.
	</t>	</t>


	<t>	<t>
	Note that NSEC3 configuration on all providers with	Note that NSEC3 configuration on all providers with
	different NSEC3PARAM values is considered a mixed setup.	different NSEC3PARAM values is considered a mixed setup.
	</t>	</t>
	</section>	</section>


	</section>	</section>

		<section anchor="keyrollover" numbered="true" toc="default">
	<section title="Key Rollover Considerations" anchor="keyrollover">	<name>Key Rollover Considerations</name>
	<t>	<t>

	The <xref target="multi-sign">Multiple Signer</xref> models	The <xref target="multi-sign" format="default">multiple-signer</xref> mo dels
	introduce some new requirements for DNSSEC key rollovers.	introduce some new requirements for DNSSEC key rollovers.
	Since this process necessarily involves coordinated actions on	Since this process necessarily involves coordinated actions on
	the part of providers and the zone owner, one reasonable	the part of providers and the zone owner, one reasonable

	strategy is for the zone owner to initiate key rollover	strategy is for the zone owner to initiate key-rollover
	operations. But other operationally plausible models may also	operations. But other operationally plausible models may also
	suit, such as a DNS provider initiating a key rollover and	suit, such as a DNS provider initiating a key rollover and
	signaling their intent to the zone owner in some manner. The	signaling their intent to the zone owner in some manner. The
	mechanism to communicate this intent could be some secure	mechanism to communicate this intent could be some secure
	out-of-band channel that has been agreed upon, or the provider	out-of-band channel that has been agreed upon, or the provider
	could offer an API function that could be periodically polled	could offer an API function that could be periodically polled
	by the zone owner.	by the zone owner.
	</t>	</t>
	<t>	<t>

	The descriptions in this section assume two DNS providers	For simplicity, the descriptions in this section assume two DNS
	for simplicity. They also assume that KSK rollovers employ	providers. They also assume that KSK rollovers employ
	the commonly used Double Signature KSK Rollover Method, and	the commonly used Double-Signature KSK rollover method and
	that ZSK rollovers employ the Pre-Publish ZSK Rollover	that ZSK rollovers employ the Pre-Publish ZSK rollover
	Method, as described in detail in <xref target="RFC6781"/>.	method, as described in detail in <xref target="RFC6781" format="default
		"/>.
	With minor modifications, they can be easily adapted to	With minor modifications, they can be easily adapted to

	other models, such as Double DS KSK Rollover or Double	other models, such as Double-DS KSK rollover or Double-Signature ZSK
	Signature ZSK rollover, if desired. Key use timing should	rollover, if desired. Key-use timing should
	follow the recommendations outlined in <xref target="RFC6781"/>,	follow the recommendations outlined in <xref target="RFC6781" format="de
		fault"/>,
	but taking into account the additional operations needed by	but taking into account the additional operations needed by

	the multi signer models. For example, "time to propagate data	the multi-signer models. For example, "time to propagate data
	to all the authoritative servers" now includes the time to import	to all the authoritative servers" now includes the time to import
	the new ZSKs into each provider.	the new ZSKs into each provider.
	</t>	</t>

		<section anchor="krc-model1" numbered="true" toc="default">
	<section title="Model 1: Common KSK, Unique ZSK per provider"	<name>Model 1: Common KSK, Unique ZSK per Provider</name>
	anchor="krc-model1">	<ul spacing="normal">
	<t>	<li>
	<list style="symbols">	Key Signing Key Rollover: In this model, the two managed-DNS
	<t>
	Key Signing Key Rollover: In this model, the two managed DNS
	providers share a common KSK (public key) in their respective	providers share a common KSK (public key) in their respective

	zones, and the zone owner controls the KSK signing key. To	zones, and the zone owner has sole access to the private key portion o f the KSK. To
	initiate the rollover, the zone owner generates a new KSK and obtains	initiate the rollover, the zone owner generates a new KSK and obtains
	the DNSKEY RRset of each DNS provider using their respective APIs.	the DNSKEY RRset of each DNS provider using their respective APIs.

	The new KSK is added to each provider's DNSKEY RRset and the RRset	The new KSK is added to each provider's DNSKEY RRset, and the RRset
	is re-signed with both the new and the old KSK. This new DNSKEY RRset	is re-signed with both the new and the old KSK. This new DNSKEY RRset
	is then transferred to each provider. The zone owner then updates	is then transferred to each provider. The zone owner then updates

	the DS RRset in the parent zone to point to the new KSK, and after	the DS RRset in the parent zone to point to the new KSK and, after
	the necessary DS record TTL period has expired, proceeds with	the necessary DS record TTL period has expired, proceeds with
	updating the DNSKEY RRset to remove the old KSK.	updating the DNSKEY RRset to remove the old KSK.

	</t>	</li>
	<t>	<li>
	Zone Signing Key Rollover: In this model, each DNS provider has	Zone Signing Key Rollover: In this model, each DNS provider has
	separate Zone Signing Keys. Each provider can choose to roll their	separate Zone Signing Keys. Each provider can choose to roll their

	ZSK independently by co-ordinating with the zone owner. Provider A	ZSK independently by coordinating with the zone owner. Provider A
	would generate a new ZSK and communicate their intent to perform a	would generate a new ZSK and communicate their intent to perform a
	rollover (note that Provider A cannot immediately insert this new	rollover (note that Provider A cannot immediately insert this new

	ZSK into their DNSKEY RRset because the RRset has to be signed by	ZSK into their DNSKEY RRset, because the RRset has to be signed by
	the zone owner). The zone owner obtains the new ZSK from	the zone owner). The zone owner obtains the new ZSK from
	Provider A. It then obtains the current DNSKEY RRset from each	Provider A. It then obtains the current DNSKEY RRset from each
	provider (including Provider A), inserts the new ZSK into each DNSKEY	provider (including Provider A), inserts the new ZSK into each DNSKEY
	RRset, re-signs the DNSKEY RRset, and sends it back to each provider	RRset, re-signs the DNSKEY RRset, and sends it back to each provider

	for deployment via their respective key management APIs. Once the	for deployment via their respective key-management APIs. Once the
	necessary time period is elapsed (i.e. all zone data has been	necessary time period has elapsed (i.e., all zone data has been
	re-signed by the new ZSK and propagated to all authoritative servers	re-signed by the new ZSK and propagated to all authoritative servers

	for the zone, plus the maximum zone TTL value of any of the data in	for the zone, plus the maximum zone-TTL value of any of the data in
	the zone signed by the old ZSK), Provider A and the zone owner can	the zone that has been signed by the old ZSK), Provider A and the
	initiate the next phase of removing the old ZSK, and re-signing the	zone owner can initiate the next phase of removing the old ZSK and
	resulting new DNSKEY RRset.	re-signing the resulting new DNSKEY RRset.
	</t>	</li>
	</list>	</ul>
	</t>
	</section>	</section>

		<section anchor="krc-model2" numbered="true" toc="default">
	<section title="Model 2: Unique KSK and ZSK per provider"	<name>Model 2: Unique KSK and ZSK per Provider</name>
	anchor="krc-model2">	<ul spacing="normal">
	<t>	<li>
	<list style="symbols">	Key Signing Key Rollover: In Model 2, each managed-DNS provider
	<t>	has their own KSK. A KSK roll for Provider A does not require any
	Key Signing Key Rollover: In Model 2, each managed DNS provider	change in the DNSKEY RRset of Provider B but does require
	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-ordination with the zone owner in order to get the DS record	co-ordination with the zone owner in order to get the DS record
	set in the parent zone updated. The KSK roll starts with Provider	set in the parent zone updated. The KSK roll starts with Provider
	A generating a new KSK and including it in their DNSKEY RRSet.	A 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.	The 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 zone	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 old KSK	owner updates the DS RRset to replace the DS record for the old KSK
	with a DS record for the new KSK. After the necessary DS RRset TTL	with a DS record for the new KSK. After the necessary DS RRset TTL

	period has elapsed, the old KSK can be removed from provider A's	period has elapsed, the old KSK can be removed from Provider A's
	DNSKEY RRset.	DNSKEY RRset.

	</t>	</li>
	<t>	<li>
	Zone Signing Key Rollover: In Model 2, each managed DNS provider	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 a new ZSK, 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 would
	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. Before
	necessary Pre-Publish key rollover time periods have elapsed,	signing zone data with the new ZSK, Provider A should wait
	provider A and the zone owner can initiate the process of removing	for the DNSKEY TTL plus the time to import the ZSK into
	the old ZSK from the DNSKEY RRset of all providers.	Provider B, plus the time to propagate the DNSKEY RRset to
	</t>	all authoritative servers of both providers. Once the
	</list>	necessary Pre-Publish key-rollover time periods have elapsed,
	</t>	Provider A and the zone owner can initiate the process of removing
		the old ZSK from the DNSKEY RRsets of all providers.
		</li>
		</ul>
	</section>	</section>
	</section>	</section>

		<section anchor="CSK" numbered="true" toc="default">
	<section anchor="CSK" title="Using Combined Signing Keys">	<name>Using Combined Signing Keys</name>
	<t>	<t>
	A Combined Signing Key (CSK) is one in which the same key serves the	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,	purposes of both being the secure entry point (SEP) key for the zone
	and also for signing all the zone data including the DNSKEY RRset	and signing all the zone data, including the DNSKEY RRset
	(i.e., there is no KSK/ZSK split).	(i.e., there is no KSK/ZSK split).
	</t>	</t>
	<t>	<t>
	Model 1 is not compatible with CSKs because the zone owner would then	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	hold the sole signing key, and providers would not be able to sign
	their own zone data.	their own zone data.
	</t>	</t>
	<t>	<t>
	Model 2 can accommodate CSKs without issue. In this case, any or all	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	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	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	CSK would 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	providers. A CSK key rollover for such a provider would involve the
	following: The provider generates a new CSK, installs the new CSK	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.	into the DNSKEY RRset, and signs it with both the old and new CSKs.
	The new CSK is communicated to the zone owner. The zone owner exports	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	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	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 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	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	latter is re-signed with only the new CSK. Finally, the old CSK is
	removed from the DNSKEY RRsets of the other providers.	removed from the DNSKEY RRsets of the other providers.
	</t>	</t>
	</section>	</section>

		<section anchor="CDS-CDNSKEY" numbered="true" toc="default">
	<section anchor="CDS-CDNSKEY" title="Use of CDS and CDNSKEY">	<name>Use of CDS and CDNSKEY</name>
	<t>	<t>

	CDS and CDNSKEY records <xref target="RFC7344" />	CDS and CDNSKEY records <xref target="RFC7344" format="default"/><xref
	<xref target="RFC8078" />	target="RFC8078" format="default"/>
	are used to facilitate automated updates	are used to facilitate automated updates

	of DNSSEC secure entry point keys between parent and child	of DNSSEC secure-entry-point keys between parent and child
	zones. Multi-signer DNSSEC configurations can support this too.	zones. Multi-signer DNSSEC configurations can support this, too.
	In Model 1, CDS/CDNSKEY changes are centralized at the zone owner.	In Model 1, CDS/CDNSKEY changes are centralized at the zone owner.
	However, the zone owner will still need to push down updated	However, the zone owner will still need to push down updated

	signed CDNS/DNSKEY RRsets to the providers via the key management	signed CDNS/DNSKEY RRsets to the providers via the key-management
	mechanism. In Model 2, the key management mechanism needs to	mechanism. In Model 2, the key-management mechanism needs to
	support cross importation of the CDS/CDNSKEY records, so that a	support cross-importation of the CDS/CDNSKEY records, so that a
	common view of the RRset can be constructed at each provider, and	common view of the RRset can be constructed at each provider and
	is visible to the parent zone attempting to update the DS RRset.	is visible to the parent zone attempting to update the DS RRset.
	</t>	</t>
	</section>	</section>

		<section anchor="Key-Management" numbered="true" toc="default">
	<section anchor="Key-Management" title="Key Management Mechanism Requirement	<name>Key-Management-Mechanism Requirements</name>
	s">
	<t>	<t>

	Managed DNS providers typically have their own proprietary zone	Managed-DNS providers typically have their own proprietary zone
	configuration and data management APIs, commonly utilizing	configuration and data-management APIs, commonly utilizing
	HTTPS/REST interfaces. So, rather than outlining a new API for	HTTPS and Representational State Transfer (REST) interfaces. So, rather
		than outlining a new API for
	key management here, we describe the specific functions that the	key management here, we describe the specific functions that the
	provider API needs to support in order to enable the multi-signer	provider API needs to support in order to enable the multi-signer
	models. The zone owner is expected to use these API functions to	models. The zone owner is expected to use these API functions to

	perform key management tasks. Other mechanisms that can partly	perform key-management tasks. Other mechanisms that can partly
	offer these functions, if supported by the providers, include the	offer these functions, if supported by the providers, include the

	<xref target="RFC2136">DNS UPDATE protocol</xref> and	<xref target="RFC2136" format="default">DNS UPDATE protocol</xref> and
	<xref target="RFC5731">EPP</xref>.	<xref target="RFC5731" format="default">Extensible Provisioning
		Protocol (EPP)</xref>.
	</t>	</t>

	<t>	<ul spacing="normal">
	<list style="symbols">	<li>The API must offer a way to query the current DNSKEY RRset
	<t>The API must offer a way to query the current DNSKEY RRset	of the provider.</li>
	of the provider</t>	<li>For Model 1, the API must offer a way to import a signed
	<t>For model 1, the API must offer a way to import a signed
	DNSKEY RRset and replace the current one at the provider.	DNSKEY RRset and replace the current one at the provider.
	Additionally, if CDS/CDNSKEY is supported, the API must also	Additionally, if CDS/CDNSKEY is supported, the API must also

	offer a way to import a signed CDS/CDNSKEY RRset.</t>	offer a way to import a signed CDS/CDNSKEY RRset.</li>
	<t>For model 2, the API must offer a way to import a DNSKEY	<li>For Model 2, the API must offer a way to import a DNSKEY
	record from an external provider into the current DNSKEY	record from an external provider into the current DNSKEY
	RRset. Additionally, if CDS/CDNSKEY is supported, the	RRset. Additionally, if CDS/CDNSKEY is supported, the
	API must offer a mechanism to import individual CDS/CDNSKEY	API must offer a mechanism to import individual CDS/CDNSKEY

	records from an external provider.</t>	records from an external provider.</li>
	</list>	</ul>
	</t>
	<t>	<t>

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

	as key rollover events happen.	as key-rollover events happen.
	</t>	</t>
	</section>	</section>

		<section anchor="Response-Size" numbered="true" toc="default">
	<section anchor="Response-Size" title="DNS Response Size Considerations">	<name>DNS Response-Size Considerations</name>
	<t>	<t>

	The Multi-Signer models result in larger DNSKEY RRsets, so the size	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	of a response to a query for the DNSKEY RRset will be larger. The
	actual size increase depends on multiple factors: DNSKEY algorithm	actual size increase depends on multiple factors: DNSKEY algorithm
	and keysize choices, the number of providers, whether additional keys	and keysize choices, the number of providers, whether additional keys

	are pre-published, how many simultaneous key rollovers are in progress	are prepublished, how many simultaneous key rollovers are in progress,
	etc. Newer elliptic curve algorithms produce keys small enough that the	etc. Newer elliptic-curve algorithms produce keys small enough that the
	responses will typically be far below the common Internet path MTU.	responses will typically be far below the common Internet-path MTU.
	Thus operational concerns related to IP fragmentation or truncation	Thus, operational concerns related to IP fragmentation or truncation
	and TCP fallback are unlikely to be encountered. In any case, DNS	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	operators need to ensure that they can emit and process large DNS UDP
	responses when necessary, and a future migration to alternative	responses when necessary, and a future migration to alternative

	transports like <xref target="RFC7858">DNS over TLS</xref> or	transports like <xref target="RFC7858" format="default">DNS over TLS</xr
	<xref target="RFC8484">DNS over HTTPS</xref> may make this topic moot.	ef> or
		<xref target="RFC8484" format="default">DNS over HTTPS</xref> may make t
		his topic moot.
	</t>	</t>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>This document includes no request to IANA.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>

	The Multi Signer models necessarily involve 3rd party providers	The multi-signer models necessarily involve third-party providers
	holding the private keys that sign the zone owner's data. Obviously	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	this means that the zone owner has decided to place a great deal
	of trust in these providers. By contrast, the more traditional	of trust in these providers. By contrast, the more traditional

	model in which the zone owner runs a hidden master and uses the zone	model in which the zone owner runs a hidden master and uses the
	transfer protocol with the providers, is arguably more secure, because	zone-transfer protocol with the providers is arguably more secure,
	only the zone owner holds the private signing keys, and the 3rd party	because
		only the zone owner holds the private signing keys, and the third-party
	providers cannot serve bogus data without detection by validating	providers cannot serve bogus data without detection by validating
	resolvers.	resolvers.
	</t>	</t>
	<t>	<t>

	The Zone key import and export APIs required by these models	The zone-key import and export APIs required by these models
	need to be strongly authenticated to prevent tampering of key	need to be strongly authenticated to prevent tampering of key
	material by malicious third parties. Many providers today	material by malicious third parties. Many providers today

	offer REST/HTTPS APIs, where the HTTPS layer provides transport	offer REST/HTTPS APIs that utilize a number of
	security and server authentication, and that utilize a number of	client-authentication mechanisms (username/password, API keys etc) and
	client authentication mechanisms (username/password, API keys etc).	whose HTTPS layer provides transport
		security and server authentication. Multifactor
		authentication could be used to further strengthen security.
	If DNS protocol mechanisms like UPDATE are being used for key	If DNS protocol mechanisms like UPDATE are being used for key
	insertion and deletion, they should similarly be strongly	insertion and deletion, they should similarly be strongly

	authenticated, e.g. by employing <xref target="RFC2845">	authenticated -- e.g., by employing <xref target="RFC2845" format="defau
	Transaction Signatures (TSIG)</xref>. Multi-factor	lt">
	authentication could be used to further strengthen security.	Transaction Signatures (TSIG)</xref>.
	Key Generation and other general security related operations	Key generation and other general security-related operations
	should follow the guidance specified in <xref target="RFC6781"/>.	should follow the guidance specified in <xref target="RFC6781" format="d
	</t>	efault"/>.

	</section>

	<section title="Acknowledgments">
	<t>
	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.
	</t>	</t>
	</section>	</section>


	</middle>	</middle>


	<!-- ***BACK MATTER *** -->

	<back>	<back>

	<references title="Normative References">
	&RFC1034;
	&RFC1035;
	&RFC2845;
	&RFC4033;
	&RFC4034;
	&RFC4035;
	&RFC5155;
	&RFC6781;
	&RFC7344;
	&RFC8078;
	&RFC8198;
	</references>


	<references title="Informative References">	<displayreference target="I-D.valsorda-dnsop-black-lies" to="BLACKLIES"/>
	&RFC1995;
	&RFC2136;	<references>
	&RFC5731;	<name>References</name>
	&RFC5936;	<references>
	&RFC7129;	<name>Normative References</name>
	&RFC7858;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	&RFC8484;	FC.1034.xml"/>
	&RFC8499;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<reference anchor="BLACKLIES"	FC.1035.xml"/>
	target="https://tools.ietf.org/html/draft-valsorda-dnsop-black-	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	lies">	FC.2845.xml"/>
	<front>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>Compact DNSSEC Denial of Existence or Black Lies</title>	FC.4033.xml"/>
	<author fullname="Filippo Valsorda" initials="F" surname="Valsorda" />	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsso	FC.4034.xml"/>
	n" />	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date />	FC.4035.xml"/>
	</front>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>	FC.5155.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6781.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7344.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8078.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8198.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.1995.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2136.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5731.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5936.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7129.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7858.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8484.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8499.xml"/>

		<!-- [BLACKLIES] I-D.valsorda-dnsop-black-lies; IESG state Expired -->

		<xi:include
		href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.valsorda-dnsop-b
		lack-lies.xml"/>

		</references>
	</references>	</references>

		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>
		The initial version of this document benefited from discussions
		with and review from <contact fullname="Duane Wessels"/>. Additional hel
		pful comments
		were provided by <contact fullname="Steve Crocker"/>, <contact
		fullname="Ulrich Wisser"/>, <contact fullname="Tony Finch"/>, <contact
		fullname="Olafur Gudmundsson"/>, <contact fullname="Matthijs
		Mekking"/>, <contact fullname="Daniel Migault"/>, and <contact fullname="
		Ben Kaduk"/>.
		</t>
		</section>
	</back>	</back>


	</rfc>	</rfc>

End of changes. 149 change blocks.
	436 lines changed or deleted	401 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/