File: rfc9103.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: forky, sid, trixie
size: 1,609,944 kB
file content (3396 lines) | stat: -rw-r--r-- 179,367 bytes
<!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 9103: DNS Zone Transfer over TLS</title>
<meta content="Willem Toorop" name="author">
<meta content="Sara Dickinson" name="author">
<meta content="Shivan Sahib" name="author">
<meta content="Pallavi Aras" name="author">
<meta content="Allison Mankin" name="author">
<meta content="
       DNS zone transfers are transmitted in cleartext, which gives attackers the
  opportunity to collect the content of a zone by eavesdropping on network
  connections. The DNS Transaction Signature (TSIG) mechanism is specified to
  restrict direct zone transfer to authorized clients only, but it does not add
  confidentiality. This document specifies the use of TLS, rather than cleartext, 
  to prevent zone content collection via passive monitoring of zone
  transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995
  and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with
  respect to the recommended number of connections between a client and server
  for each transport. 
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="DNS" name="keyword">
<meta content="operations" name="keyword">
<meta content="privacy" name="keyword">
<meta content="9103" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9103.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9103" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls-12" 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 9103</td>
<td class="center">XFR over TLS</td>
<td class="right">August 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Toorop, et al.</td>
<td class="center">Standards Track</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/rfc9103" class="eref">9103</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc1995" class="eref">1995</a>, <a href="https://www.rfc-editor.org/rfc/rfc5936" class="eref">5936</a>, <a href="https://www.rfc-editor.org/rfc/rfc7766" class="eref">7766</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-08" class="published">August 2021</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">W. Toorop</div>
<div class="org">NLnet Labs</div>
</div>
<div class="author">
      <div class="author-name">S. Dickinson</div>
<div class="org">Sinodun IT</div>
</div>
<div class="author">
      <div class="author-name">S. Sahib</div>
<div class="org">Brave Software</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">A. Mankin</div>
<div class="org">Salesforce</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9103</h1>
<h1 id="title">DNS Zone Transfer over TLS</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">DNS zone transfers are transmitted in cleartext, which gives attackers the
  opportunity to collect the content of a zone by eavesdropping on network
  connections. The DNS Transaction Signature (TSIG) mechanism is specified to
  restrict direct zone transfer to authorized clients only, but it does not add
  confidentiality. This document specifies the use of TLS, rather than cleartext, 
  to prevent zone content collection via passive monitoring of zone
  transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995
  and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with
  respect to the recommended number of connections between a client and server
  for each transport.<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 is an Internet Standards Track document.<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).  Further
            information on Internet Standards is available in 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/rfc9103">https://www.rfc-editor.org/info/rfc9103</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) 2021 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 ulBare toc">
<li class="compact ulEmpty ulBare 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" class="xref">Introduction</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-threat-model" class="xref">Threat Model</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-design-considerations-for-x" class="xref">Design Considerations for XoT</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-connection-and-data-flows-i" class="xref">Connection and Data Flows in Existing XFR Mechanisms</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare 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-axfr-mechanism" class="xref">AXFR Mechanism</a></p>
</li>
              <li class="compact ulEmpty ulBare 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-ixfr-mechanism" class="xref">IXFR Mechanism</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-data-leakage-of-notify-and-" class="xref">Data Leakage of NOTIFY and SOA Message Exchanges</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.5.2.3.2.1">
                    <p id="section-toc.1-1.5.2.3.2.1.1"><a href="#section-5.3.1" class="xref">5.3.1</a>.  <a href="#name-notify" class="xref">NOTIFY</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.5.2.3.2.2">
                    <p id="section-toc.1-1.5.2.3.2.2.1"><a href="#section-5.3.2" class="xref">5.3.2</a>.  <a href="#name-soa" class="xref">SOA</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare 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-updates-to-existing-specifi" class="xref">Updates to Existing Specifications</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare 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-update-to-rfc-1995-for-ixfr" class="xref">Update to RFC 1995 for IXFR over TCP</a></p>
</li>
              <li class="compact ulEmpty ulBare 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-update-to-rfc-5936-for-axfr" class="xref">Update to RFC 5936 for AXFR over TCP</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-updates-to-rfcs-1995-and-59" class="xref">Updates to RFCs 1995 and 5936 for XFR over TCP</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3.2.1">
                    <p id="section-toc.1-1.6.2.3.2.1.1"><a href="#section-6.3.1" class="xref">6.3.1</a>.  <a href="#name-connection-reuse" class="xref">Connection Reuse</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3.2.2">
                    <p id="section-toc.1-1.6.2.3.2.2.1"><a href="#section-6.3.2" class="xref">6.3.2</a>.  <a href="#name-axfrs-and-ixfrs-on-the-same" class="xref">AXFRs and IXFRs on the Same Connection</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3.2.3">
                    <p id="section-toc.1-1.6.2.3.2.3.1"><a href="#section-6.3.3" class="xref">6.3.3</a>.  <a href="#name-xfr-limits" class="xref">XFR Limits</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3.2.4">
                    <p id="section-toc.1-1.6.2.3.2.4.1"><a href="#section-6.3.4" class="xref">6.3.4</a>.  <a href="#name-the-edns-tcp-keepalive-edns" class="xref">The edns-tcp-keepalive EDNS(0) Option</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.3.2.5">
                    <p id="section-toc.1-1.6.2.3.2.5.1"><a href="#section-6.3.5" class="xref">6.3.5</a>.  <a href="#name-backwards-compatibility" class="xref">Backwards Compatibility</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-update-to-rfc-7766" class="xref">Update to RFC 7766</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare 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-xot-specification" class="xref">XoT Specification</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-connection-establishment" class="xref">Connection Establishment</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-tls-versions" class="xref">TLS Versions</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-port-selection" class="xref">Port Selection</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-high-level-xot-descriptions" class="xref">High-Level XoT Descriptions</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-xot-transfers" class="xref">XoT Transfers</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-xot-connections" class="xref">XoT Connections</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-xot-vs-adot" class="xref">XoT vs. ADoT</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.8">
                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-response-rcodes" class="xref">Response RCODES</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.9">
                <p id="section-toc.1-1.7.2.9.1"><a href="#section-7.9" class="xref">7.9</a>.  <a href="#name-axot-specifics" class="xref">AXoT Specifics</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.9.2.1">
                    <p id="section-toc.1-1.7.2.9.2.1.1"><a href="#section-7.9.1" class="xref">7.9.1</a>.  <a href="#name-padding-axot-responses" class="xref">Padding AXoT Responses</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.10">
                <p id="section-toc.1-1.7.2.10.1"><a href="#section-7.10" class="xref">7.10</a>. <a href="#name-ixot-specifics" class="xref">IXoT Specifics</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.10.2.1">
                    <p id="section-toc.1-1.7.2.10.2.1.1"><a href="#section-7.10.1" class="xref">7.10.1</a>.  <a href="#name-condensation-of-responses" class="xref">Condensation of Responses</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.10.2.2">
                    <p id="section-toc.1-1.7.2.10.2.2.1"><a href="#section-7.10.2" class="xref">7.10.2</a>.  <a href="#name-fallback-to-axfr" class="xref">Fallback to AXFR</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.10.2.3">
                    <p id="section-toc.1-1.7.2.10.2.3.1"><a href="#section-7.10.3" class="xref">7.10.3</a>.  <a href="#name-padding-of-ixot-responses" class="xref">Padding of IXoT Responses</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7.2.11">
                <p id="section-toc.1-1.7.2.11.1"><a href="#section-7.11" class="xref">7.11</a>. <a href="#name-name-compression-and-maximu" class="xref">Name Compression and Maximum Payload Sizes</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare 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-multi-primary-configuration" class="xref">Multi-primary Configurations</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-authentication-mechanisms" class="xref">Authentication Mechanisms</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-tsig" class="xref">TSIG</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-sig0" class="xref">SIG(0)</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-tls" class="xref">TLS</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.3.2.1">
                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-opportunistic-tls" class="xref">Opportunistic TLS</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.3.2.2">
                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-strict-tls" class="xref">Strict TLS</a></p>
</li>
                  <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.3.2.3">
                    <p id="section-toc.1-1.9.2.3.2.3.1"><a href="#section-9.3.3" class="xref">9.3.3</a>.  <a href="#name-mutual-tls" class="xref">Mutual TLS</a></p>
</li>
                </ul>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-ip-based-acl-on-the-primary" class="xref">IP-Based ACL on the Primary</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9.2.5">
                <p id="section-toc.1-1.9.2.5.1"><a href="#section-9.5" class="xref">9.5</a>.  <a href="#name-zonemd" class="xref">ZONEMD</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare 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-xot-authentication" class="xref">XoT Authentication</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-policies-for-both-axot-and-" class="xref">Policies for Both AXoT and IXoT</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-implementation-consideratio" class="xref">Implementation Considerations</a></p>
</li>
          <li class="compact ulEmpty ulBare 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-operational-considerations" class="xref">Operational Considerations</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-16" class="xref">16</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.16.2.1">
                <p id="section-toc.1-1.16.2.1.1"><a href="#section-16.1" class="xref">16.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.16.2.2">
                <p id="section-toc.1-1.16.2.2.1"><a href="#section-16.2" class="xref">16.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-xot-server-connection-handl" class="xref">XoT Server Connection Handling</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17.2.1">
                <p id="section-toc.1-1.17.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-listening-only-on-a-specifi" class="xref">Listening Only on a Specific IP Address for TLS</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17.2.2">
                <p id="section-toc.1-1.17.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-client-specific-tls-accepta" class="xref">Client-Specific TLS Acceptance</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17.2.3">
                <p id="section-toc.1-1.17.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-sni-based-tls-acceptance" class="xref">SNI-Based TLS Acceptance</a></p>
</li>
              <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17.2.4">
                <p id="section-toc.1-1.17.2.4.1"><a href="#appendix-A.4" class="xref">A.4</a>.  <a href="#name-transport-specific-response" class="xref">Transport-Specific Response Policies</a></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.17.2.4.2.1">
                    <p id="section-toc.1-1.17.2.4.2.1.1"><a href="#appendix-A.4.1" class="xref">A.4.1</a>.  <a href="#name-sni-based-response-policies" class="xref">SNI-Based Response Policies</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.18">
            <p id="section-toc.1-1.18.1"><a href="#appendix-B" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.19">
            <p id="section-toc.1-1.19.1"><a href="#appendix-C" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.20">
            <p id="section-toc.1-1.20.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">DNS has a number of privacy vulnerabilities, as discussed in detail in
  <span>[<a href="#RFC9076" class="xref">RFC9076</a>]</span>. Query privacy between stub resolvers and recursive resolvers has received
  the most attention to date, with Standards Track documents for both DNS over TLS
  (DoT) <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span> and DNS over HTTPS (DoH) <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span>
  and a proposal for
  DNS over QUIC <span>[<a href="#I-D.ietf-dprive-dnsoquic" class="xref">DPRIVE-DNSOQUIC</a>]</span>. There is ongoing work on DNS
  privacy
  requirements for exchanges between recursive resolvers and authoritative
  servers and some suggestions for
  how signaling of DoT support by authoritative name servers might work. However, there is
  currently no RFC that specifically defines recursive-to-authoritative DNS over TLS
  (ADoT).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2"><span>[<a href="#RFC9076" class="xref">RFC9076</a>]</span> establishes that a stub resolver's DNS query
  transactions are not public and that they need protection, but, on zone transfer
  <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>, it says only:<a href="#section-1-2" class="pilcrow">¶</a></p>
<blockquote id="section-1-3">Privacy risks for the holder of a zone (the risk that someone
  gets the data) are discussed in <span>[<a href="#RFC5155" class="xref">RFC5155</a>]</span> and <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a>
