File: rfc8901.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2141 lines) | stat: -rw-r--r-- 91,525 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8901: Multi-Signer DNSSEC Models</title>
<meta content="Shumon Huque" name="author">
<meta content="Pallavi Aras" name="author">
<meta content="John Dickinson" name="author">
<meta content="Jan Vcelak" name="author">
<meta content="David Blacka" name="author">
<meta content="
       
        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.
       
    " name="description">
<meta content="xml2rfc 3.1.1" name="generator">
<meta content="DNSSEC" name="keyword">
<meta content="Multiple" name="keyword">
<meta content="Provider" name="keyword">
<meta content="Signer" name="keyword">
<meta content="Models" name="keyword">
<meta content="8901" name="rfc.number">
<link href="rfc8901.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8901" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec-05" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8901</td>
<td class="center">Multi-Signer DNSSEC Models</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Huque, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8901" class="eref">8901</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Huque</div>
<div class="org">Salesforce</div>
</div>
<div class="author">
      <div class="author-name">P. Aras</div>
<div class="org">Salesforce</div>
</div>
<div class="author">
      <div class="author-name">J. Dickinson</div>
<div class="org">Sinodun IT</div>
</div>
<div class="author">
      <div class="author-name">J. Vcelak</div>
<div class="org">NS1</div>
</div>
<div class="author">
      <div class="author-name">D. Blacka</div>
<div class="org">Verisign</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8901</h1>
<h1 id="title">Multi-Signer DNSSEC Models</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8901">https://www.rfc-editor.org/info/rfc8901</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction-and-motivation" class="xref">Introduction and Motivation</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-deployment-models" class="xref">Deployment Models</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-multiple-signer-models" class="xref">Multiple-Signer Models</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.1">
                    <p id="section-toc.1-1.2.2.1.2.1.1" class="keepWithNext"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-model-1-common-ksk-set-uniq" class="xref">Model 1: Common KSK Set, Unique ZSK Set per Provider</a><a href="#section-toc.1-1.2.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact ulEmpty toc" id="section-toc.1-1.2.2.1.2.2">
                    <p id="section-toc.1-1.2.2.1.2.2.1" class="keepWithNext"><a href="#section-2.1.2" class="xref">2.1.2</a>.  <a href="#name-model-2-unique-ksk-set-and-" class="xref">Model 2: Unique KSK Set and ZSK Set per Provider</a><a href="#section-toc.1-1.2.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-validating-resolver-behavio" class="xref">Validating Resolver Behavior</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-signing-algorithm-considera" class="xref">Signing-Algorithm Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-authenticated-denial-consid" class="xref">Authenticated-Denial Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-single-method" class="xref">Single Method</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-mixing-methods" class="xref">Mixing Methods</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-key-rollover-considerations" class="xref">Key Rollover Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-model-1-common-ksk-unique-z" class="xref">Model 1: Common KSK, Unique ZSK per Provider</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-model-2-unique-ksk-and-zsk-" class="xref">Model 2: Unique KSK and ZSK per Provider</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-using-combined-signing-keys" class="xref">Using Combined Signing Keys</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-use-of-cds-and-cdnskey" class="xref">Use of CDS and CDNSKEY</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-key-management-mechanism-re" class="xref">Key-Management-Mechanism Requirements</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-dns-response-size-considera" class="xref">DNS Response-Size Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.13.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.13.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction-and-motivation">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction-and-motivation" class="section-name selfRef">Introduction and Motivation</a>
      </h2>