</blockquote>
<p id="section-1-4">In what way is exposing the full contents of a zone a privacy risk? The
  contents of the zone could include information such as names of persons used in
  names of hosts. Best practice is not to use personal information for domain
  names, but many such domain names exist. The contents of the zone could also
  include references to locations that allow inference about location information
  of the individuals associated with the zone's organization. It could also
  include references to other organizations. Examples of this could be:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">Person-laptop.example.org<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">MX-for-Location.example.org<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.3">Service-tenant-from-another-org.example.org<a href="#section-1-5.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-6">Additionally, the full zone contents expose all the IP addresses of endpoints
  held in the DNS records, which can make reconnaissance and attack targeting easier,
  particularly
  for IPv6 addresses or private networks. There may also be regulatory, policy, or other
  reasons why the zone contents in full must be treated as private.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">Neither of the RFCs mentioned in <span>[<a href="#RFC9076" class="xref">RFC9076</a>]</span>
  contemplate the risk that someone gets the data through eavesdropping on
  network connections, only via enumeration or unauthorized transfer, as described
  in the following paragraphs.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">Zone enumeration is trivially possible for DNSSEC zones that use NSEC, i.e.,
  queries for the authenticated denial-of-existence records allow a client to
  walk through the entire zone contents. <span>[<a href="#RFC5155" class="xref">RFC5155</a>]</span> specifies NSEC3, a
  mechanism to provide measures against zone enumeration for DNSSEC-signed zones (a goal
  was to make it as hard to enumerate a DNSSEC-signed zone as an unsigned zone).
  Whilst this is widely used, it has been demonstrated that zone walking is
  possible for precomputed NSEC3 using attacks, such as those described in
  <span>[<a href="#NSEC3-attacks" class="xref">NSEC3-attacks</a>]</span>. This prompted further work on an alternative
  mechanism for DNSSEC-authenticated denial of existence (NSEC5
  <span>[<a href="#I-D.vcelak-nsec5" class="xref">NSEC5</a>]</span>); however, questions remain over the practicality of
  this mechanism.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9"><span>[<a href="#RFC5155" class="xref">RFC5155</a>]</span> does not address data obtained outside zone enumeration (nor
  does <span>[<a href="#I-D.vcelak-nsec5" class="xref">NSEC5</a>]</span>). Preventing eavesdropping of zone transfers (as
  described in this document) is orthogonal to preventing zone enumeration, though they aim to
  protect the same information.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10"><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> specifies using TSIG <span>[<a href="#RFC8945" class="xref">RFC8945</a>]</span> for
  authorization of the clients
  of a zone transfer and for data integrity but does not express any need for
  confidentiality, and TSIG does not offer encryption.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">Section 8 of the NIST document "Secure Domain Name System (DNS) Deployment Guide"
  <span>[<a href="#NIST-GUIDE" class="xref">NIST-GUIDE</a>]</span> discusses restricting access for zone transfers using
  Access Control Lists (ACLs) and
  TSIG in more detail. It also discusses the possibility that specific deployments
  might choose to use a lower-level network layer to protect zone transfers, e.g., IPsec.<a href="#section-1-11" class="pilcrow">¶</a></p>
<p id="section-1-12">It is noted that in all the common open-source implementations
  such ACLs are applied on a per-query basis (at the time of writing). Since requests
  typically occur on TCP connections, authoritative servers must therefore accept any TCP connection
  and then handle the authentication of each zone transfer (XFR) request individually.<a href="#section-1-12" class="pilcrow">¶</a></p>
<p id="section-1-13">Because both AXFR (authoritative transfer) and IXFR (incremental zone transfer) are
  typically carried out over TCP
  from authoritative DNS protocol implementations, encrypting zone transfers
  using TLS <span>[<a href="#RFC8499" class="xref">RFC8499</a>]</span> -- based closely on DoT <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span> -- seems like a simple step forward.
  This document specifies how to use TLS (1.3 or later) as a transport to prevent zone
  collection from zone transfers.<a href="#section-1-13" class="pilcrow">¶</a></p>
<p id="section-1-14">This document also updates the previous specifications for zone transfers to
  clarify and extend them, mainly with respect to TCP usage:<a href="#section-1-14" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-15.1">
          <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> (IXFR) and <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> (AXFR) are both updated to add further
    specification on efficient use of TCP connections.<a href="#section-1-15.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-15.2">
          <span><a href="https://www.rfc-editor.org/rfc/rfc7766#section-6.2.2" class="relref">Section 6.2.2</a> of [<a href="#RFC7766" class="xref">RFC7766</a>]</span> ("DNS Transport over TCP -
    Implementation Requirements") is updated with a new recommendation about 
    the number of connections between a client and server for each transport.<a href="#section-1-15.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Privacy terminology is as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6973#section-3" class="relref">Section 3</a> of [<a href="#RFC6973" class="xref">RFC6973</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">DNS terminology is as described in <span>[<a href="#RFC8499" class="xref">RFC8499</a>]</span>. Note that, as in
 <span>[<a href="#RFC8499" class="xref">RFC8499</a>]</span>, the
 terms 'primary' and 'secondary' are used for two servers engaged in zone transfers.<a href="#section-2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-4">
        <dt id="section-2-4.1">DoT:</dt>
        <dd style="margin-left: 3.5em" id="section-2-4.2">DNS over TLS, as specified in <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span><a href="#section-2-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.3">XFR over TCP:</dt>
        <dd style="margin-left: 3.5em" id="section-2-4.4">Used to mean both IXFR over TCP <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> 
   and AXFR over TCP <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span><a href="#section-2-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.5">XoT:</dt>
        <dd style="margin-left: 3.5em" id="section-2-4.6">XFR-over-TLS mechanisms, as specified in this document, which apply 
   to both AXFR over TLS and IXFR over TLS (XoT is pronounced 'zot' since X here
   stands for 'zone transfer')<a href="#section-2-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.7">AXoT:</dt>
        <dd style="margin-left: 3.5em" id="section-2-4.8">AXFR over TLS<a href="#section-2-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-4.9">IXoT:</dt>
        <dd style="margin-left: 3.5em" id="section-2-4.10">IXFR over TLS<a href="#section-2-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="threat-model">
<section id="section-3">
      <h2 id="name-threat-model">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-threat-model" class="section-name selfRef">Threat Model</a>
      </h2>
<p id="section-3-1">The threat model considered here is one where the current contents and size of the zone are
  considered sensitive and should be protected during transfer.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The threat model does not, however, consider the existence of a zone, the act of
  zone transfer between two entities, nor the identities of the name servers
  hosting a zone (including both those acting as hidden primaries/secondaries
  or directly serving the zone) as sensitive information. The proposed mechanism
  does not attempt to obscure such information. The reasons for this include:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">much of this information can be obtained by various methods, 
    including active scanning of the DNS, and<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.2">an attacker who can monitor network traffic can rather 
    easily infer relations between name servers simply from traffic 
    patterns, even when some or all of the traffic is encrypted
    (in terms of current deployments).<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4">The model does not consider attacks on the mechanisms that trigger a zone transfer, e.g.,
  NOTIFY messages.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">It is noted that simply using XoT will indicate a desire by the zone owner that the
  contents of the zone remain confidential and so could be subject to blocking (e.g., via
  blocking of port 853) if an attacker had
  such capabilities. However, this threat is likely true of any such mechanism that attempts to
  encrypt data passed between name servers, e.g., IPsec.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="design-considerations-for-xot">
<section id="section-4">
      <h2 id="name-design-considerations-for-x">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-design-considerations-for-x" class="section-name selfRef">Design Considerations for XoT</a>
      </h2>
<p id="section-4-1">The following principles were considered in the design for XoT:<a href="#section-4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4-2">
        <dt id="section-4-2.1">Confidentiality:</dt>
        <dd style="margin-left: 1.5em" id="section-4-2.2">Clearly using an encrypted transport for zone transfers will
    defeat zone content leakage that can occur via passive surveillance.<a href="#section-4-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-2.3">Authentication:</dt>
        <dd style="margin-left: 1.5em" id="section-4-2.4">Use of single or mutual TLS (mTLS) authentication (in combination
    with ACLs) can complement and potentially be an 
    alternative to TSIG.<a href="#section-4-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-2.5">Performance:</dt>
        <dd style="margin-left: 1.5em" id="section-4-2.6">
          <ul class="normal">
<li class="normal" id="section-4-2.6.1.1">Existing AXFR and IXFR mechanisms have the burden of backwards
 compatibility with older implementations based on the original specifications
 in <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> and <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>. For example, 
 some older AXFR servers don't
 support using a TCP connection for multiple AXFR sessions or XFRs of different
 zones because they have not been updated to follow the guidance in <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>.
 Any implementation of XoT would obviously be required to
 implement optimized and interoperable transfers, as described in <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>,
 e.g., transfer of multiple zones over one connection.<a href="#section-4-2.6.1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4-2.6.1.2">Current usage of TCP for IXFR is suboptimal in some cases, i.e.,
 connections are frequently closed after a single IXFR.<a href="#section-4-2.6.1.2" class="pilcrow">¶</a>
</li>
          </ul>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="connection-and-data-flows-in-existing-xfr-mechanisms">
<section id="section-5">
      <h2 id="name-connection-and-data-flows-i">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-connection-and-data-flows-i" class="section-name selfRef">Connection and Data Flows in Existing XFR Mechanisms</a>
      </h2>
<p id="section-5-1">The original specification for zone transfers in <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> and <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> was
  based on a polling mechanism: a secondary performed a periodic query for the SOA (start of
  zone authority) record (based
  on the refresh timer) to determine if an AXFR was required.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2"><span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> and <span>[<a href="#RFC1996" class="xref">RFC1996</a>]</span> introduced the concepts
  of IXFR and NOTIFY,
  respectively, to provide for prompt propagation of zone updates. This has
  largely replaced AXFR where possible, particularly for dynamically updated
  zones.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3"><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> subsequently redefined the specification of AXFR to improve
  performance and interoperability.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">In this document, the term 'XFR mechanism' is used to describe the entire set of
  message exchanges between a secondary and a primary that concludes with a
  successful AXFR or IXFR request/response. This set may or may not include:<a href="#section-5-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-5.1">NOTIFY messages<a href="#section-5-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.2">SOA queries<a href="#section-5-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.3">Fallback from IXFR to AXFR<a href="#section-5-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-5.4">Fallback from IXFR over UDP to IXFR over TCP<a href="#section-5-5.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-6">The term is used to encompass the range of permutations that are possible and
  is useful to distinguish the 'XFR mechanism' from a single XFR
  request/response exchange.<a href="#section-5-6" class="pilcrow">¶</a></p>
<div id="axfr-mechanism">
<section id="section-5.1">
        <h3 id="name-axfr-mechanism">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-axfr-mechanism" class="section-name selfRef">AXFR Mechanism</a>
        </h3>
<p id="section-5.1-1">The figure below provides an outline of an AXFR mechanism including NOTIFYs.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span id="name-axfr-mechanism-2"></span><div id="fig1">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-5.1-2.1">
<pre>
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            AXFR Request           | ---
       | --------------------------------&gt; |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 1          |   |
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   | TCP
       |          AXFR Response 2          |   | Session
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 3          |   |
       |             (Zone data)           | ---
       |                                   |
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-axfr-mechanism-2" class="selfRef">AXFR Mechanism</a>
          </figcaption></figure>
</div>
<ol start="1" type="1" class="normal type-1" id="section-5.1-3">
  <li id="section-5.1-3.1">An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from the
  primary to the secondary. A secondary may also initiate an AXFR based on a
  refresh timer or scheduled/triggered zone maintenance.<a href="#section-5.1-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-3.2">The secondary will normally (but not always) make an SOA query to the primary
  to obtain the serial number of the zone held by the primary.<a href="#section-5.1-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-3.3">If the primary serial is higher than the secondary's serial (using Serial
  Number Arithmetic <span>[<a href="#RFC1982" class="xref">RFC1982</a>]</span>), the secondary makes an AXFR request
  (over TCP)
  to the primary, after which the AXFR data flows in one or more AXFR responses on
  the TCP connection. <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> defines this specific step as an 'AXFR
  session',
  i.e., as an AXFR query message and the sequence of AXFR response messages
  returned for it.<a href="#section-5.1-3.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.1-4"><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> re-specified AXFR, providing additional guidance beyond that
provided in <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> and <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> and importantly
specified that AXFR must use TCP as the transport protocol.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">Additionally, Sections <a href="https://www.rfc-editor.org/rfc/rfc5936#section-4.1" class="relref">4.1</a>, <a href="https://www.rfc-editor.org/rfc/rfc5936#section-4.1.1" class="relref">4.1.1</a>, and <a href="https://www.rfc-editor.org/rfc/rfc5936#section-4.1.2" class="relref">4.1.2</a> of <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> provide improved
guidance for AXFR clients and servers with regard to reuse of TCP connections
for multiple AXFRs and AXFRs of different zones. However, <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> was
constrained by having to be backwards compatible with some very early basic
implementations of AXFR. For example, it outlines that the SOA query can also
happen on this connection. However, this can cause interoperability problems
with older implementations that support only the trivial case of one AXFR per
connection.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ixfr-mechanism">
<section id="section-5.2">
        <h3 id="name-ixfr-mechanism">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-ixfr-mechanism" class="section-name selfRef">IXFR Mechanism</a>
        </h3>
<p id="section-5.2-1">The figure below provides an outline of the IXFR mechanism including NOTIFYs.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<span id="name-ixfr-mechanism-2"></span><div id="fig2">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-5.2-2.1">
<pre>
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP or TCP
       | &lt;-------------------------------- |
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            IXFR Request           |
       | --------------------------------&gt; |  UDP or TCP
       | &lt;-------------------------------- |
       |            IXFR Response          |
       |             (Zone data)           |
       |                                   |
       |                                   | ---
       |            IXFR Request           |    |
       | --------------------------------&gt; |    | Retry over
       | &lt;-------------------------------- |    | TCP if
       |            IXFR Response          |    | required
       |             (Zone data)           | ---
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-ixfr-mechanism-2" class="selfRef">IXFR Mechanism</a>
          </figcaption></figure>
</div>
<ol start="1" type="1" class="normal type-1" id="section-5.2-3">
  <li id="section-5.2-3.1">An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from the
  primary to the secondary. A secondary may also initiate an IXFR based on a
  refresh timer or scheduled/triggered zone maintenance.<a href="#section-5.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-3.2">The secondary will normally (but not always) make an SOA query to the primary
  to obtain the serial number of the zone held by the primary.<a href="#section-5.2-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-3.3">If the primary serial is higher than the secondary's serial (using Serial
  Number Arithmetic <span>[<a href="#RFC1982" class="xref">RFC1982</a>]</span>), the secondary makes an IXFR request to
  the primary, after which the primary sends an IXFR response.<a href="#section-5.2-3.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.2-4"><span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> specifies that IXFR may use UDP if the entire IXFR
response can be contained in a single DNS packet, otherwise, TCP is used. In
fact, it says:<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<blockquote id="section-5.2-5">Thus, a client should first make an IXFR query using UDP.<a href="#section-5.2-5" class="pilcrow">¶</a>
</blockquote>
<p id="section-5.2-6">So there may be a fourth step above where the client falls back to IXFR over TCP.
There may also be an additional step where the secondary must fall back to AXFR
because, e.g., the primary does not support IXFR.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
<p id="section-5.2-7">However, it is noted that most of the widely used open-source implementations of authoritative name servers
(including both <span>[<a href="#BIND" class="xref">BIND</a>]</span> and <span>[<a href="#NSD" class="xref">NSD</a>]</span>) do IXFR using TCP by default
in their latest releases. For BIND, TCP connections are sometimes used for SOA
queries, but, in general, they are not used persistently and are closed after an IXFR
is completed.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="data-leakage-of-notify-and-soa-message-exchanges">
<section id="section-5.3">
        <h3 id="name-data-leakage-of-notify-and-">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-data-leakage-of-notify-and-" class="section-name selfRef">Data Leakage of NOTIFY and SOA Message Exchanges</a>
        </h3>
<p id="section-5.3-1">This section presents a rationale for considering the encryption of the other
  messages in the XFR mechanism.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">Since the SOA of the published zone can be trivially discovered by simply
  querying the publicly available authoritative servers, leakage of this resource record (RR)
  via such a
  direct query is not discussed in the following sections.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<div id="notify">
<section id="section-5.3.1">
          <h4 id="name-notify">
<a href="#section-5.3.1" class="section-number selfRef">5.3.1. </a><a href="#name-notify" class="section-name selfRef">NOTIFY</a>
          </h4>
<p id="section-5.3.1-1">Unencrypted NOTIFY messages identify configured secondaries on the primary.<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
<p id="section-5.3.1-2"><span>[<a href="#RFC1996" class="xref">RFC1996</a>]</span> also states:<a href="#section-5.3.1-2" class="pilcrow">¶</a></p>
<blockquote id="section-5.3.1-3">If ANCOUNT&gt;0, then the answer section represents an
  unsecure hint at the new RRset for this &lt;QNAME,QCLASS,QTYPE&gt;.<a href="#section-5.3.1-3" class="pilcrow">¶</a>
</blockquote>
<p id="section-5.3.1-4">But since the only query type (QTYPE) for NOTIFY defined at the time of this writing
  is SOA, this does not pose a
  potential leak.<a href="#section-5.3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="soa">
<section id="section-5.3.2">
          <h4 id="name-soa">
<a href="#section-5.3.2" class="section-number selfRef">5.3.2. </a><a href="#name-soa" class="section-name selfRef">SOA</a>
          </h4>
<p id="section-5.3.2-1">For hidden XFR servers (either primaries or secondaries), an SOA response
  directly from that server only additionally leaks the degree of SOA serial
  number lag of any downstream secondary of that server.<a href="#section-5.3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="updates-to-existing-specifications">
<section id="section-6">
      <h2 id="name-updates-to-existing-specifi">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-updates-to-existing-specifi" class="section-name selfRef">Updates to Existing Specifications</a>
      </h2>
<p id="section-6-1">For convenience, the term 'XFR over TCP' is used in this document to mean both
  IXFR over TCP and AXFR over TCP; therefore, statements that use that term update
  both <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> and <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> and implicitly also
  apply to XoT. Differences in behavior specific to XoT are discussed in
  <a href="#xot-specification" class="xref">Section 7</a>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Both <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> and <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> were published
  sometime before TCP became a widely supported transport for DNS. <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span>, in fact, says nothing
  with respect to optimizing IXFRs over TCP or reusing already open TCP
  connections to perform IXFRs or other queries. Therefore, there arguably is an
  implicit assumption that a TCP connection is used for
  one and only one IXFR request. Indeed, many major open-source implementations
  take this approach (at the time of this writing). And whilst <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>
  gives guidance on
  connection reuse for AXFR, it predates more recent specifications describing
  persistent TCP connections (e.g., <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span>, <span>[<a href="#RFC7828" class="xref">RFC7828</a>]</span>), and AXFR implementations again
  often make less-than-optimal use of open connections.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Given this, new implementations of XoT will clearly benefit from specific guidance on
  TCP/TLS connection usage for XFR, because this will:<a href="#section-6-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-4.1">result in more consistent XoT implementations with better interoperability and<a href="#section-6-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-4.2">remove any need for XoT implementations to support legacy behavior for XoT connections
  that XFR-over-TCP implementations have historically often supported.<a href="#section-6-4.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-5">Therefore, this document updates both the previous specifications for