<p id="section-1-1">
        Many enterprises today employ the service of multiple Domain Name
        System (DNS) <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>
        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
        <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>: 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
        <span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span> <span>[<a href="#RFC4034" class="xref">RFC4034</a>]</span> <span>[<a href="#RFC4035" class="xref">RFC4035</a>]</span> deployment
 in such an environment.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        This document assumes a reasonable level of familiarity with
        DNS operations and protocol terms. Much of the terminology
        is explained in further detail in <span><a href="#RFC8499" class="xref">"DNS Terminology"</a> [<a href="#RFC8499" class="xref">RFC8499</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
</section>
<div id="models">
<section id="section-2">
      <h2 id="name-deployment-models">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-deployment-models" class="section-name selfRef">Deployment Models</a>
      </h2>
<p id="section-2-1">
        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.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
        Occasionally, however, standard zone-transfer techniques
        cannot be used.  This could be due to the use of nonstandard
        DNS features or the 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.<a href="#section-2-2" class="pilcrow">¶</a></p>
<div id="multi-sign">
<section id="section-2.1">
        <h3 id="name-multiple-signer-models">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-multiple-signer-models" class="section-name selfRef">Multiple-Signer Models</a>
        </h3>
<p id="section-2.1-1">
        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.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">
        These models can support DNSSEC even for the nonstandard
        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 precompute all the possible
        response sets and associated signatures and then algorithmically
        determine at query time which response set and signature need
        to be returned.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">
        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.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">
        In the descriptions below, the Key Signing Key (KSK) and Zone
        Signing Key (ZSK) correspond to the definitions in
        <span>[<a href="#RFC8499" class="xref">RFC8499</a>]</span>, 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.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<div id="model1">
<section id="section-2.1.1">
          <h4 id="name-model-1-common-ksk-set-uniq">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-model-1-common-ksk-set-uniq" class="section-name selfRef">Model 1: Common KSK Set, Unique ZSK Set per Provider</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-2.1.1-1.1">The zone owner holds the KSK set, manages the DS record set,
           and is responsible for signing the DNSKEY RRset and distributing
           it to the providers.<a href="#section-2.1.1-1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-1.2">Each provider has their own ZSK set, which is used to sign data
           in the zone.<a href="#section-2.1.1-1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-1.3">The providers have an API that the zone owner uses to query the ZSK
           public keys and insert a combined DNSKEY RRset that includes
           the ZSK sets of each provider and the KSK set, signed by the KSK.<a href="#section-2.1.1-1.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-1.4">Note that even if the contents of the DNSKEY RRset do not change,
           the zone owner needs to periodically re-sign it as signature
           expiration approaches. The provider API is also used
           to thus periodically redistribute the refreshed DNSKEY RRset.<a href="#section-2.1.1-1.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-1.5">Key rollovers need coordinated participation of the zone
           owner to update the DNSKEY RRset (for KSK or ZSK) and the
           DS RRset (for KSK).<a href="#section-2.1.1-1.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-1.6">(One specific variant of this model that may be interesting is
           a configuration in which there is only a single provider. A
           possible use case for this is where the zone owner wants to
           outsource the signing and operation of their DNS zone to a single
           third-party provider but still control the KSK, so that they can
           authorize and/or revoke the use of specific zone signing keys.)<a href="#section-2.1.1-1.6" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="model2">
<section id="section-2.1.2">
          <h4 id="name-model-2-unique-ksk-set-and-">
<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-model-2-unique-ksk-set-and-" class="section-name selfRef">Model 2: Unique KSK Set and ZSK Set per Provider</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-2.1.2-1.1">Each provider has their own KSK and ZSK sets.<a href="#section-2.1.2-1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.2-1.2">Each provider offers an API that the zone owner uses to import
           the ZSK sets of the other providers into their DNSKEY RRset.<a href="#section-2.1.2-1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.2-1.3">The DNSKEY RRset is signed independently by each provider using
           their own KSK.<a href="#section-2.1.2-1.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.2-1.4">The zone owner manages the DS RRset located in the parent zone.
           This is comprised of DS records corresponding to the KSKs of
           each provider.<a href="#section-2.1.2-1.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.2-1.5">Key rollovers need coordinated participation of the zone
           owner to update the DS RRset (for KSK) and the DNSKEY
           RRset (for ZSK).<a href="#section-2.1.2-1.5" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="resolver">
<section id="section-3">
      <h2 id="name-validating-resolver-behavio">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-validating-resolver-behavio" class="section-name selfRef">Validating Resolver Behavior</a>
      </h2>
<p id="section-3-1">
        The central requirement for both of the <span><a href="#multi-sign" class="xref">multiple-signer models</a> (<a href="#multi-sign" class="xref">Section 2.1</a>)</span> is to ensure
        that the ZSKs from all providers are present in each
        provider's apex DNSKEY RRset and 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):<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">The validating resolver follows a referral (i.e., secure delegation)
        to the zone in question.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.2">It retrieves the zone's DNSKEY RRset from one of Provider
        A's nameservers, authenticates it against the parent DS RRset,
        and caches it.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.3">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.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.4">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.<a href="#section-3-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.5">The resolver will not accept this response. It may still
        be able to ultimately authenticate the name by querying other
        nameservers for the zone until it elicits a response from one
        of Provider A's nameservers. But it has incurred the penalty
        of additional round trips with other nameservers, with the
        corresponding latency and processing costs. The exact number
        of additional round trips depends on details of the resolver's
        nameserver-selection algorithm and the number of nameservers
        configured at Provider B.<a href="#section-3-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.6">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 it is
 possible that downstream clients of the resolver that originated the
        query timed out waiting for a response.<a href="#section-3-2.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">

        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.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
        Details of how the DNSKEY RRset itself is validated differ.
        In <span><a href="#model1" class="xref">Model 1</a> (<a href="#model1" class="xref">Section 2.1.1</a>)</span>, 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 <span><a href="#model2" class="xref">Model 2</a> (<a href="#model2" class="xref">Section 2.1.2</a>)</span>, 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.<a href="#section-3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="algorithms">
<section id="section-4">
      <h2 id="name-signing-algorithm-considera">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-signing-algorithm-considera" class="section-name selfRef">Signing-Algorithm Considerations</a>
      </h2>
<p id="section-4-1">
        DNS providers participating in multi-signer models need to use
        a common DNSSEC signing algorithm (or a common set of algorithms
        if several 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 <span>[<a href="#RFC4035" class="xref">RFC4035</a>], <a href="https://www.rfc-editor.org/rfc/rfc4035#section-2.2" class="relref">Section 2.2</a></span>. If providers
        employ distinct signing algorithms, then this requirement cannot
        be satisfied.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nsec">
<section id="section-5">
      <h2 id="name-authenticated-denial-consid">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-authenticated-denial-consid" class="section-name selfRef">Authenticated-Denial Considerations</a>
      </h2>
<p id="section-5-1">
        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 (<span><a href="https://www.rfc-editor.org/rfc/rfc4035#section-3.1.3" class="relref">Section 3.1.3</a> of [<a href="#RFC4035" class="xref">RFC4035</a>]</span>) or NSEC3
 (<span><a href="https://www.rfc-editor.org/rfc/rfc5155#section-7.2" class="relref">Section 7.2</a> of [<a href="#RFC5155" class="xref">RFC5155</a>]</span>) records
 that provide cryptographic proof of
        this nonexistence. The NSEC3 method enhances NSEC by
        providing opt-out for signing insecure delegations and also adds
        limited protection against zone-enumeration attacks.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        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.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
        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 precomputed NSEC3,
        <span><a href="#RFC7129" class="xref">NSEC3 white lies</a> [<a href="#RFC7129" class="xref">RFC7129</a>]</span>,
        <span><a href="#I-D.valsorda-dnsop-black-lies" class="xref">NSEC
 black lies</a> [<a href="#I-D.valsorda-dnsop-black-lies" class="xref">BLACKLIES</a>]</span>, 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.<a href="#section-5-3" class="pilcrow">¶</a></p>
<section id="section-5.1">
        <h3 id="name-single-method">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-single-method" class="section-name selfRef">Single Method</a>
        </h3>
<p id="section-5.1-1">
          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
          closest to current operational practice.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2">
        <h3 id="name-mixing-methods">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-mixing-methods" class="section-name selfRef">Mixing Methods</a>
        </h3>
<p id="section-5.2-1">
          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.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
          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 a higher number
          of queries. This aspect should be considered especially in the
          context of <span><a href="#RFC8198" class="xref">"Aggressive Use of DNSSEC-Validated
          Cache"</a> [<a href="#RFC8198" class="xref">RFC8198</a>]</span>.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
          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.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2-4">
          Note that NSEC3 configuration on all providers with
          different NSEC3PARAM values is considered a mixed setup.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="keyrollover">
<section id="section-6">
      <h2 id="name-key-rollover-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-key-rollover-considerations" class="section-name selfRef">Key Rollover Considerations</a>
      </h2>
<p id="section-6-1">
        The <span><a href="#multi-sign" class="xref">multiple-signer</a> (<a href="#multi-sign" class="xref">Section 2.1</a>)</span> 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.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
        For simplicity, the descriptions in this section assume two DNS
 providers. 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 <span>[<a href="#RFC6781" class="xref">RFC6781</a>]</span>.
        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 <span>[<a href="#RFC6781" class="xref">RFC6781</a>]</span>,
        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.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="krc-model1">
<section id="section-6.1">
        <h3 id="name-model-1-common-ksk-unique-z">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-model-1-common-ksk-unique-z" class="section-name selfRef">Model 1: Common KSK, Unique ZSK per Provider</a>
        </h3>
<ul class="normal">
<li class="normal" id="section-6.1-1.1">
          Key Signing Key Rollover: In this model, the two managed-DNS
          providers share a common KSK (public key) in their respective
          zones, and the zone owner has sole access to the private key portion of the KSK. To
          initiate the rollover, the zone owner generates a new KSK and obtains
          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
          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
          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
          updating the DNSKEY RRset to remove the old KSK.<a href="#section-6.1-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-1.2">
          Zone Signing Key Rollover: In this model, each DNS provider has
          separate Zone Signing Keys. Each provider can choose to roll their
          ZSK independently by coordinating with the zone owner. Provider A
          would generate a new ZSK and communicate their intent to perform a
          rollover (note that Provider A cannot immediately insert this new
          ZSK into their DNSKEY RRset, because the RRset has to be signed by
          the zone owner). The zone owner obtains the new ZSK from
          Provider A. It then obtains the current DNSKEY RRset from each
          provider (including Provider A), inserts the new ZSK into each DNSKEY
          RRset, re-signs the DNSKEY RRset, and sends it back to each provider
          for deployment via their respective key-management APIs. Once the
          necessary time period has elapsed (i.e., all zone data has been
          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
          the zone that has been signed by the old ZSK), Provider A and the
          zone owner can initiate the next phase of removing the old ZSK and
          re-signing the resulting new DNSKEY RRset.<a href="#section-6.1-1.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="krc-model2">
<section id="section-6.2">
        <h3 id="name-model-2-unique-ksk-and-zsk-">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-model-2-unique-ksk-and-zsk-" class="section-name selfRef">Model 2: Unique KSK and ZSK per Provider</a>
        </h3>
<ul class="normal">
<li class="normal" id="section-6.2-1.1">
          Key Signing Key Rollover: In Model 2, each managed-DNS provider
          has their own KSK. A KSK roll for Provider A does not require any
          change in the DNSKEY RRset of Provider B but does require
          co-ordination with the zone owner in order to get the DS record
          set in the parent zone updated. The KSK roll starts with Provider
          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 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
          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
          DNSKEY RRset.<a href="#section-6.2-1.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-1.2">
          Zone Signing Key Rollover: In Model 2, each managed-DNS provider
          has their own ZSK. The ZSK roll for Provider A would start with
          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
          Provider A would then be communicated to the zone owner, who would
          initiate the process of importing this ZSK into the DNSKEY RRsets
          of the other providers, using their respective APIs. Before
   signing zone data with the new ZSK, Provider A should wait
   for the DNSKEY TTL plus the time to import the ZSK into
   Provider B, plus the time to propagate the DNSKEY RRset to
   all authoritative servers of both providers.  Once the
          necessary Pre-Publish key-rollover time periods have elapsed,
          Provider A and the zone owner can initiate the process of removing
          the old ZSK from the DNSKEY RRsets of all providers.<a href="#section-6.2-1.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="CSK">
<section id="section-7">
      <h2 id="name-using-combined-signing-keys">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-using-combined-signing-keys" class="section-name selfRef">Using Combined Signing Keys</a>
      </h2>
<p id="section-7-1">
        A Combined Signing Key (CSK) is one in which the same key serves the
        purposes of both being the secure entry point (SEP) key for the zone
        and signing all the zone data, including the DNSKEY RRset
        (i.e., there is no KSK/ZSK split).<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
        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.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        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 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
        following: The provider generates a new CSK, installs the 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
        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.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="CDS-CDNSKEY">
<section id="section-8">
      <h2 id="name-use-of-cds-and-cdnskey">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-use-of-cds-and-cdnskey" class="section-name selfRef">Use of CDS and CDNSKEY</a>
      </h2>
<p id="section-8-1">
        CDS and CDNSKEY records <span>[<a href="#RFC7344" class="xref">RFC7344</a>]</span><span>[<a href="#RFC8078" class="xref">RFC8078</a>]</span>
        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.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Key-Management">
<section id="section-9">
      <h2 id="name-key-management-mechanism-re">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-key-management-mechanism-re" class="section-name selfRef">Key-Management-Mechanism Requirements</a>
      </h2>
<p id="section-9-1">
        Managed-DNS providers typically have their own proprietary zone
        configuration and data-management APIs, commonly utilizing
        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
        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
        <span><a href="#RFC2136" class="xref">DNS UPDATE protocol</a> [<a href="#RFC2136" class="xref">RFC2136</a>]</span> and
        <span><a href="#RFC5731" class="xref">Extensible Provisioning
 Protocol (EPP)</a> [<a href="#RFC5731" class="xref">RFC5731</a>]</span>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-2.1">The API must offer a way to query the current DNSKEY RRset
           of the provider.<a href="#section-9-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-2.2">For Model 1, the API must offer a way to import a signed
           DNSKEY RRset and replace the current one at the provider.
           Additionally, if CDS/CDNSKEY is supported, the API must also
           offer a way to import a signed CDS/CDNSKEY RRset.<a href="#section-9-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-2.3">For Model 2, the API must offer a way to import a DNSKEY
           record from an external provider into the current DNSKEY
           RRset. Additionally, if CDS/CDNSKEY is supported, the
           API must offer a mechanism to import individual CDS/CDNSKEY
           records from an external provider.<a href="#section-9-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-9-3">
        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.<a href="#section-9-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Response-Size">
<section id="section-10">
      <h2 id="name-dns-response-size-considera">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-dns-response-size-considera" class="section-name selfRef">DNS Response-Size Considerations</a>
      </h2>
<p id="section-10-1">
        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 prepublished, 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 <span><a href="#RFC7858" class="xref">DNS over TLS</a> [<a href="#RFC7858" class="xref">RFC7858</a>]</span> or
        <span><a href="#RFC8484" class="xref">DNS over HTTPS</a> [<a href="#RFC8484" class="xref">RFC8484</a>]</span> may make this topic moot.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">This document has no IANA actions.<a href="#section-11-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-12">
      <h2 id="name-security-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-12-1">
        The multi-signer models necessarily involve third-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 third-party
        providers cannot serve bogus data without detection by validating
        resolvers.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">
 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 that utilize a number of
        client-authentication mechanisms (username/password, API keys etc) and
 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
        insertion and deletion, they should similarly be strongly
        authenticated -- e.g., by employing <span><a href="#RFC2845" class="xref">Transaction Signatures (TSIG)</a> [<a href="#RFC2845" class="xref">RFC2845</a>]</span>.
        Key generation and other general security-related operations
        should follow the guidance specified in <span>[<a href="#RFC6781" class="xref">RFC6781</a>]</span>.<a href="#section-12-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1034">[RFC1034]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - concepts and facilities"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1034</span>, <span class="seriesInfo">DOI 10.17487/RFC1034</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1035">[RFC1035]</dt>
        <dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2845">[RFC2845]</dt>
        <dd>
<span class="refAuthor">Vixie, P.</span><span class="refAuthor">, Gudmundsson, O.</span><span class="refAuthor">, Eastlake 3rd, D.</span><span class="refAuthor">, and B. Wellington</span>, <span class="refTitle">"Secret Key Transaction Authentication for DNS (TSIG)"</span>, <span class="seriesInfo">RFC 2845</span>, <span class="seriesInfo">DOI 10.17487/RFC2845</span>, <time datetime="2000-05" class="refDate">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2845">https://www.rfc-editor.org/info/rfc2845</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4033">[RFC4033]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"DNS Security Introduction and Requirements"</span>, <span class="seriesInfo">RFC 4033</span>, <span class="seriesInfo">DOI 10.17487/RFC4033</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4034">[RFC4034]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Resource Records for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4034</span>, <span class="seriesInfo">DOI 10.17487/RFC4034</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4034">https://www.rfc-editor.org/info/rfc4034</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4035">[RFC4035]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Protocol Modifications for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4035</span>, <span class="seriesInfo">DOI 10.17487/RFC4035</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4035">https://www.rfc-editor.org/info/rfc4035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5155">[RFC5155]</dt>
        <dd>
<span class="refAuthor">Laurie, B.</span><span class="refAuthor">, Sisson, G.</span><span class="refAuthor">, Arends, R.</span><span class="refAuthor">, and D. Blacka</span>, <span class="refTitle">"DNS Security (DNSSEC) Hashed Authenticated Denial of Existence"</span>, <span class="seriesInfo">RFC 5155</span>, <span class="seriesInfo">DOI 10.17487/RFC5155</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5155">https://www.rfc-editor.org/info/rfc5155</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6781">[RFC6781]</dt>
        <dd>
<span class="refAuthor">Kolkman, O.</span><span class="refAuthor">, Mekking, W.</span><span class="refAuthor">, and R. Gieben</span>, <span class="refTitle">"DNSSEC Operational Practices, Version 2"</span>, <span class="seriesInfo">RFC 6781</span>, <span class="seriesInfo">DOI 10.17487/RFC6781</span>, <time datetime="2012-12" class="refDate">December 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6781">https://www.rfc-editor.org/info/rfc6781</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7344">[RFC7344]</dt>
        <dd>
<span class="refAuthor">Kumari, W.</span><span class="refAuthor">, Gudmundsson, O.</span><span class="refAuthor">, and G. Barwood</span>, <span class="refTitle">"Automating DNSSEC Delegation Trust Maintenance"</span>, <span class="seriesInfo">RFC 7344</span>, <span class="seriesInfo">DOI 10.17487/RFC7344</span>, <time datetime="2014-09" class="refDate">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7344">https://www.rfc-editor.org/info/rfc7344</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8078">[RFC8078]</dt>
        <dd>
<span class="refAuthor">Gudmundsson, O.</span><span class="refAuthor"> and P. Wouters</span>, <span class="refTitle">"Managing DS Records from the Parent via CDS/CDNSKEY"</span>, <span class="seriesInfo">RFC 8078</span>, <span class="seriesInfo">DOI 10.17487/RFC8078</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8078">https://www.rfc-editor.org/info/rfc8078</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8198">[RFC8198]</dt>
      <dd>
<span class="refAuthor">Fujiwara, K.</span><span class="refAuthor">, Kato, A.</span><span class="refAuthor">, and W. Kumari</span>, <span class="refTitle">"Aggressive Use of DNSSEC-Validated Cache"</span>, <span class="seriesInfo">RFC 8198</span>, <span class="seriesInfo">DOI 10.17487/RFC8198</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8198">https://www.rfc-editor.org/info/rfc8198</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.valsorda-dnsop-black-lies">[BLACKLIES]</dt>
        <dd>
<span class="refAuthor">Valsorda, F.</span><span class="refAuthor"> and O. Gudmundsson</span>, <span class="refTitle">"Compact DNSSEC Denial of Existence or Black Lies"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-valsorda-dnsop-black-lies-00</span>, <time datetime="2016-03-21" class="refDate">21 March 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00">https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1995">[RFC1995]</dt>
        <dd>
<span class="refAuthor">Ohta, M.</span>, <span class="refTitle">"Incremental Zone Transfer in DNS"</span>, <span class="seriesInfo">RFC 1995</span>, <span class="seriesInfo">DOI 10.17487/RFC1995</span>, <time datetime="1996-08" class="refDate">August 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1995">https://www.rfc-editor.org/info/rfc1995</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2136">[RFC2136]</dt>
        <dd>
<span class="refAuthor">Vixie, P., Ed.</span><span class="refAuthor">, Thomson, S.</span><span class="refAuthor">, Rekhter, Y.</span><span class="refAuthor">, and J. Bound</span>, <span class="refTitle">"Dynamic Updates in the Domain Name System (DNS UPDATE)"</span>, <span class="seriesInfo">RFC 2136</span>, <span class="seriesInfo">DOI 10.17487/RFC2136</span>, <time datetime="1997-04" class="refDate">April 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2136">https://www.rfc-editor.org/info/rfc2136</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5731">[RFC5731]</dt>
        <dd>
<span class="refAuthor">Hollenbeck, S.</span>, <span class="refTitle">"Extensible Provisioning Protocol (EPP) Domain Name Mapping"</span>, <span class="seriesInfo">STD 69</span>, <span class="seriesInfo">RFC 5731</span>, <span class="seriesInfo">DOI 10.17487/RFC5731</span>, <time datetime="2009-08" class="refDate">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5731">https://www.rfc-editor.org/info/rfc5731</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5936">[RFC5936]</dt>
        <dd>
<span class="refAuthor">Lewis, E.</span><span class="refAuthor"> and A. Hoenes, Ed.</span>, <span class="refTitle">"DNS Zone Transfer Protocol (AXFR)"</span>, <span class="seriesInfo">RFC 5936</span>, <span class="seriesInfo">DOI 10.17487/RFC5936</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5936">https://www.rfc-editor.org/info/rfc5936</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7129">[RFC7129]</dt>
        <dd>
<span class="refAuthor">Gieben, R.</span><span class="refAuthor"> and W. Mekking</span>, <span class="refTitle">"Authenticated Denial of Existence in the DNS"</span>, <span class="seriesInfo">RFC 7129</span>, <span class="seriesInfo">DOI 10.17487/RFC7129</span>, <time datetime="2014-02" class="refDate">February 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7129">https://www.rfc-editor.org/info/rfc7129</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7858">[RFC7858]</dt>
        <dd>
<span class="refAuthor">Hu, Z.</span><span class="refAuthor">, Zhu, L.</span><span class="refAuthor">, Heidemann, J.</span><span class="refAuthor">, Mankin, A.</span><span class="refAuthor">, Wessels, D.</span><span class="refAuthor">, and P. Hoffman</span>, <span class="refTitle">"Specification for DNS over Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 7858</span>, <span class="seriesInfo">DOI 10.17487/RFC7858</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7858">https://www.rfc-editor.org/info/rfc7858</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8484">[RFC8484]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span><span class="refAuthor"> and P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8499">[RFC8499]</dt>
      <dd>
<span class="refAuthor">Hoffman, P.</span><span class="refAuthor">, Sullivan, A.</span><span class="refAuthor">, and K. Fujiwara</span>, <span class="refTitle">"DNS Terminology"</span>, <span class="seriesInfo">BCP 219</span>, <span class="seriesInfo">RFC 8499</span>, <span class="seriesInfo">DOI 10.17487/RFC8499</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8499">https://www.rfc-editor.org/info/rfc8499</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">
        The initial version of this document benefited from discussions
        with and review from <span class="contact-name">Duane Wessels</span>. Additional helpful comments
        were provided by <span class="contact-name">Steve Crocker</span>, <span class="contact-name">Ulrich Wisser</span>, <span class="contact-name">Tony Finch</span>, <span class="contact-name">Olafur Gudmundsson</span>, <span class="contact-name">Matthijs  Mekking</span>, <span class="contact-name">Daniel Migault</span>, and <span class="contact-name">Ben Kaduk</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Shumon Huque</span></div>
<div dir="auto" class="left"><span class="org">Salesforce</span></div>
<div dir="auto" class="left"><span class="street-address">415 Mission Street, 3rd Floor</span></div>
<div dir="auto" class="left">
<span class="locality">San Francisco</span>, <span class="region">CA</span> <span class="postal-code">94105</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:shuque@gmail.com" class="email">shuque@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Pallavi Aras</span></div>
<div dir="auto" class="left"><span class="org">Salesforce</span></div>
<div dir="auto" class="left"><span class="street-address">415 Mission Street, 3rd Floor</span></div>
<div dir="auto" class="left">
<span class="locality">San Francisco</span>, <span class="region">CA</span> <span class="postal-code">94105</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:paras@salesforce.com" class="email">paras@salesforce.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">John Dickinson</span></div>
<div dir="auto" class="left"><span class="org">Sinodun IT</span></div>
<div dir="auto" class="left"><span class="street-address">Magdalen Centre<br>Oxford Science Park</span></div>
<div dir="auto" class="left"><span class="locality">Oxford</span></div>
<div dir="auto" class="left"><span class="postal-code">OX4 4GA</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jad@sinodun.com" class="email">jad@sinodun.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jan Vcelak</span></div>
<div dir="auto" class="left"><span class="org">NS1</span></div>
<div dir="auto" class="left"><span class="street-address">55 Broad Street, 19th Floor</span></div>
<div dir="auto" class="left">
<span class="locality">New York</span>, <span class="region">NY</span> <span class="postal-code">10004</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jvcelak@ns1.com" class="email">jvcelak@ns1.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Blacka</span></div>
<div dir="auto" class="left"><span class="org">Verisign</span></div>
<div dir="auto" class="left"><span class="street-address">12061 Bluemont Way</span></div>
<div dir="auto" class="left">
<span class="locality">Reston</span>, <span class="region">VA</span> <span class="postal-code">20190</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:davidb@verisign.com" class="email">davidb@verisign.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>