XFR over TCP (<span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> and <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>) to clarify that:<a href="#section-6-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-6.1">Implementations <span class="bcp14">MUST</span> use <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> ("DNS Transport
  over TCP - Implementation Requirements") to optimize the use of TCP connections.<a href="#section-6-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-6.2">Whilst <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> states that "DNS clients
  <span class="bcp14">SHOULD</span> pipeline their queries"
  on TCP connections, it did not distinguish between XFRs and other queries for this
  behavior. It is now recognized that XFRs are not as latency sensitive as
  other queries and can be significantly more complex for clients to handle,
  both because of the large amount of state that must be kept and because there
  may be multiple messages in the responses. For these reasons, it is clarified
  here that a valid reason for not pipelining queries is when they are all XFR
  queries, i.e., clients sending multiple XFRs <span class="bcp14">MAY</span> choose not to pipeline those
  queries. Clients that do not pipeline XFR queries therefore have no
  additional requirements to handle out-of-order or intermingled responses (as
  described later), since they will never receive them.<a href="#section-6-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-6.3">Implementations <span class="bcp14">SHOULD</span> use the
  edns-tcp-keepalive EDNS(0) option <span>[<a href="#RFC7828" class="xref">RFC7828</a>]</span> to manage 
  persistent connections. This is
  more flexible than the alternative of simply using fixed timeouts.<a href="#section-6-6.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-7">The following sections include detailed clarifications on the updates to XFR
behavior implied in <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> and how the use of <span>[<a href="#RFC7828" class="xref">RFC7828</a>]</span> applies
specifically to XFR exchanges. They also discuss how IXFR and AXFR can reuse
the same TCP connection.<a href="#section-6-7" class="pilcrow">¶</a></p>
<p id="section-6-8">For completeness, the recent specification of extended
DNS error (EDE) codes <span>[<a href="#RFC8914" class="xref">RFC8914</a>]</span> is also mentioned here. For zone transfers, when returning REFUSED to a
zone transfer request from an 'unauthorized' client (e.g., where the client is not
listed in an ACL for zone transfers or does not sign the request with a
valid TSIG key), the extended DNS error code 18 - Prohibited can also be sent.<a href="#section-6-8" class="pilcrow">¶</a></p>
<div id="update-to-rfc1995-for-ixfr-over-tcp">
<section id="section-6.1">
        <h3 id="name-update-to-rfc-1995-for-ixfr">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-update-to-rfc-1995-for-ixfr" class="section-name selfRef">Update to RFC 1995 for IXFR over TCP</a>
        </h3>
<p id="section-6.1-1">For clarity, an IXFR-over-TCP server compliant with this specification
  <span class="bcp14">MUST</span> be
  able to handle multiple concurrent IXoT requests on a single TCP connection
  (for the same and different zones) and <span class="bcp14">SHOULD</span> send the responses as soon as
  they are available, which might be out of order compared to the requests.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="update-to-rfc5936-for-axfr-over-tcp">
<section id="section-6.2">
        <h3 id="name-update-to-rfc-5936-for-axfr">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-update-to-rfc-5936-for-axfr" class="section-name selfRef">Update to RFC 5936 for AXFR over TCP</a>
        </h3>
<p id="section-6.2-1">For clarity, an AXFR-over-TCP server compliant with this specification
  <span class="bcp14">MUST</span> be
  able to handle multiple concurrent AXoT sessions on a single TCP connection
  (for the same and different zones). The response streams for concurrent AXFRs
  <span class="bcp14">MAY</span> be intermingled, and AXFR-over-TCP clients compliant with this
  specification, which pipeline AXFR requests, <span class="bcp14">MUST</span> be able to handle this.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp">
<section id="section-6.3">
        <h3 id="name-updates-to-rfcs-1995-and-59">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-updates-to-rfcs-1995-and-59" class="section-name selfRef">Updates to RFCs 1995 and 5936 for XFR over TCP</a>
        </h3>
<div id="connection-reuse">
<section id="section-6.3.1">
          <h4 id="name-connection-reuse">
<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a href="#name-connection-reuse" class="section-name selfRef">Connection Reuse</a>
          </h4>
<p id="section-6.3.1-1">As specified, XFR-over-TCP clients <span class="bcp14">SHOULD</span> reuse any existing open TCP
    connection when
    starting any new XFR request to the same primary, and for issuing SOA queries,
    instead of opening a new connection. The number of TCP connections between a
    secondary and primary <span class="bcp14">SHOULD</span> be minimized (also see <a href="#update-to-rfc7766" class="xref">Section 6.4</a>).<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
<p id="section-6.3.1-2">Valid reasons for not reusing existing connections might include:<a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.1-3.1">As already noted in <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span>, separate connections for
      different zones might be preferred for operational reasons. In this case, the number of
      concurrent connections for zone transfers <span class="bcp14">SHOULD</span> be limited to the total
      number of zones transferred between the client and server.<a href="#section-6.3.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-3.2">A configured limit for the number of outstanding queries or XFR requests
      allowed on a single TCP connection has been reached.<a href="#section-6.3.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-3.3">The message ID pool has already been exhausted on an open connection.<a href="#section-6.3.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-3.4">A large number of timeouts or slow responses have occurred on an open
      connection.<a href="#section-6.3.1-3.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.1-3.5">An edns-tcp-keepalive EDNS(0) option with a timeout of 0 has been received from the
      server, and the client is in the process of closing the connection (see <a href="#the-edns-tcp-keepalive-edns0-option" class="xref">Section 6.3.4</a>).<a href="#section-6.3.1-3.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.3.1-4">If no TCP connections are currently open, XFR clients <span class="bcp14">MAY</span> send SOA
    queries over UDP or a new TCP connection.<a href="#section-6.3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="axfrs-and-ixfrs-on-the-same-connection">
<section id="section-6.3.2">
          <h4 id="name-axfrs-and-ixfrs-on-the-same">
<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a href="#name-axfrs-and-ixfrs-on-the-same" class="section-name selfRef">AXFRs and IXFRs on the Same Connection</a>
          </h4>
<p id="section-6.3.2-1">Neither <span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> nor <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> explicitly
    discuss the use of a single TCP
    connection for both IXFR and AXFR requests. <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> does make the
    general statement:<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-6.3.2-2">Non-AXFR session traffic can also use an open connection.<a href="#section-6.3.2-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-6.3.2-3">In this document, the above is clarified to indicate that implementations capable of both AXFR and IXFR and
    compliant with this specification <span class="bcp14">SHOULD</span>:<a href="#section-6.3.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.3.2-4.1">use the same TCP connection for both AXFR and IXFR requests to the same
      primary,<a href="#section-6.3.2-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.2-4.2">pipeline such requests (if they pipeline XFR requests in general) and
      <span class="bcp14">MAY</span> intermingle them, and<a href="#section-6.3.2-4.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6.3.2-4.3">send the response(s) for each request as soon as they are available, i.e.,
      responses <span class="bcp14">MAY</span> be sent intermingled.<a href="#section-6.3.2-4.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-6.3.2-5">For some current implementations, adding all the above functionality would introduce
    significant code complexity. In such a case, there will need to be an assessment of the
    trade-off between that and the performance benefits of the above for XFR.<a href="#section-6.3.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="xfr-limits">
<section id="section-6.3.3">
          <h4 id="name-xfr-limits">
<a href="#section-6.3.3" class="section-number selfRef">6.3.3. </a><a href="#name-xfr-limits" class="section-name selfRef">XFR Limits</a>
          </h4>
<p id="section-6.3.3-1">The server <span class="bcp14">MAY</span> limit the number of concurrent IXFRs, AXFRs, or total XFR
    transfers in progress (or from a given secondary) to protect server resources.
    Servers <span class="bcp14">SHOULD</span> return SERVFAIL if this limit is hit, since it is a
    transient error and a retry at a later time might succeed (there is no previous
    specification for this behavior).<a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-edns-tcp-keepalive-edns0-option">
<section id="section-6.3.4">
          <h4 id="name-the-edns-tcp-keepalive-edns">
<a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a href="#name-the-edns-tcp-keepalive-edns" class="section-name selfRef">The edns-tcp-keepalive EDNS(0) Option</a>
          </h4>
<p id="section-6.3.4-1">XFR clients that send the edns-tcp-keepalive EDNS(0) option on every XFR request provide
    the server with maximum opportunity to update the edns-tcp-keepalive timeout. The XFR
    server may use the frequency of recent XFRs to calculate an average update rate as
    input to the decision of what edns-tcp-keepalive timeout to use. If the server
    does not support edns-tcp-keepalive, the client <span class="bcp14">MAY</span> keep the connection
    open for a few seconds (<span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> recommends that servers use
    timeouts of at least a few seconds).<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
<p id="section-6.3.4-2">Whilst the specification for EDNS(0)  <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span>  does not
    specifically mention AXFRs, it does say:<a href="#section-6.3.4-2" class="pilcrow">¶</a></p>
<blockquote id="section-6.3.4-3">If an OPT record is present in a received request, compliant
    responders <span class="bcp14">MUST</span> include an OPT record in their respective
    responses.<a href="#section-6.3.4-3" class="pilcrow">¶</a>
</blockquote>
<p id="section-6.3.4-4">In this document, the above is clarified to indicate that if an OPT record is present in a received AXFR request,
    compliant responders <span class="bcp14">MUST</span> include an OPT record in each of the subsequent
    AXFR responses. Note that this requirement, combined with the use of
    edns-tcp-keepalive, enables AXFR servers to signal the desire to close a
    connection (when existing transactions have competed) due to low resources by
    sending an edns-tcp-keepalive EDNS(0) option with a timeout of 0 on any AXFR
    response. This does not signal that the AXFR is aborted, just that the server
    wishes to close the connection as soon as possible.<a href="#section-6.3.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="backwards-compatibility">
<section id="section-6.3.5">
          <h4 id="name-backwards-compatibility">
<a href="#section-6.3.5" class="section-number selfRef">6.3.5. </a><a href="#name-backwards-compatibility" class="section-name selfRef">Backwards Compatibility</a>
          </h4>
<p id="section-6.3.5-1">Certain legacy behaviors were noted in <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>, with provisions
    that implementations may want to offer options to fallback to legacy behavior when
    interoperating with servers known to not support <span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span>. For
    purposes of interoperability, IXFR and AXFR implementations may want to continue offering
    such configuration options, as well as supporting some behaviors that were
    underspecified prior to this work (e.g., performing IXFR and AXFRs on separate
    connections). However, XoT connections should have no need to do so.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="update-to-rfc7766">
<section id="section-6.4">
        <h3 id="name-update-to-rfc-7766">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-update-to-rfc-7766" class="section-name selfRef">Update to RFC 7766</a>
        </h3>
<p id="section-6.4-1"><span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> made general implementation
  recommendations with regard to TCP/TLS connection handling:<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<blockquote id="section-6.4-2">To mitigate the risk of unintentional server overload, DNS
  clients <span class="bcp14">MUST</span> take care to minimize the number of concurrent TCP
  connections made to any individual server. It is <span class="bcp14">RECOMMENDED</span>
  that for any given client/server interaction there <span class="bcp14">SHOULD</span> be no
  more than one connection for regular queries, one for zone
  transfers, and one for each protocol that is being used on top
  of TCP (for example, if the resolver was using TLS). However,
  it is noted that certain primary/ secondary configurations with
  many busy zones might need to use more than one TCP connection
  for zone transfers for operational reasons (for example, to
  support concurrent transfers of multiple zones).<a href="#section-6.4-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-6.4-3">Whilst this recommends a particular behavior for the clients using TCP, it
  does not relax the requirement for servers to handle 'mixed' traffic (regular
  queries and zone transfers) on any open TCP/TLS connection. It also overlooks the
  potential that other transports might want to take the same approach with regard to
  using separate connections for different purposes.<a href="#section-6.4-3" class="pilcrow">¶</a></p>
<p id="section-6.4-4">This specification updates the above general guidance in <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span>
  to provide the same separation of connection purpose (regular queries and zone transfers) for
  all transports being used on top of TCP.<a href="#section-6.4-4" class="pilcrow">¶</a></p>
<p id="section-6.4-5">Therefore, it is <span class="bcp14">RECOMMENDED</span> that for
  each protocol used on top of TCP in any given client/server interaction there
  <span class="bcp14">SHOULD</span> be no more than one connection for regular queries and one for zone
  transfers.<a href="#section-6.4-5" class="pilcrow">¶</a></p>
<p id="section-6.4-6">As an illustration, it could be imagined that in the future such an
  interaction could hypothetically include one or all of the following:<a href="#section-6.4-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.4-7.1">one TCP connection for regular queries<a href="#section-6.4-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-7.2">one TCP connection for zone transfers<a href="#section-6.4-7.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-7.3">one TLS connection for regular queries<a href="#section-6.4-7.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-7.4">one TLS connection for zone transfers<a href="#section-6.4-7.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-7.5">one DoH connection for regular queries<a href="#section-6.4-7.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.4-7.6">one DoH connection for zone transfers<a href="#section-6.4-7.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.4-8"><a href="#connection-reuse" class="xref">Section 6.3.1</a> provides specific details of the reasons why
  more than one connection for a given transport might be required for zone transfers from
  a particular client.<a href="#section-6.4-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="xot-specification">
<section id="section-7">
      <h2 id="name-xot-specification">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-xot-specification" class="section-name selfRef">XoT Specification</a>
      </h2>
<div id="connection-establishment">
<section id="section-7.1">
        <h3 id="name-connection-establishment">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-connection-establishment" class="section-name selfRef">Connection Establishment</a>
        </h3>
<p id="section-7.1-1">During connection establishment, the Application-Layer Protocol Negotiation (ALPN) token
    "dot" <span>[<a href="#DoT-ALPN" class="xref">DoT-ALPN</a>]</span> <span class="bcp14">MUST</span> be selected in the TLS
    handshake.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tls-versions">
<section id="section-7.2">
        <h3 id="name-tls-versions">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-tls-versions" class="section-name selfRef">TLS Versions</a>
        </h3>
<p id="section-7.2-1">All implementations of this specification <span class="bcp14">MUST</span> use only TLS 1.3 <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> or later.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="port-selection">
<section id="section-7.3">
        <h3 id="name-port-selection">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-port-selection" class="section-name selfRef">Port Selection</a>
        </h3>
<p id="section-7.3-1">The connection for XoT <span class="bcp14">SHOULD</span> be established using port 853, as
    specified in <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span>, unless there is mutual agreement between the
    primary and secondary to use a port other than port 853 for XoT. There <span class="bcp14">MAY</span>
    be agreement to use different ports for AXoT and IXoT or for different zones.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="high-level-xot-descriptions">
<section id="section-7.4">
        <h3 id="name-high-level-xot-descriptions">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-high-level-xot-descriptions" class="section-name selfRef">High-Level XoT Descriptions</a>
        </h3>
<p id="section-7.4-1">It is useful to note that in XoT it is the secondary that initiates
    the TLS connection to the primary for an XFR request so that, in terms of
    connectivity, the secondary is the TLS client and the primary is the TLS server.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">The figure below provides an outline of the AXoT mechanism including NOTIFYs.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<span id="name-axot-mechanism"></span><div id="fig3">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-7.4-3.1">
<pre>
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP/TLS session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            AXFR Request           | ---
       | --------------------------------&gt; |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 1          |   |
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   | TLS
       |          AXFR Response 2          |   | Session
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 3          |   |
       |             (Zone data)           | ---
       |                                   |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-axot-mechanism" class="selfRef">AXoT Mechanism</a>
          </figcaption></figure>
</div>
<p id="section-7.4-4">The figure below provides an outline of the IXoT mechanism including NOTIFYs.<a href="#section-7.4-4" class="pilcrow">¶</a></p>
<span id="name-ixot-mechanism"></span><div id="fig4">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-7.4-5.1">
<pre>
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP/TLS session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            IXFR Request           | ---
       | --------------------------------&gt; |    |
       | &lt;-------------------------------- |    |
       |            IXFR Response          |    |
       |             (Zone data)           |    |
       |                                   |    | TLS
       |                                   |    | session
       |            IXFR Request           |    |
       | --------------------------------&gt; |    |
       | &lt;-------------------------------- |    |
       |            IXFR Response          |    |
       |             (Zone data)           | ---
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-ixot-mechanism" class="selfRef">IXoT Mechanism</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="xot-transfers">
<section id="section-7.5">
        <h3 id="name-xot-transfers">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-xot-transfers" class="section-name selfRef">XoT Transfers</a>
        </h3>
<p id="section-7.5-1">For a zone transfer between two endpoints to be considered protected with XoT,
  all XFR requests and responses for that zone <span class="bcp14">MUST</span> be sent over TLS connections,
  where at a minimum:<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5-2.1">The client <span class="bcp14">MUST</span> authenticate the server by use of an authentication
    domain name using a Strict Privacy profile, as described in <span>[<a href="#RFC8310" class="xref">RFC8310</a>]</span>.<a href="#section-7.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.5-2.2">
            <p id="section-7.5-2.2.1">The server <span class="bcp14">MUST</span> validate the client is authorized to request or proxy
    a zone transfer by using one or both of the following methods:<a href="#section-7.5-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.5-2.2.2.1">mutual TLS (mTLS)<a href="#section-7.5-2.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.5-2.2.2.2">an IP-based ACL (which can be either per message or per connection)
      combined with a valid TSIG/SIG(0) signature on the XFR request<a href="#section-7.5-2.2.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-7.5-3">If only one method is selected, then mTLS is preferred because it provides strong
  cryptographic protection at both endpoints.<a href="#section-7.5-3" class="pilcrow">¶</a></p>
<p id="section-7.5-4">Authentication mechanisms are discussed in full in <a href="#authentication-mechanisms" class="xref">Section 9</a>,
  and the rationale for the above requirement is discussed in <a href="#xot-authentication" class="xref">Section 10</a>.
  Transfer group policies are discussed in <a href="#policies-for-both-axot-and-ixot" class="xref">Section 11</a>.<a href="#section-7.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="xot-connections">
<section id="section-7.6">
        <h3 id="name-xot-connections">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-xot-connections" class="section-name selfRef">XoT Connections</a>
        </h3>
<p id="section-7.6-1">The details in <a href="#updates-to-existing-specifications" class="xref">Section 6</a> about, e.g.,
  persistent connections and XFR message handling, are fully applicable to XoT connections as
  well. However, any behavior specified here takes precedence for XoT.<a href="#section-7.6-1" class="pilcrow">¶</a></p>
<p id="section-7.6-2">If no TLS connections are currently open, XoT clients <span class="bcp14">MAY</span> send SOA queries
  over UDP, TCP, or TLS.<a href="#section-7.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="xot-vs-adot">
<section id="section-7.7">
        <h3 id="name-xot-vs-adot">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-xot-vs-adot" class="section-name selfRef">XoT vs. ADoT</a>
        </h3>
<p id="section-7.7-1">As noted earlier, there is currently no specification for encryption of
  connections from recursive resolvers to authoritative servers. Some
  authoritative servers are experimenting with ADoT, and opportunistic encryption
  has also been raised as a possibility; therefore, it is highly likely that use
  of encryption by authoritative servers will evolve in the coming years.<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<p id="section-7.7-2">This raises questions in the short term with regard to TLS connection and
  message handling for authoritative servers. In particular, there is likely to be
  a class of authoritative servers that wish to use XoT in the near future with a
  small number of configured secondaries but that do not wish to support DoT for
  regular queries from recursives in that same time frame. These servers have to
  potentially cope with probing and direct queries from recursives and from test
  servers and also potential attacks that might wish to make use of TLS to
  overload the server.<a href="#section-7.7-2" class="pilcrow">¶</a></p>
<p id="section-7.7-3"><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> clearly states that non-AXFR session traffic can use an
  open connection; however, this requirement needs to be reevaluated when considering
  the application of the same model to XoT. Proposing that a server should also start
  responding to all queries received over TLS just because it has enabled XoT
  would be equivalent to defining a form of authoritative DoT. This specification
  does not propose that, but it also does not prohibit servers from answering
  queries unrelated to XFR exchanges over TLS. Rather, this specification
  simply outlines in later sections:<a href="#section-7.7-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.7-4.1">the utilization of EDE codes by XoT servers in response to queries on TLS
    connections that they are not willing to answer (see <a href="#response-rcodes" class="xref">Section 7.8</a>)<a href="#section-7.7-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.7-4.2">the operational and policy options that an operator of a XoT server has
    with regard to managing TLS connections and messages (see <a href="#xot-server-connection-handling" class="xref">Appendix A</a>)<a href="#section-7.7-4.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="response-rcodes">
<section id="section-7.8">
        <h3 id="name-response-rcodes">
<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-response-rcodes" class="section-name selfRef">Response RCODES</a>
        </h3>
<p id="section-7.8-1">XoT clients and servers <span class="bcp14">MUST</span> implement EDE codes. If a XoT server receives
  non-XoT traffic it is not willing to answer on a TLS connection, it <span class="bcp14">SHOULD</span>
  respond with REFUSED and the extended DNS error code 21 - Not Supported
  <span>[<a href="#RFC8914" class="xref">RFC8914</a>]</span>. XoT clients should not send any further
  queries of this type to the server for a reasonable period of time (for
  example, one hour), i.e., long enough that the server configuration or policy
  might be updated.<a href="#section-7.8-1" class="pilcrow">¶</a></p>
<p id="section-7.8-2">Historically, servers have used the REFUSED RCODE for many situations; therefore,
  clients often had no detailed information on which to base an error or fallback
  path when queries were refused. As a result, the client behavior could vary
  significantly. XoT servers that refuse queries must cater to the fact that
  client behavior might vary from continually retrying queries regardless of
  receiving REFUSED to every query or, at the other extreme, clients may decide to
  stop using the server over any transport. This might be because those clients are
  either non-XoT clients or do not implement EDE codes.<a href="#section-7.8-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="axot-specifics">
<section id="section-7.9">
        <h3 id="name-axot-specifics">
<a href="#section-7.9" class="section-number selfRef">7.9. </a><a href="#name-axot-specifics" class="section-name selfRef">AXoT Specifics</a>
        </h3>
<div id="padding-axot-responses">
<section id="section-7.9.1">
          <h4 id="name-padding-axot-responses">
<a href="#section-7.9.1" class="section-number selfRef">7.9.1. </a><a href="#name-padding-axot-responses" class="section-name selfRef">Padding AXoT Responses</a>
          </h4>
<p id="section-7.9.1-1">The goal of padding AXoT responses is two fold:<a href="#section-7.9.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.9.1-2.1">to obfuscate the actual size of the transferred zone to minimize information
      leakage about the entire contents of the zone<a href="#section-7.9.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-7.9.1-2.2">to obfuscate the incremental changes to the zone between SOA updates to
      minimize information leakage about zone update activity and growth<a href="#section-7.9.1-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-7.9.1-3">Note that the reuse of XoT connections for transfers of multiple different
    zones slightly complicates any attempt to analyze the traffic size and timing to
    extract information.  Also, effective padding may require the state to be kept
    because zones may grow and/or shrink over time.<a href="#section-7.9.1-3" class="pilcrow">¶</a></p>
<p id="section-7.9.1-4">It is noted here that, depending on the padding policies eventually developed for XoT,
    the requirement to obfuscate the total zone size might
    require a server to create 'empty' AXoT responses, that is, AXoT responses that
    contain no RRs apart from an OPT RR containing the EDNS(0) option for padding.
    For example, without this capability, the maximum size that a tiny zone could be padded to
    would theoretically be limited if there had to be a minimum of 1 RR per packet.<a href="#section-7.9.1-4" class="pilcrow">¶</a></p>
<p id="section-7.9.1-5">However, as with existing AXFR, the last AXoT response message sent <span class="bcp14">MUST</span>
    contain the same SOA that was in the first message of the AXoT response series
    in order to signal the conclusion of the zone transfer.<a href="#section-7.9.1-5" class="pilcrow">¶</a></p>
<p id="section-7.9.1-6"><span>[<a href="#RFC5936" class="xref">RFC5936</a>]</span> says:<a href="#section-7.9.1-6" class="pilcrow">¶</a></p>
<blockquote id="section-7.9.1-7">Each AXFR response message <span class="bcp14">SHOULD</span> contain a sufficient number
    of RRs to reasonably amortize the per-message overhead, up to
    the largest number that will fit within a DNS message (taking
    the required content of the other sections into account, as
    described below).<a href="#section-7.9.1-7" class="pilcrow">¶</a>
</blockquote>
<p id="section-7.9.1-8">'Empty' AXoT responses generated in order to meet a padding requirement will be
    exceptions to the above statement. For flexibility, for future proofing, and in
    order to guarantee support for future padding policies, it is stated here that
    secondary implementations <span class="bcp14">MUST</span> be resilient to receiving padded AXoT
    responses, including 'empty' AXoT responses that contain only an OPT RR containing the
    EDNS(0) option for padding.<a href="#section-7.9.1-8" class="pilcrow">¶</a></p>
<p id="section-7.9.1-9">Recommendations of specific policies for padding AXoT responses are out of scope
    for this specification. Detailed considerations of such policies and the
    trade-offs involved are expected to be the subject of future work.<a href="#section-7.9.1-9" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ixot-specifics">
<section id="section-7.10">
        <h3 id="name-ixot-specifics">
<a href="#section-7.10" class="section-number selfRef">7.10. </a><a href="#name-ixot-specifics" class="section-name selfRef">IXoT Specifics</a>
        </h3>
<div id="condensation-of-responses">
<section id="section-7.10.1">
          <h4 id="name-condensation-of-responses">
<a href="#section-7.10.1" class="section-number selfRef">7.10.1. </a><a href="#name-condensation-of-responses" class="section-name selfRef">Condensation of Responses</a>
          </h4>
<p id="section-7.10.1-1"><span>[<a href="#RFC1995" class="xref">RFC1995</a>]</span> says that condensation of responses is optional and
    <span class="bcp14">MAY</span> be done. Whilst
    it does add complexity to generating responses, it can significantly reduce the
    size of responses. However, any such reduction might be offset by increased
    message size due to padding. This specification does not update the optionality
    of condensation for XoT responses.<a href="#section-7.10.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fallback-to-axfr">
<section id="section-7.10.2">
          <h4 id="name-fallback-to-axfr">
<a href="#section-7.10.2" class="section-number selfRef">7.10.2. </a><a href="#name-fallback-to-axfr" class="section-name selfRef">Fallback to AXFR</a>
          </h4>
<p id="section-7.10.2-1">Fallback to AXFR can happen, for example, if the server is not able to provide
    an IXFR for the requested SOA. Implementations differ in how long they store
    zone deltas and how many may be stored at any one time.<a href="#section-7.10.2-1" class="pilcrow">¶</a></p>
<p id="section-7.10.2-2">Just as with IXFR over TCP, after a failed IXFR, an IXoT client <span class="bcp14">SHOULD</span>
    request the AXFR on the already open XoT connection.<a href="#section-7.10.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="padding-of-ixot-responses">
<section id="section-7.10.3">
          <h4 id="name-padding-of-ixot-responses">
<a href="#section-7.10.3" class="section-number selfRef">7.10.3. </a><a href="#name-padding-of-ixot-responses" class="section-name selfRef">Padding of IXoT Responses</a>
          </h4>
<p id="section-7.10.3-1">The goal of padding IXoT responses is to obfuscate the incremental
    changes to the zone between SOA updates to minimize information leakage about
    zone update activity and growth. Both the size and timing of the IXoT responses could
    reveal information.<a href="#section-7.10.3-1" class="pilcrow">¶</a></p>
<p id="section-7.10.3-2">IXFR responses can vary greatly in size from the order of 100 bytes for one or
    two record updates to tens of thousands of bytes for large, dynamic DNSSEC-signed zones.
    The frequency of IXFR responses can also depend greatly on if and how the zone is DNSSEC
    signed.<a href="#section-7.10.3-2" class="pilcrow">¶</a></p>
<p id="section-7.10.3-3">In order to guarantee support for future padding policies, it is stated here
    that
    secondary implementations <span class="bcp14">MUST</span> be resilient to receiving padded IXoT
    responses.<a href="#section-7.10.3-3" class="pilcrow">¶</a></p>
<p id="section-7.10.3-4">Recommendation of specific policies for padding IXoT responses are out of scope
    for this specification. Detailed considerations of such padding policies, the
    use of traffic obfuscation techniques (such as generating fake XFR traffic), and
    the trade-offs involved are expected to be the subject of future work.<a href="#section-7.10.3-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="name-compression-and-maximum-payload-sizes">
<section id="section-7.11">
        <h3 id="name-name-compression-and-maximu">
<a href="#section-7.11" class="section-number selfRef">7.11. </a><a href="#name-name-compression-and-maximu" class="section-name selfRef">Name Compression and Maximum Payload Sizes</a>
        </h3>
<p id="section-7.11-1">It is noted here that name compression <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> can be used in XFR
  responses to reduce the size of the payload; however, the maximum value of the offset that
  can be used in the name compression pointer structure is 16384. For some DNS
  implementations, this limits the size of an individual XFR response used in
  practice to something around the order of 16 KB. In principle, larger
  payload sizes can be supported for some responses with more sophisticated
  approaches (e.g., by precalculating the maximum offset required).<a href="#section-7.11-1" class="pilcrow">¶</a></p>
<p id="section-7.11-2">Implementations may wish to offer options to disable name compression for XoT
  responses to enable larger payloads. This might be particularly helpful when
  padding is used, since minimizing the payload size is not necessarily a useful
  optimization in this case and disabling name compression will reduce the
  resources required to construct the payload.<a href="#section-7.11-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="multi-primary-configurations">
<section id="section-8">
      <h2 id="name-multi-primary-configuration">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-multi-primary-configuration" class="section-name selfRef">Multi-primary Configurations</a>
      </h2>
<p id="section-8-1">This model can provide flexibility
  and redundancy, particularly for IXFR. A secondary will receive one or more
  NOTIFY messages and can send an SOA to all of the configured primaries. It can
  then choose to send an XFR request to the primary with the highest SOA (or
  based on other criteria, e.g., RTT).<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">When using persistent connections, the secondary may have a XoT connection
  already open to one or more primaries. Should a secondary preferentially
  request an XFR from a primary to which it already has an open XoT connection
  or the one with the highest SOA (assuming it doesn't have a connection open to
  it already)?<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Two extremes can be envisaged here. The first one can be considered a 'preferred
  primary connection' model. In this case, the secondary continues to use one
  persistent connection to a single primary until it has reason not to. Reasons
  not to might include the primary repeatedly closing the connection, long query/response RTTs
  on transfers, or the SOA of the primary being an unacceptable lag behind the SOA of
  an alternative primary.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">The other extreme can be considered a 'parallel primary connection' model. Here,
  a secondary could keep multiple persistent connections open to all available
  primaries and only request XFRs from the primary with the highest serial number.
  Since normally the number of secondaries and primaries in direct contact in a
  transfer group is reasonably low, this might be feasible if latency is the most
  significant concern.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">Recommendation of a particular scheme is out of scope of this document, but
implementations are encouraged to provide configuration options that allow
operators to make choices about this behavior.<a href="#section-8-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authentication-mechanisms">
<section id="section-9">
      <h2 id="name-authentication-mechanisms">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-authentication-mechanisms" class="section-name selfRef">Authentication Mechanisms</a>
      </h2>
<p id="section-9-1">To provide context to the requirements in <a href="#xot-transfers" class="xref">Section 7.5</a>, this
  section provides a brief summary of some of the existing authentication and
  validation mechanisms (both transport independent and TLS specific) that are
  available when performing zone transfers.
  <a href="#xot-authentication" class="xref">Section 10</a> then discusses in more detail specifically how a
  combination of TLS authentication, TSIG, and IP-based ACLs interact for XoT.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">In this document, the mechanisms are classified based on the following properties:<a href="#section-9-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-9-3">
        <dt id="section-9-3.1">Data Origin Authentication (DO):</dt>
        <dd style="margin-left: 1.5em" id="section-9-3.2">Authentication 1) of the fact that the DNS message originated
    from the party with whom credentials were shared and 2) of the data integrity
    of the message contents (the originating party may or may not be the party
    operating the far end of a TCP/TLS connection in a 'proxy' scenario).<a href="#section-9-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-3.3">Channel Confidentiality (CC):</dt>
        <dd style="margin-left: 1.5em" id="section-9-3.4">Confidentiality of the communication channel between the
    client and server (i.e., the two endpoints of a TCP/TLS connection) from passive
    surveillance.<a href="#section-9-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-3.5">Channel Authentication (CA):</dt>
        <dd style="margin-left: 1.5em" id="section-9-3.6">Authentication of the identity of the party to whom a TCP/TLS
    connection is made (this might not be a direct connection between the primary
    and secondary in a proxy scenario).<a href="#section-9-3.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<div id="tsig">
<section id="section-9.1">
        <h3 id="name-tsig">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-tsig" class="section-name selfRef">TSIG</a>
        </h3>
<p id="section-9.1-1">TSIG <span>[<a href="#RFC8945" class="xref">RFC8945</a>]</span> provides a mechanism for two or more parties to use
  shared secret keys that can then be used to create a message digest to protect
  individual DNS messages. This allows each party to authenticate that a request
  or response (and the data in it) came from the other party, even if it was
  transmitted over an unsecured channel or via a proxy.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.1-2">
          <dt id="section-9.1-2.1">Properties:</dt>
          <dd style="margin-left: 1.5em" id="section-9.1-2.2">Data origin authentication.<a href="#section-9.1-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sig-0">
<section id="section-9.2">
        <h3 id="name-sig0">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-sig0" class="section-name selfRef">SIG(0)</a>
        </h3>
<p id="section-9.2-1">SIG(0) <span>[<a href="#RFC2931" class="xref">RFC2931</a>]</span> similarly provides a mechanism to digitally sign a
  DNS message but uses public key authentication, where the public keys are stored in
  DNS as KEY RRs and a private key is stored at the signer.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.2-2">
          <dt id="section-9.2-2.1">Properties:</dt>
          <dd style="margin-left: 1.5em" id="section-9.2-2.2">Data origin authentication.<a href="#section-9.2-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="tls">
<section id="section-9.3">
        <h3 id="name-tls">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-tls" class="section-name selfRef">TLS</a>
        </h3>
<div id="opportunistic-tls">
<section id="section-9.3.1">
          <h4 id="name-opportunistic-tls">
<a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-opportunistic-tls" class="section-name selfRef">Opportunistic TLS</a>
          </h4>
<p id="section-9.3.1-1">Opportunistic TLS for DoT is defined in <span>[<a href="#RFC8310" class="xref">RFC8310</a>]</span> and can provide a
    defense against passive
    surveillance, providing on-the-wire confidentiality. Essentially:<a href="#section-9.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.3.1-2.1">if clients know authentication information for a server, they
      <span class="bcp14">SHOULD</span> try to authenticate the server,<a href="#section-9.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.3.1-2.2">if this fails or clients do not know the information, they <span class="bcp14">MAY</span>
      fallback to using TLS without authentication, or<a href="#section-9.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.3.1-2.3">clients <span class="bcp14">MAY</span> fallback to using cleartext if TLS is not
      available.<a href="#section-9.3.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-9.3.1-3">As such, it does not offer a defense against active attacks (e.g., an on-path active
    attacker on the connection from client to server) and is not considered as useful for
    XoT.<a href="#section-9.3.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.3.1-4">
            <dt id="section-9.3.1-4.1">Properties:</dt>
            <dd style="margin-left: 1.5em" id="section-9.3.1-4.2">None guaranteed.<a href="#section-9.3.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="strict-tls">
<section id="section-9.3.2">
          <h4 id="name-strict-tls">
<a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-strict-tls" class="section-name selfRef">Strict TLS</a>
          </h4>
<p id="section-9.3.2-1">Strict TLS for DoT <span>[<a href="#RFC8310" class="xref">RFC8310</a>]</span> requires that a client is configured
  with an authentication domain name (and/or Subject Public Key Info (SPKI) pin set) that
  <span class="bcp14">MUST</span> be used to
  authenticate the TLS handshake with the server. If authentication of the server
  fails, the client will not proceed with the connection. This provides a defense
  for the client against active surveillance, providing client-to-server
  authentication and end-to-end channel confidentiality.<a href="#section-9.3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.3.2-2">
            <dt id="section-9.3.2-2.1">Properties:</dt>
            <dd style="margin-left: 1.5em" id="section-9.3.2-2.2">Channel confidentiality and channel authentication (of the server).<a href="#section-9.3.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="mutual-tls">
<section id="section-9.3.3">
          <h4 id="name-mutual-tls">
<a href="#section-9.3.3" class="section-number selfRef">9.3.3. </a><a href="#name-mutual-tls" class="section-name selfRef">Mutual TLS</a>
          </h4>
<p id="section-9.3.3-1">This is an extension to Strict TLS <span>[<a href="#RFC8310" class="xref">RFC8310</a>]</span> that requires that a
  client is configured with an authentication domain name (and/or SPKI pin set) and a client
  certificate. The client offers the certificate for authentication by the server,
  and the client can authenticate the server the same way as in Strict TLS. This
  provides a defense for both parties against active surveillance, providing
  bidirectional authentication and end-to-end channel confidentiality.<a href="#section-9.3.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-9.3.3-2">
            <dt id="section-9.3.3-2.1">Properties:</dt>
            <dd style="margin-left: 1.5em" id="section-9.3.3-2.2">Channel confidentiality and mutual channel authentication.<a href="#section-9.3.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="ip-based-acl-on-the-primary">
<section id="section-9.4">
        <h3 id="name-ip-based-acl-on-the-primary">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-ip-based-acl-on-the-primary" class="section-name selfRef">IP-Based ACL on the Primary</a>
        </h3>
<p id="section-9.4-1">Most DNS server implementations offer an option to configure an IP-based 
  ACL, which is often used in combination with TSIG-based ACLs to
  restrict access to zone transfers on primary servers on a per-query basis.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
<p id="section-9.4-2">This is also possible with XoT, but it must be noted that, as with TCP, the
  implementation of such an ACL cannot be enforced on the primary until an XFR
  request is received on an established connection.<a href="#section-9.4-2" class="pilcrow">¶</a></p>
<p id="section-9.4-3">As discussed in <a href="#xot-server-connection-handling" class="xref">Appendix A</a>, an 
  IP-based per-connection ACL could also be implemented where only TLS connections from
  recognized secondaries are accepted.<a href="#section-9.4-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.4-4">
          <dt id="section-9.4-4.1">Properties:</dt>
          <dd style="margin-left: 1.5em" id="section-9.4-4.2">Channel authentication of the client.<a href="#section-9.4-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="zonemd">
<section id="section-9.5">
        <h3 id="name-zonemd">
<a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-zonemd" class="section-name selfRef">ZONEMD</a>
        </h3>
<p id="section-9.5-1">For completeness, ZONEMD
  <span>[<a href="#RFC8976" class="xref">RFC8976</a>]</span> ("Message Digest for DNS Zones") is described here. 
  The ZONEMD message digest
  is a mechanism that can be used to verify the content of a standalone zone. It
  is designed to be independent of the transmission channel or mechanism, allowing
  a general consumer of a zone to do origin authentication of the entire zone
  contents. Note that the current version of <span>[<a href="#RFC8976" class="xref">RFC8976</a>]</span>
  states:<a href="#section-9.5-1" class="pilcrow">¶</a></p>
<blockquote id="section-9.5-2">As specified herein, ZONEMD is impractical for large, dynamic zones due to the
  time and resources required for digest calculation. However, the ZONEMD record
  is extensible so that new digest schemes may be added in the future to support
  large, dynamic zones.<a href="#section-9.5-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-9.5-3">It is complementary but orthogonal to the above mechanisms and can be used in
  conjunction with XoT but is not considered further here.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="xot-authentication">
<section id="section-10">
      <h2 id="name-xot-authentication">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-xot-authentication" class="section-name selfRef">XoT Authentication</a>
      </h2>
<p id="section-10-1">It is noted that zone transfer scenarios can vary from a simple single
  primary/secondary relationship where both servers are under the control of a
  single operator to a complex hierarchical structure that includes proxies and
  multiple operators. Each deployment scenario will require specific analysis to
  determine which combination of authentication methods are best suited to the
  deployment model in question.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">The XoT authentication requirement specified in <a href="#xot-transfers" class="xref">Section 7.5</a>
  addresses the
  issue of ensuring that the transfers are encrypted between the two endpoints
  directly involved in the current transfers. The following table summarizes the
  properties of a selection of the mechanisms discussed in
  <a href="#authentication-mechanisms" class="xref">Section 9</a>. The two-letter abbreviations for the properties
  are used below: (S) indicates the secondary and (P) indicates
  the primary.<a href="#section-10-2" class="pilcrow">¶</a></p>
<span id="name-properties-of-authenticatio"></span><div id="table1">
<table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-properties-of-authenticatio" class="selfRef">Properties of Authentication Methods for XoT</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Method</th>
            <th class="text-center" rowspan="1" colspan="1">DO(S)</th>
            <th class="text-center" rowspan="1" colspan="1">CC(S)</th>
            <th class="text-center" rowspan="1" colspan="1">CA(S)</th>
            <th class="text-center" rowspan="1" colspan="1">DO(P)</th>
            <th class="text-center" rowspan="1" colspan="1">CC(P)</th>
            <th class="text-center" rowspan="1" colspan="1">CA(P)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Strict TLS</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Mutual TLS</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">ACL on primary</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">TSIG</td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1">Y</td>
            <td class="text-center" rowspan="1" colspan="1"></td>
            <td class="text-center" rowspan="1" colspan="1"></td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-10-4">Based on this analysis, it can be seen that:<a href="#section-10-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10-5.1">Using just mutual TLS can be considered a standalone solution since both endpoints are
    cryptographically authenticated.<a href="#section-10-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-10-5.2">Using secondary-side Strict TLS with a primary-side IP-based ACL and TSIG/SIG(0) combination
    provides sufficient protection to be acceptable.<a href="#section-10-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-10-6">Using just an IP-based ACL could be susceptible to attacks that can spoof TCP IP
  addresses; using TSIG/SIG(0) alone could be susceptible to attacks that were
  able to capture such messages should they be accidentally sent in cleartext by any server
  with the key.<a href="#section-10-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="policies-for-both-axot-and-ixot">
<section id="section-11">
      <h2 id="name-policies-for-both-axot-and-">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-policies-for-both-axot-and-" class="section-name selfRef">Policies for Both AXoT and IXoT</a>
      </h2>
<p id="section-11-1">Whilst the protection of the zone contents in a transfer between two endpoints
  can be provided by the XoT protocol, the protection of all the transfers of a
  given zone requires operational administration and policy management.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">The entire group of servers involved in XFR for a particular set of
  zones (all the primaries and all the secondaries) is called the 'transfer group'.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">In order to assure the confidentiality of the zone information, the entire
  transfer group <span class="bcp14">MUST</span> have a consistent policy of using XoT. If any do not, this
  is a weak link for attackers to exploit. For clarification, this means that
  within any transfer group both AXFRs and IXFRs for a zone <span class="bcp14">MUST</span> all use
  XoT.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">An individual zone transfer is not considered protected by XoT unless
  both the client and server are configured to use only XoT, and the overall zone
  transfer is not considered protected until all members of the transfer group
  are configured to use only XoT with all other transfers servers (see <a href="#implementation-considerations" class="xref">Section 12</a>).<a href="#section-11-4" class="pilcrow">¶</a></p>
<p id="section-11-5">A XoT policy <span class="bcp14">MUST</span> specify if:<a href="#section-11-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11-6.1">mutual TLS is used and/or<a href="#section-11-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-6.2">an IP-based ACL and TSIG/SIG(0) combination is used.<a href="#section-11-6.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-11-7">Since this may require configuration of a number of servers who may be under
  the control of different operators, the desired consistency could be hard to
  enforce and audit in practice.<a href="#section-11-7" class="pilcrow">¶</a></p>
<p id="section-11-8">Certain aspects of the policies can be relatively easy to test independently,
  e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses
  or over cleartext DNS. Other aspects, such as if a secondary will accept data
  without a TSIG digest or if secondaries are using Strict as opposed to
  Opportunistic TLS, are more challenging.<a href="#section-11-8" class="pilcrow">¶</a></p>
<p id="section-11-9">The mechanics of coordinating or enforcing such policies are out of the scope
  of this document but may be the subject of future operational guidance.<a href="#section-11-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="implementation-considerations">
<section id="section-12">
      <h2 id="name-implementation-consideratio">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-implementation-consideratio" class="section-name selfRef">Implementation Considerations</a>
      </h2>
<p id="section-12-1">Server implementations may want to also offer options that allow ACLs on a zone
  to specify that a specific client can use either XoT or TCP. This would allow
  for flexibility while clients are migrating to XoT.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">Client implementations may similarly want to offer options to cater to the
  multi-primary case where the primaries are migrating to XoT.<a href="#section-12-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="operational-considerations">
<section id="section-13">
      <h2 id="name-operational-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
      </h2>
<p id="section-13-1">If the options described in <a href="#implementation-considerations" class="xref">Section 12</a> are
  available,
  such configuration options <span class="bcp14">MUST</span> only be used in a 'migration mode' and
  therefore should be used with great care.<a href="#section-13-1" class="pilcrow">¶</a></p>
<p id="section-13-2">It is noted that use of a TLS proxy in front of the primary server is a simple
  deployment solution that can enable server-side XoT.<a href="#section-13-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-14">
      <h2 id="name-iana-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-14-1">This document has no IANA actions.<a href="#section-14-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-15">
      <h2 id="name-security-considerations">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-15-1">This document specifies a security measure against a DNS risk: the risk that an
attacker collects entire DNS zones through eavesdropping on cleartext DNS zone
transfers.<a href="#section-15-1" class="pilcrow">¶</a></p>
<p id="section-15-2">This does not mitigate:<a href="#section-15-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-15-3.1">the risk that some level of zone activity might be inferred by observing zone
  transfer sizes and timing on encrypted connections (even with padding
  applied), in combination with obtaining SOA records by directly querying
  authoritative servers,<a href="#section-15-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-15-3.2">the risk that hidden primaries might be inferred or identified via
  observation of encrypted connections, or<a href="#section-15-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-15-3.3">the risk of zone contents being obtained via zone enumeration techniques.<a href="#section-15-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-15-4">Security concerns of DoT are outlined in <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span> and <span>[<a href="#RFC8310" class="xref">RFC8310</a>]</span>.<a href="#section-15-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-16">
      <h2 id="name-references">
<a href="#section-16" class="section-number selfRef">16. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-16.1">
        <h3 id="name-normative-references">
<a href="#section-16.1" class="section-number selfRef">16.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="DoT-ALPN">[DoT-ALPN]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tls-extensiontype-values/">https://www.iana.org/assignments/tls-extensiontype-values/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<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="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="RFC1996">[RFC1996]</dt>
        <dd>
<span class="refAuthor">Vixie, P.</span>, <span class="refTitle">"A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)"</span>, <span class="seriesInfo">RFC 1996</span>, <span class="seriesInfo">DOI 10.17487/RFC1996</span>, <time datetime="1996-08" class="refDate">August 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1996">https://www.rfc-editor.org/info/rfc1996</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2931">[RFC2931]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"DNS Request and Transaction Signatures ( SIG(0)s )"</span>, <span class="seriesInfo">RFC 2931</span>, <span class="seriesInfo">DOI 10.17487/RFC2931</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2931">https://www.rfc-editor.org/info/rfc2931</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5936">[RFC5936]</dt>
        <dd>
<span class="refAuthor">Lewis, E.</span> and <span class="refAuthor">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="RFC6973">[RFC6973]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Peterson, J.</span>, <span class="refAuthor">Morris, J.</span>, <span class="refAuthor">Hansen, M.</span>, and <span class="refAuthor">R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7766">[RFC7766]</dt>
        <dd>
<span class="refAuthor">Dickinson, J.</span>, <span class="refAuthor">Dickinson, S.</span>, <span class="refAuthor">Bellis, R.</span>, <span class="refAuthor">Mankin, A.</span>, and <span class="refAuthor">D. Wessels</span>, <span class="refTitle">"DNS Transport over TCP - Implementation Requirements"</span>, <span class="seriesInfo">RFC 7766</span>, <span class="seriesInfo">DOI 10.17487/RFC7766</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7766">https://www.rfc-editor.org/info/rfc7766</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7828">[RFC7828]</dt>
        <dd>
<span class="refAuthor">Wouters, P.</span>, <span class="refAuthor">Abley, J.</span>, <span class="refAuthor">Dickinson, S.</span>, and <span class="refAuthor">R. Bellis</span>, <span class="refTitle">"The edns-tcp-keepalive EDNS0 Option"</span>, <span class="seriesInfo">RFC 7828</span>, <span class="seriesInfo">DOI 10.17487/RFC7828</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7828">https://www.rfc-editor.org/info/rfc7828</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>, and <span class="refAuthor">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="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8310">[RFC8310]</dt>
        <dd>
<span class="refAuthor">Dickinson, S.</span>, <span class="refAuthor">Gillmor, D.</span>, and <span class="refAuthor">T. Reddy</span>, <span class="refTitle">"Usage Profiles for DNS over TLS and DNS over DTLS"</span>, <span class="seriesInfo">RFC 8310</span>, <span class="seriesInfo">DOI 10.17487/RFC8310</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8310">https://www.rfc-editor.org/info/rfc8310</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</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>, and <span class="refAuthor">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>
<dt id="RFC8914">[RFC8914]</dt>
        <dd>
<span class="refAuthor">Kumari, W.</span>, <span class="refAuthor">Hunt, E.</span>, <span class="refAuthor">Arends, R.</span>, <span class="refAuthor">Hardaker, W.</span>, and <span class="refAuthor">D. Lawrence</span>, <span class="refTitle">"Extended DNS Errors"</span>, <span class="seriesInfo">RFC 8914</span>, <span class="seriesInfo">DOI 10.17487/RFC8914</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8914">https://www.rfc-editor.org/info/rfc8914</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8945">[RFC8945]</dt>
      <dd>
<span class="refAuthor">Dupont, F.</span>, <span class="refAuthor">Morris, S.</span>, <span class="refAuthor">Vixie, P.</span>, <span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refAuthor">Gudmundsson, O.</span>, and <span class="refAuthor">B. Wellington</span>, <span class="refTitle">"Secret Key Transaction Authentication for DNS (TSIG)"</span>, <span class="seriesInfo">STD 93</span>, <span class="seriesInfo">RFC 8945</span>, <span class="seriesInfo">DOI 10.17487/RFC8945</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8945">https://www.rfc-editor.org/info/rfc8945</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-16.2">
        <h3 id="name-informative-references">
<a href="#section-16.2" class="section-number selfRef">16.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="BIND">[BIND]</dt>
        <dd>
<span class="refAuthor">ISC</span>, <span class="refTitle">"BIND 9.16.16"</span>, <span>&lt;<a href="https://www.isc.org/bind/">https://www.isc.org/bind/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-dprive-dnsoquic">[DPRIVE-DNSOQUIC]</dt>
        <dd>
<span class="refAuthor">Huitema, C.</span>, <span class="refAuthor">Dickinson, S.</span>, and <span class="refAuthor">A. Mankin</span>, <span class="refTitle">"Specification of DNS over Dedicated QUIC Connections"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dprive-dnsoquic-03</span>, <time datetime="2021-07-12" class="refDate">12 July 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03">https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NIST-GUIDE">[NIST-GUIDE]</dt>
        <dd>
<span class="refAuthor">Chandramouli, R.</span> and <span class="refAuthor">S. Rose</span>, <span class="refTitle">"Secure Domain Name System (DNS) Deployment Guide"</span>, <time datetime="2013-09" class="refDate">September 2013</time>, <span>&lt;<a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NSD">[NSD]</dt>
        <dd>
<span class="refAuthor">NLnet Labs</span>, <span class="refTitle">"NSD 4.3.6"</span>, <span>&lt;<a href="https://www.nlnetlabs.nl/projects/nsd/about/">https://www.nlnetlabs.nl/projects/nsd/about/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NSEC3-attacks">[NSEC3-attacks]</dt>
        <dd>
<span class="refAuthor">Goldberg, S.</span>, <span class="refAuthor">Naor, N.</span>, <span class="refAuthor">Papadopoulos, D.</span>, <span class="refAuthor">Reyzin, L.</span>, <span class="refAuthor">Vasant, S.</span>, and <span class="refAuthor">A. Ziv</span>, <span class="refTitle">"Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on NSEC3 Variants"</span>, <time datetime="2015-02" class="refDate">February 2015</time>, <span>&lt;<a href="https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf">https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.vcelak-nsec5">[NSEC5]</dt>
        <dd>
<span class="refAuthor">Vcelak, J.</span>, <span class="refAuthor">Goldberg, S.</span>, <span class="refAuthor">Papadopoulos, D.</span>, <span class="refAuthor">Huque, S.</span>, and <span class="refAuthor">D. Lawrence</span>, <span class="refTitle">"NSEC5, DNSSEC Authenticated Denial of Existence"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-vcelak-nsec5-08</span>, <time datetime="2018-12-29" class="refDate">29 December 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-vcelak-nsec5-08">https://datatracker.ietf.org/doc/html/draft-vcelak-nsec5-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1982">[RFC1982]</dt>
        <dd>
<span class="refAuthor">Elz, R.</span> and <span class="refAuthor">R. Bush</span>, <span class="refTitle">"Serial Number Arithmetic"</span>, <span class="seriesInfo">RFC 1982</span>, <span class="seriesInfo">DOI 10.17487/RFC1982</span>, <time datetime="1996-08" class="refDate">August 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1982">https://www.rfc-editor.org/info/rfc1982</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>, and <span class="refAuthor">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="RFC6891">[RFC6891]</dt>
        <dd>
<span class="refAuthor">Damas, J.</span>, <span class="refAuthor">Graff, M.</span>, and <span class="refAuthor">P. Vixie</span>, <span class="refTitle">"Extension Mechanisms for DNS (EDNS(0))"</span>, <span class="seriesInfo">STD 75</span>, <span class="seriesInfo">RFC 6891</span>, <span class="seriesInfo">DOI 10.17487/RFC6891</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6891">https://www.rfc-editor.org/info/rfc6891</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8484">[RFC8484]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span> and <span class="refAuthor">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="RFC8976">[RFC8976]</dt>
        <dd>
<span class="refAuthor">Wessels, D.</span>, <span class="refAuthor">Barber, P.</span>, <span class="refAuthor">Weinberg, M.</span>, <span class="refAuthor">Kumari, W.</span>, and <span class="refAuthor">W. Hardaker</span>, <span class="refTitle">"Message Digest for DNS Zones"</span>, <span class="seriesInfo">RFC 8976</span>, <span class="seriesInfo">DOI 10.17487/RFC8976</span>, <time datetime="2021-02" class="refDate">February 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8976">https://www.rfc-editor.org/info/rfc8976</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9076">[RFC9076]</dt>
        <dd>
<span class="refAuthor">Wicinski, T., Ed.</span>, <span class="refTitle">"DNS Privacy Considerations"</span>, <span class="seriesInfo">RFC 9076</span>, <span class="seriesInfo">DOI 10.17487/RFC9076</span>, <time datetime="2021-07" class="refDate">July 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9076">https://www.rfc-editor.org/info/rfc9076</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tls-esni">[TLS-ESNI]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Oku, K.</span>, <span class="refAuthor">Sullivan, N.</span>, and <span class="refAuthor">C. A. Wood</span>, <span class="refTitle">"TLS Encrypted Client Hello"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tls-esni-13</span>, <time datetime="2021-08-12" class="refDate">12 August 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13">https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="xot-server-connection-handling">
<section id="appendix-A">
      <h2 id="name-xot-server-connection-handl">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-xot-server-connection-handl" class="section-name selfRef">XoT Server Connection Handling</a>
      </h2>
<p id="appendix-A-1">This appendix provides a non-normative outline of the pros and cons of XoT server
  connection-handling options.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">For completeness, it is noted that an earlier draft version of this document
  suggested using a XoT-specific ALPN to negotiate TLS connections that supported
  only a limited set of queries (SOA, XFRs); however, this did not gain support.
  Reasons given included additional code complexity and the fact that XoT and ADoT are both
  DNS wire format and so should share the <code>dot</code> ALPN.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<div id="only-listen-on-tls-on-a-specific-ip-address">
<section id="appendix-A.1">
        <h3 id="name-listening-only-on-a-specifi">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-listening-only-on-a-specifi" class="section-name selfRef">Listening Only on a Specific IP Address for TLS</a>
        </h3>
<p id="appendix-A.1-1">Obviously, a name server that hosts a zone and services queries for the zone on
  an IP address published in an NS record may wish to use a separate IP address
  for XoT to listen for TLS, only publishing that address to its secondaries.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.1-2">
          <dt id="appendix-A.1-2.1">Pros:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.2">Probing of the public IP address will show no support for TLS. ACLs will
    prevent zone transfer on all transports on a per-query basis.<a href="#appendix-A.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.1-2.3">Cons:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.1-2.4">Attackers passively observing traffic will still be able to observe TLS
    connections to the separate address.<a href="#appendix-A.1-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="client-specific-tls-acceptance">
<section id="appendix-A.2">
        <h3 id="name-client-specific-tls-accepta">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-client-specific-tls-accepta" class="section-name selfRef">Client-Specific TLS Acceptance</a>
        </h3>
<p id="appendix-A.2-1">Primaries that include IP-based ACLs and/or mutual TLS in their authentication models
  have the option of only accepting TLS connections from authorized clients. This
  could be implemented either using a proxy or directly in the DNS implementation.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.2-2">
          <dt id="appendix-A.2-2.1">Pros:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.2-2.2">Connection management happens at setup time. The maximum number of TLS
    connections a server will have to support can be easily assessed. Once the
    connection is accepted, the server might well be willing to answer any query on
    that connection since it is coming from a configured secondary, and a specific
    response policy on the connection may not be needed (see below).<a href="#appendix-A.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.2-2.3">Cons:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.2-2.4">Currently, none of the major open-source 
    implementations of a DNS authoritative server support such an option.<a href="#appendix-A.2-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sni-based-tls-acceptance">
<section id="appendix-A.3">
        <h3 id="name-sni-based-tls-acceptance">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-sni-based-tls-acceptance" class="section-name selfRef">SNI-Based TLS Acceptance</a>
        </h3>
<p id="appendix-A.3-1">Primaries could also choose to only accept TLS connections based on a Server Name
  Indication (SNI) that was published only to their secondaries.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.3-2">
          <dt id="appendix-A.3-2.1">Pros:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.3-2.2">Reduces the number of accepted connections.<a href="#appendix-A.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.3-2.3">Cons:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.3-2.4">As above. Also, this is not a recommended use of SNI. For SNIs sent in the
    clear, this would still allow attackers passively observing traffic to
    potentially abuse this mechanism. The use of Encrypted Client Hello
    <span>[<a href="#I-D.ietf-tls-esni" class="xref">TLS-ESNI</a>]</span> may be of use here.<a href="#appendix-A.3-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="transport-specific-response-policies">
<section id="appendix-A.4">
        <h3 id="name-transport-specific-response">
<a href="#appendix-A.4" class="section-number selfRef">A.4. </a><a href="#name-transport-specific-response" class="section-name selfRef">Transport-Specific Response Policies</a>
        </h3>
<p id="appendix-A.4-1">Some primaries might rely on TSIG/SIG(0) combined with per-query, IP-based
  ACLs to authenticate secondaries. In this case, the primary must accept all
  incoming TLS/TCP connections and then apply a transport-specific response policy on a
  per-query basis.<a href="#appendix-A.4-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4-2">As an aside, whilst <span>[<a href="#RFC7766" class="xref">RFC7766</a>]</span> makes a general purpose distinction in
  the advice to clients
  about their usage of connections (between regular queries and zone transfers), this is
  not strict, and nothing in the DNS protocol prevents using the same connection
  for both types of traffic. Hence, a server cannot know the intention of any
  client that connects to it; it can only inspect the messages it receives on
  such a connection and make per-query decisions about whether or not to answer
  those queries.<a href="#appendix-A.4-2" class="pilcrow">¶</a></p>
<p id="appendix-A.4-3">Example policies a XoT server might implement are:<a href="#appendix-A.4-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.4-4">
          <dt id="appendix-A.4-4.1">strict:</dt>
          <dd style="margin-left: 6.0em" id="appendix-A.4-4.2">REFUSE all queries on TLS connections, except SOA and authorized XFR requests<a href="#appendix-A.4-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.4-4.3">moderate:</dt>
          <dd style="margin-left: 6.0em" id="appendix-A.4-4.4">REFUSE all queries on TLS connections until one is received that is
    signed by a recognized TSIG/SIG(0) key, then answer all queries on the
    connection after that<a href="#appendix-A.4-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.4-4.5">complex:</dt>
          <dd style="margin-left: 6.0em" id="appendix-A.4-4.6">apply a heuristic to determine which queries on a TLS connections to REFUSE<a href="#appendix-A.4-4.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.4-4.7">relaxed:</dt>
          <dd style="margin-left: 6.0em" id="appendix-A.4-4.8">answer all non-XoT queries on all TLS connections with the same policy applied to TCP
    queries<a href="#appendix-A.4-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel" id="appendix-A.4-5">
          <dt id="appendix-A.4-5.1">Pros:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.4-5.2">Allows for flexible behavior by the server that could be changed over time.<a href="#appendix-A.4-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="appendix-A.4-5.3">Cons:</dt>
          <dd style="margin-left: 1.5em" id="appendix-A.4-5.4">The server must handle the burden of accepting all TLS connections just
    to perform XFRs with a small number of secondaries. Client behavior to a REFUSED
    response is not clearly defined (see <a href="#response-rcodes" class="xref">Section 7.8</a>). Currently,
    none of the major open-source implementations of a DNS authoritative server offer an option for different response
    policies in different transports (but such functionality could potentially be implemented
    using a proxy).<a href="#appendix-A.4-5.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div id="sni-based-response-policies">
<section id="appendix-A.4.1">
          <h4 id="name-sni-based-response-policies">
<a href="#appendix-A.4.1" class="section-number selfRef">A.4.1. </a><a href="#name-sni-based-response-policies" class="section-name selfRef">SNI-Based Response Policies</a>
          </h4>
<p id="appendix-A.4.1-1">In a similar fashion, XoT servers might use the presence of an SNI in the
  Client Hello to determine which response policy to initially apply to the TLS
  connections.<a href="#appendix-A.4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.4.1-2">
            <dt id="appendix-A.4.1-2.1">Pros:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A.4.1-2.2">This has the potential to allow a clean distinction between a XoT service
    and any future DoT-based service for answering recursive queries.<a href="#appendix-A.4.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A.4.1-2.3">Cons:</dt>
            <dd style="margin-left: 1.5em" id="appendix-A.4.1-2.4">As above.<a href="#appendix-A.4.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="acknowledgements">
<section id="appendix-B">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-B-1">The authors thank <span class="contact-name">Tony Finch</span>, <span class="contact-name">Benno   Overeinder</span>, <span class="contact-name">Shumon Huque</span>,
  <span class="contact-name">Tim Wicinski</span>, and many other members of DPRIVE for review and
  discussions.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">The authors particularly thank <span class="contact-name">Peter van Dijk</span>, 
  <span class="contact-name">Ondrej Sury</span>, <span class="contact-name">Brian Dickson</span>, and
  several other open-source DNS implementers for valuable discussion and
  clarification on the issue associated with pipelining XFR queries and handling
  out-of-order/intermingled responses.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contributors">
<section id="appendix-C">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-C-1">Significant contributions to the document were made by:<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Han Zhang</span></div>
<div dir="auto" class="left"><span class="org">Salesforce</span></div>
<div dir="auto" class="left">
<span class="locality">San Francisco</span>, <span class="region">CA</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:hzhang@salesforce.com" class="email">hzhang@salesforce.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-D">
      <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">Willem Toorop</span></div>
<div dir="auto" class="left"><span class="org">NLnet Labs</span></div>
<div dir="auto" class="left"><span class="street-address">Science Park 400</span></div>
<div dir="auto" class="left">
<span class="postal-code">1098 XH</span> <span class="locality">Amsterdam</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:willem@nlnetlabs.nl" class="email">willem@nlnetlabs.nl</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sara Dickinson</span></div>
<div dir="auto" class="left"><span class="org">Sinodun IT</span></div>
<div dir="auto" class="left"><span class="extended-address">Magdalen Centre</span></div>
<div dir="auto" class="left"><span class="street-address">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:sara@sinodun.com" class="email">sara@sinodun.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Shivan Sahib</span></div>
<div dir="auto" class="left"><span class="org">Brave Software</span></div>
<div dir="auto" class="left">
<span class="locality">Vancouver</span> <span class="region">BC</span> </div>
<div dir="auto" class="left"><span class="country-name">Canada</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:shivankaulsahib@gmail.com" class="email">shivankaulsahib@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="locality">Herndon</span>, <span class="region">VA</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">Allison Mankin</span></div>
<div dir="auto" class="left"><span class="org">Salesforce</span></div>
<div dir="auto" class="left">
<span class="locality">Herndon</span>, <span class="region">VA</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:allison.mankin@gmail.com" class="email">allison.mankin@gmail.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>