File: rfc8945.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2880 lines) | stat: -rw-r--r-- 144,099 bytes
<!DOCTYPE html>
<html lang="en" class="RFC STD">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8945: Secret Key Transaction Authentication for DNS (TSIG)</title>
<meta content="Francis Dupont" name="author">
<meta content="Stephen Morris" name="author">
<meta content="Paul Vixie" name="author">
<meta content="Donald E. Eastlake 3rd" name="author">
<meta content="Olafur Gudmundsson" name="author">
<meta content="Brian Wellington" name="author">
<meta content="
       This document describes a protocol for transaction-level authentication
      using shared secrets and one-way hashing.  It can be used to authenticate
      dynamic updates to a DNS zone as coming from an approved client or to
      authenticate responses as coming from an approved name server. 
       No recommendation is made here for distributing the shared secrets;
      it is expected that a network administrator will statically configure
      name servers and clients using some out-of-band mechanism. 
       This document obsoletes RFCs 2845 and 4635. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="8945" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    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="rfc8945.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8945" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis-09" 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 8945</td>
<td class="center">DNS TSIG</td>
<td class="right">November 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dupont, 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/rfc8945" class="eref">8945</a></dd>
<dt class="label-std">STD:</dt>
<dd class="std">93</dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc2845" class="eref">2845</a>, <a href="https://www.rfc-editor.org/rfc/rfc4635" class="eref">4635</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="2020-11" class="published">November 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">F. Dupont</div>
<div class="org">ISC</div>
</div>
<div class="author">
      <div class="author-name">S. Morris</div>
<div class="org">Unaffiliated</div>
</div>
<div class="author">
      <div class="author-name">P. Vixie</div>
<div class="org">Farsight</div>
</div>
<div class="author">
      <div class="author-name">D. Eastlake 3rd</div>
<div class="org">Futurewei</div>
</div>
<div class="author">
      <div class="author-name">O. Gudmundsson</div>
<div class="org">Cloudflare</div>
</div>
<div class="author">
      <div class="author-name">B. Wellington</div>
<div class="org">Akamai</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8945</h1>
<h1 id="title">Secret Key Transaction Authentication for DNS (TSIG)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes a protocol for transaction-level authentication
      using shared secrets and one-way hashing.  It can be used to authenticate
      dynamic updates to a DNS zone as coming from an approved client or to
      authenticate responses as coming from an approved name server.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">No recommendation is made here for distributing the shared secrets;
      it is expected that a network administrator will statically configure
      name servers and clients using some out-of-band mechanism.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">This document obsoletes RFCs 2845 and 4635.<a href="#section-abstract-3" 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/rfc8945">https://www.rfc-editor.org/info/rfc8945</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the copyright in some of this
            material may not have granted the IETF Trust the right to allow
            modifications of such material outside the IETF Standards Process.
            Without obtaining an adequate license from the person(s)
            controlling the copyright in such materials, this document may not
            be modified outside the IETF Standards Process, and derivative
            works of it may not be created outside the IETF Standards Process,
            except to format it for publication as an RFC or to translate it
            into languages other than English.<a href="#section-boilerplate.2-3" 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="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-background" class="xref">Background</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-document-history" class="xref">Document History</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-key-words" class="xref">Key Words</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-assigned-numbers" class="xref">Assigned Numbers</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-tsig-rr-format" class="xref">TSIG RR Format</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-tsig-rr-type" class="xref">TSIG RR Type</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-tsig-record-format" class="xref">TSIG Record Format</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-mac-computation" class="xref">MAC Computation</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3.2.1">
                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-request-mac" class="xref">Request MAC</a><a href="#section-toc.1-1.4.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3.2.2">
                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-dns-message" class="xref">DNS Message</a><a href="#section-toc.1-1.4.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3.2.3">
                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-tsig-variables" class="xref">TSIG Variables</a><a href="#section-toc.1-1.4.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-protocol-details" class="xref">Protocol Details</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-generation-of-tsig-on-reque" class="xref">Generation of TSIG on Requests</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" 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-server-processing-of-reques" class="xref">Server Processing of Request</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-key-check-and-error-handlin" class="xref">Key Check and Error Handling</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-mac-check-and-error-handlin" class="xref">MAC Check and Error Handling</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-time-check-and-error-handli" class="xref">Time Check and Error Handling</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2.2.4">
                    <p id="section-toc.1-1.5.2.2.2.4.1"><a href="#section-5.2.4" class="xref">5.2.4</a>.  <a href="#name-truncation-check-and-error-" class="xref">Truncation Check and Error Handling</a><a href="#section-toc.1-1.5.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty toc compact" 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-generation-of-tsig-on-answe" class="xref">Generation of TSIG on Answers</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" 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-tsig-on-tcp-connections" class="xref">TSIG on TCP Connections</a><a href="#section-toc.1-1.5.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" 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-generation-of-tsig-on-error" class="xref">Generation of TSIG on Error Returns</a><a href="#section-toc.1-1.5.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-client-processing-of-answer" class="xref">Client Processing of Answer</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4.2.1">
                    <p id="section-toc.1-1.5.2.4.2.1.1"><a href="#section-5.4.1" class="xref">5.4.1</a>.  <a href="#name-key-error-handling" class="xref">Key Error Handling</a><a href="#section-toc.1-1.5.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4.2.2">
                    <p id="section-toc.1-1.5.2.4.2.2.1"><a href="#section-5.4.2" class="xref">5.4.2</a>.  <a href="#name-mac-error-handling" class="xref">MAC Error Handling</a><a href="#section-toc.1-1.5.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4.2.3">
                    <p id="section-toc.1-1.5.2.4.2.3.1"><a href="#section-5.4.3" class="xref">5.4.3</a>.  <a href="#name-time-error-handling" class="xref">Time Error Handling</a><a href="#section-toc.1-1.5.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.4.2.4">
                    <p id="section-toc.1-1.5.2.4.2.4.1"><a href="#section-5.4.4" class="xref">5.4.4</a>.  <a href="#name-truncation-error-handling" class="xref">Truncation Error Handling</a><a href="#section-toc.1-1.5.2.4.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-special-considerations-for-" class="xref">Special Considerations for Forwarding Servers</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-algorithms-and-identifiers" class="xref">Algorithms and Identifiers</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-tsig-truncation-policy" class="xref">TSIG Truncation Policy</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-shared-secrets" class="xref">Shared Secrets</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-issue-fixed-in-this-documen" class="xref">Issue Fixed in This Document</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-why-not-dnssec" class="xref">Why Not DNSSEC?</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" 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-references" class="xref">References</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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>
<section id="section-1.1">
        <h3 id="name-background">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-background" class="section-name selfRef">Background</a>
        </h3>
<p id="section-1.1-1">The Domain Name System (DNS) (<span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>) is a
 replicated hierarchical distributed 
        database system that provides information fundamental to Internet
        operations, such as name-to-address translation and mail-handling
 information.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">This document specifies use of a message authentication code
        (MAC), generated using certain keyed hash functions, to
        provide an efficient means of point-to-point authentication and
        integrity checking for DNS transactions. Such transactions include
        DNS update requests and responses for which this can provide a lightweight
        alternative to the secure DNS dynamic update protocol described by
 <span>[<a href="#RFC3007" class="xref">RFC3007</a>]</span>.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">A further use of this mechanism is to protect zone transfers.
        In this case, the data covered would be the whole zone transfer
        including any glue records sent.  The protocol described by DNSSEC
        (<span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span>, <span>[<a href="#RFC4034" class="xref">RFC4034</a>]</span>,
        <span>[<a href="#RFC4035" class="xref">RFC4035</a>]</span>) does not protect glue records and unsigned
        records.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">The authentication mechanism proposed here provides a
        simple and efficient authentication between clients and servers,
        by using shared secret keys to establish a trust relationship between
        two entities.  Such keys must be protected in a manner similar to
        private keys, lest a third party masquerade as one of the intended
        parties (by forging the MAC).  The proposal is unsuitable for general
        server-to-server authentication and for servers that speak with many
        other servers, since key management would become unwieldy with the
        number of shared keys going up quadratically. But it is suitable for
        many resolvers on hosts that only talk to a few recursive servers.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-1.2">
        <h3 id="name-protocol-overview">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
        </h3>
<p id="section-1.2-1">Secret Key Transaction Authentication makes use of signatures
         on messages sent between the parties involved (e.g., resolver and
         server).  These are known as "transaction signatures", or TSIG.
         For historical reasons, in this document, they are referred to as
         message authentication codes (MACs).<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">Use of TSIG presumes prior agreement between the
         two parties involved (e.g., resolver and server) as to any
         algorithm and key to be used.  The way that this agreement
         is reached is outside the scope of the document.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">A DNS message exchange involves the sending of a query and the
         receipt of one of more DNS messages in response.  For
         the query, the MAC is calculated based on the hash of the contents
         and the agreed TSIG key.  The MAC for the response is similar but
         also includes the MAC of the query as part of the calculation.
         Where a response comprises multiple packets, the calculation of
         the MAC associated with the second and subsequent packets includes in
         its inputs the MAC for the preceding packet.
         In this way, it is possible to detect any interruption in the
         packet sequence, although not its premature termination.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<p id="section-1.2-4">The MAC is contained in a TSIG resource record included
         in the additional section of the DNS message.<a href="#section-1.2-4" class="pilcrow">¶</a></p>
</section>
<section id="section-1.3">
        <h3 id="name-document-history">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-document-history" class="section-name selfRef">Document History</a>
        </h3>
<p id="section-1.3-1">TSIG was originally specified by <span>[<a href="#RFC2845" class="xref">RFC2845</a>]</span>.
         In 2017, two name server implementations strictly following that document (and
         the related  <span>[<a href="#RFC4635" class="xref">RFC4635</a>]</span>) were discovered to have
         security problems related to this feature (<span>[<a href="#CVE-2017-3142" class="xref">CVE-2017-3142</a>]</span>, 
         <span>[<a href="#CVE-2017-3143" class="xref">CVE-2017-3143</a>]</span>, <span>[<a href="#CVE-2017-11104" class="xref">CVE-2017-11104</a>]</span>).  The implementations 
         were fixed, but to avoid similar problems in the future, the
         two documents were updated and merged, producing this revised
         specification for TSIG.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">While TSIG implemented according to this RFC provides for enhanced
         security, there are no changes in interoperability. TSIG on the wire
         is still the same mechanism described in <span>[<a href="#RFC2845" class="xref">RFC2845</a>]</span>; only the checking semantics have been
  changed. 

  See <a href="#issuesfixed" class="xref">Section 10.1</a> for
 further details.<a href="#section-1.3-2" class="pilcrow">¶</a></p>
</section>
</section>
<div id="keywords">
<section id="section-2">
      <h2 id="name-key-words">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-key-words" class="section-name selfRef">Key Words</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>
</section>
</div>
<div id="numbers">
<section id="section-3">
      <h2 id="name-assigned-numbers">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-assigned-numbers" class="section-name selfRef">Assigned Numbers</a>
      </h2>
<p id="section-3-1">This document defines the following Resource Record (RR) type and
      associated value:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-3-2.1">TSIG (250)<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">In addition, the document also defines the following DNS RCODEs
      and associated names:<a href="#section-3-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-3-4.1">16 (BADSIG)<a href="#section-3-4.1" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-3-4.2">17 (BADKEY)<a href="#section-3-4.2" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-3-4.3">18 (BADTIME)<a href="#section-3-4.3" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-3-4.4">22 (BADTRUNC)<a href="#section-3-4.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-5">(See <span><a href="https://www.rfc-editor.org/rfc/rfc6895#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC6895" class="xref">RFC6895</a>]</span>
      concerning the assignment of the value 16 to BADSIG.)<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">These RCODES may appear within the "Error" field of a TSIG RR.<a href="#section-3-6" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4">
      <h2 id="name-tsig-rr-format">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-tsig-rr-format" class="section-name selfRef">TSIG RR Format</a>
      </h2>
<section id="section-4.1">
        <h3 id="name-tsig-rr-type">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-tsig-rr-type" class="section-name selfRef">TSIG RR Type</a>
        </h3>
<p id="section-4.1-1">To provide secret key authentication, we use an RR
        type whose mnemonic is TSIG and whose type code is 250.
        TSIG is a meta-RR and <span class="bcp14">MUST NOT</span> be cached.  TSIG RRs are
        used for authentication between DNS entities that have
        established a shared secret key.  TSIG RRs are dynamically
        computed to cover a particular DNS transaction and are not
        DNS RRs in the usual sense.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">As the TSIG RRs are related to one DNS request/response,
        there is no value in storing or retransmitting them; thus, the
        TSIG RR is discarded once it has been used to authenticate a DNS
        message.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
</section>
<div id="format">
<section id="section-4.2">
        <h3 id="name-tsig-record-format">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-tsig-record-format" class="section-name selfRef">TSIG Record Format</a>
        </h3>
<p id="section-4.2-1">The fields of the TSIG RR are described below.  All multi-octet integers in the record are sent in network byte
        order (see <span><a href="https://www.rfc-editor.org/rfc/rfc1035#section-2.3.2" class="relref">Section 2.3.2</a> of [<a href="#RFC1035" class="xref">RFC1035</a>]</span>).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-2">
          <dt id="section-4.2-2.1">NAME:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.2">
            <p id="section-4.2-2.2.1">The name of the key used, in domain
          name syntax.  The name should reflect the names of the
          hosts and uniquely identify the key among a set of keys
          these two hosts may share at any given time.  For example,
          if hosts
          A.site.example and B.example.net share a key, possibilities
          for the key name include &lt;id&gt;.A.site.example,
          &lt;id&gt;.B.example.net, and
          &lt;id&gt;.A.site.example.B.example.net.  It should be
          possible for more than one key to be in simultaneous use
          among a set of interacting hosts. This allows for periodic
          key rotation as per best operational practices, as well as
          algorithm agility as indicated by <span>[<a href="#RFC7696" class="xref">RFC7696</a>]</span>.<a href="#section-4.2-2.2.1" class="pilcrow">¶</a></p>
<p id="section-4.2-2.2.2">The name may be used as a local index
          to the key involved, but it is recommended that it be
          globally unique.  Where a key is just shared between two
          hosts, its name actually need only be meaningful to
          them, but it is recommended that the key name be mnemonic
          and incorporate the names of participating agents or
          resources as suggested above.<a href="#section-4.2-2.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.3">TYPE:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.4">This <span class="bcp14">MUST</span> be TSIG (250: Transaction SIGnature).<a href="#section-4.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.5">CLASS:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.6">This <span class="bcp14">MUST</span> be ANY.<a href="#section-4.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.7">TTL:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.8">This <span class="bcp14">MUST</span> be 0.<a href="#section-4.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.9">RDLENGTH:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.10">(variable)<a href="#section-4.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-2.11">RDATA:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-2.12">The RDATA for a TSIG RR consists of a
          number of fields, described below:<a href="#section-4.2-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div class="artwork art-text alignLeft" id="section-4.2-3">
<pre>
                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                         Algorithm Name                        /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |          Time Signed          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |            Fudge              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          MAC Size             |                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             MAC               /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Original ID          |            Error              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Other Len            |                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Other Data          /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre><a href="#section-4.2-3" class="pilcrow">¶</a>
</div>
<p id="section-4.2-4">The contents of the RDATA fields are:<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4.2-5">
          <dt id="section-4.2-5.1">Algorithm Name:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.2">an octet sequence identifying the TSIG algorithm in the
   domain name syntax. (Allowed names are listed in <a href="#allowed-algorithms" class="xref">Table 3</a>.) The name is stored
   in the DNS name wire format as described in <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span>. As per <span>[<a href="#RFC3597" class="xref">RFC3597</a>]</span>, this name <span class="bcp14">MUST NOT</span> be
   compressed.<a href="#section-4.2-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.3">Time Signed:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.4">an unsigned 48-bit integer containing the time the message was
   signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
   seconds.<a href="#section-4.2-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.5">Fudge:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.6">an unsigned 16-bit integer specifying the allowed time
   difference in seconds permitted in the Time Signed field.<a href="#section-4.2-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.7">MAC Size:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.8">an unsigned 16-bit integer giving the length of the MAC field in
   octets.  Truncation is indicated by a MAC Size less than the size of
   the keyed hash produced by the algorithm specified by the Algorithm
   Name.<a href="#section-4.2-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.9">MAC:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.10">a sequence of octets whose contents are defined by the TSIG
   algorithm used, possibly truncated as specified by the MAC Size. The
   length of this field is given by the MAC Size. Calculation of the
   MAC is detailed in <a href="#mac_computation" class="xref">Section 4.3</a>.<a href="#section-4.2-5.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.11">Original ID:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.12">an unsigned 16-bit integer holding the message ID of the
   original request message. For a TSIG RR on a request, it is set
   equal to the DNS message ID. In a TSIG attached to a response -- or
   in cases such as the forwarding of a dynamic update request -- the
   field contains the ID of the original DNS request.<a href="#section-4.2-5.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.13">Error:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.14">in responses, an unsigned 16-bit integer containing the extended
   RCODE covering TSIG processing.  In requests, this
   <span class="bcp14">MUST</span> be zero.<a href="#section-4.2-5.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.15">Other Len:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.16">an unsigned 16-bit integer specifying the length of the Other
   Data field in octets.<a href="#section-4.2-5.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-5.17">Other Data:</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-5.18">additional data relevant to the TSIG record. In responses, this
   will be empty (i.e., Other Len will be zero) unless the content of
   the Error field is BADTIME, in which case it will be a 48-bit
   unsigned integer containing the server's current time as the number
   of seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds (see
   <a href="#time_check" class="xref">Section 5.2.3</a>). This document assigns
   no meaning to its contents in requests.<a href="#section-4.2-5.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="mac_computation">
<section id="section-4.3">
        <h3 id="name-mac-computation">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-mac-computation" class="section-name selfRef">MAC Computation</a>
        </h3>
<p id="section-4.3-1">When generating or verifying the contents of a TSIG record,
        the data listed in the rest of this section are passed,
        in the order listed below, as input to MAC computation.  The
        data are passed in network byte order or wire format,
        as appropriate and are fed into the hashing function
        as a continuous octet sequence with no interfield separator or
        padding.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<section id="section-4.3.1">
          <h4 id="name-request-mac">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-request-mac" class="section-name selfRef">Request MAC</a>
          </h4>
<p id="section-4.3.1-1">Only included in the computation of a MAC for a response message
          (or the first message in a multi-message response),
          the validated request MAC <span class="bcp14">MUST</span> be included in the MAC
          computation.  If the request MAC failed to validate, an unsigned
          error message <span class="bcp14">MUST</span> be returned instead (<a href="#on_error" class="xref">Section 5.3.2</a>).<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
<p id="section-4.3.1-2">The request's MAC, comprising the following fields, is digested in
          wire format:<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
<span id="name-requests-mac"></span><div id="mac-field">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-requests-mac" class="selfRef">Request's MAC</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Field</th>
                <th class="text-left" rowspan="1" colspan="1">Type</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MAC Size</td>
                <td class="text-left" rowspan="1" colspan="1">Unsigned 16-bit integer</td>
                <td class="text-left" rowspan="1" colspan="1">in network byte order</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MAC Data</td>
                <td class="text-left" rowspan="1" colspan="1">octet sequence</td>
                <td class="text-left" rowspan="1" colspan="1">exactly as transmitted</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-4.3.1-4">Special considerations apply to the TSIG calculation for the
   second and subsequent messages in a response that consists of multiple
   DNS messages (e.g., a zone transfer). 
  
   These are described in <a href="#tcp" class="xref">Section 5.3.1</a>.<a href="#section-4.3.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3.2">
          <h4 id="name-dns-message">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-dns-message" class="section-name selfRef">DNS Message</a>
          </h4>
<p id="section-4.3.2-1">In the MAC computation, the whole/complete DNS message in
   wire format is used.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<p id="section-4.3.2-2">When creating an outgoing message, the TSIG is based on
   the message content before
the TSIG
   RR has been added to the additional section and before the
   DNS Message Header's ARCOUNT has been incremented to include
   the TSIG RR.<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
<p id="section-4.3.2-3">When verifying an incoming message, the TSIG is checked against
   the message after the TSIG RR has been removed, the ARCOUNT 
   decremented, and the message ID replaced by the original message
   ID from the TSIG if those IDs differ.  (This could happen, for
   example, when forwarding a dynamic update request.)<a href="#section-4.3.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3.3">
          <h4 id="name-tsig-variables">
<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-tsig-variables" class="section-name selfRef">TSIG Variables</a>
          </h4>
<p id="section-4.3.3-1">Also included in the digest is certain information present
          in the TSIG RR.  Adding this data provides further protection against an
          attempt to interfere with the message.<a href="#section-4.3.3-1" class="pilcrow">¶</a></p>
<span id="name-tsig-variables-2"></span><div id="tisg-field-names">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-tsig-variables-2" class="selfRef">TSIG Variables</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Source</th>
                <th class="text-left" rowspan="1" colspan="1">Field Name</th>
                <th class="text-left" rowspan="1" colspan="1">Notes</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RR</td>
                <td class="text-left" rowspan="1" colspan="1">NAME</td>
                <td class="text-left" rowspan="1" colspan="1">Key name, in canonical wire format</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RR</td>
                <td class="text-left" rowspan="1" colspan="1">CLASS</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span class="bcp14">MUST</span> be ANY</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RR</td>
                <td class="text-left" rowspan="1" colspan="1">TTL</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span class="bcp14">MUST</span> be 0</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Algorithm Name</td>
                <td class="text-left" rowspan="1" colspan="1">in canonical wire format</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Time Signed</td>
                <td class="text-left" rowspan="1" colspan="1">in network byte order</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Fudge</td>
                <td class="text-left" rowspan="1" colspan="1">in network byte order</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Error</td>
                <td class="text-left" rowspan="1" colspan="1">in network byte order</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Other Len</td>
                <td class="text-left" rowspan="1" colspan="1">in network byte order</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">TSIG RDATA</td>
                <td class="text-left" rowspan="1" colspan="1">Other Data</td>
                <td class="text-left" rowspan="1" colspan="1">exactly as transmitted</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-4.3.3-3">The RR RDLENGTH and RDATA MAC Size are not included in the
          input to MAC computation, since they are not guaranteed to be
          knowable before the MAC is generated.<a href="#section-4.3.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3.3-4">The Original ID field is not included in this section,
          as it has already been substituted for the message ID in
          the DNS header and hashed.<a href="#section-4.3.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3.3-5">For each label type, there must be a defined "Canonical
          wire format" that specifies how to express a label in an
          unambiguous way.  For label type 00, this is defined in <span><a href="https://www.rfc-editor.org/rfc/rfc4034#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC4034" class="xref">RFC4034</a>]</span>.  The use of
   label types other than 00 is not defined for this specification.<a href="#section-4.3.3-5" class="pilcrow">¶</a></p>
<section id="section-4.3.3.1">
            <h5 id="name-time-values-used-in-tsig-ca">
<a href="#section-4.3.3.1" class="section-number selfRef">4.3.3.1. </a><a href="#name-time-values-used-in-tsig-ca" class="section-name selfRef">Time Values Used in TSIG Calculations</a>
            </h5>
<p id="section-4.3.3.1-1">The data digested includes the two timer values in the
            TSIG header in order to defend against replay attacks.  If
            this were not done, an attacker could replay old messages
            but update the Time Signed and Fudge fields to make the
            message look new.  The two fields are collectively named "TSIG Timers", and
            for the purpose of MAC calculation, they are hashed in
            their wire format, in the following order: first
            Time Signed, then Fudge.<a href="#section-4.3.3.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
</section>
<div id="details">
<section id="section-5">
      <h2 id="name-protocol-details">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-protocol-details" class="section-name selfRef">Protocol Details</a>
      </h2>
<section id="section-5.1">
        <h3 id="name-generation-of-tsig-on-reque">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-generation-of-tsig-on-reque" class="section-name selfRef">Generation of TSIG on Requests</a>
        </h3>
<p id="section-5.1-1">Once the outgoing record has been constructed, the client performs
 the keyed hash (Hashed Message Authentication Code (HMAC))
 computation, appends a TSIG record with the 
 calculated MAC to the additional section (incrementing the
 ARCOUNT to reflect the additional RR), and transmits the request to
 the server.  This TSIG record <span class="bcp14">MUST</span> be the only TSIG RR
 in the message and <span class="bcp14">MUST</span> be the last record in the
 additional data section. The client <span class="bcp14">MUST</span> store the MAC
 and the key name from the request while awaiting an answer.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">The digest components for a request are:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-5.1-3.1">DNS Message (request)<a href="#section-5.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty compact" id="section-5.1-3.2">TSIG Variables (request)<a href="#section-5.1-3.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<div id="request_processing">
<section id="section-5.2">
        <h3 id="name-server-processing-of-reques">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-server-processing-of-reques" class="section-name selfRef">Server Processing of Request</a>
        </h3>
<p id="section-5.2-1">If an incoming message contains a TSIG record, it <span class="bcp14">MUST</span>
        be the last record in the additional section.  Multiple
        TSIG records are not allowed.  If multiple TSIG records are detected
        or a TSIG record is present
        in any other position, the DNS message is dropped and a response
        with RCODE 1 (FORMERR) <span class="bcp14">MUST</span> be returned.  Upon receipt of
        a message with exactly one correctly placed TSIG RR, a copy of the
        TSIG RR is stored and the TSIG RR is removed from the DNS message
        and decremented out of the DNS message header's ARCOUNT.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">If the TSIG RR cannot be interpreted, the server <span class="bcp14">MUST</span>
        regard the message as corrupt and return a FORMERR to the server.
        Otherwise, the server is <span class="bcp14">REQUIRED</span> to return a TSIG RR in
        the response.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">To validate the received TSIG RR, the server <span class="bcp14">MUST</span> perform the
        following checks in the following order:<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.2-4">
           <li id="section-5.2-4.1">Check key<a href="#section-5.2-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-4.2">Check MAC<a href="#section-5.2-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-4.3">Check time values<a href="#section-5.2-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-4.4">Check truncation policy<a href="#section-5.2-4.4" class="pilcrow">¶</a>
</li>
        </ol>
<section id="section-5.2.1">
          <h4 id="name-key-check-and-error-handlin">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-key-check-and-error-handlin" class="section-name selfRef">Key Check and Error Handling</a>
          </h4>
<p id="section-5.2.1-1">If a non-forwarding server does not recognize the key or
   algorithm used by the client (or recognizes the algorithm but does
   not implement it), the server <span class="bcp14">MUST</span> generate an error
   response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This
   response <span class="bcp14">MUST</span> be unsigned as specified in <a href="#on_error" class="xref">Section 5.3.2</a>. The server
   <span class="bcp14">SHOULD</span> log the error. (Special considerations apply
   to forwarding servers; see <a href="#forwarding" class="xref">Section 5.5</a>.)<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2.2">
          <h4 id="name-mac-check-and-error-handlin">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-mac-check-and-error-handlin" class="section-name selfRef">MAC Check and Error Handling</a>
          </h4>
<p id="section-5.2.2-1">Using the information in the TSIG, the server <span class="bcp14">MUST</span> verify
          the MAC by doing its own calculation and comparing the result with
          the MAC received. If the MAC fails to
          verify, the server <span class="bcp14">MUST</span> generate an
          error response as specified in <a href="#on_error" class="xref">Section 5.3.2</a> with
          RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG).  This response
          <span class="bcp14">MUST</span> be unsigned, as specified in <a href="#on_error" class="xref">Section 5.3.2</a>. 
          The server <span class="bcp14">SHOULD</span> log the error.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<div id="trunc">
<section id="section-5.2.2.1">
            <h5 id="name-mac-truncation">
<a href="#section-5.2.2.1" class="section-number selfRef">5.2.2.1. </a><a href="#name-mac-truncation" class="section-name selfRef">MAC Truncation</a>
            </h5>
<p id="section-5.2.2.1-1">When space is at a premium and the strength of the full
          length of a MAC is not needed, it is reasonable to truncate
          the keyed hash and use the truncated value for
          authentication.  HMAC SHA-1 truncated to 96 bits is an option
          available in several IETF protocols, including IPsec and TLS.
          However, while this option is kept for backwards compatibility,
          it may not provide a security level appropriate for all cases
          in the modern environment. In these cases, it is preferable to
          use a hashing algorithm such as SHA-256-128, SHA-384-192, or
          SHA-512-256 <span>[<a href="#RFC4868" class="xref">RFC4868</a>]</span>.<a href="#section-5.2.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.2.1-2">Processing of a truncated MAC follows these rules:<a href="#section-5.2.2.1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.2.2.1-3">
              <dt id="section-5.2.2.1-3.1">If the MAC Size field is greater than the keyed hash output
 length:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2.2.1-3.2">This case <span class="bcp14">MUST NOT</span> be generated and, if
 received, <span class="bcp14">MUST</span> cause the DNS message to be
 dropped and RCODE 1 (FORMERR) to be returned.<a href="#section-5.2.2.1-3.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2.2.1-3.3">If the MAC Size field equals the keyed hash output length:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2.2.1-3.4">The
       entire keyed hash output is present and used.<a href="#section-5.2.2.1-3.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2.2.1-3.5">If the MAC Size field is less than the larger of 10 (octets) and
 half the length of the hash function in use:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2.2.1-3.6">With the
 exception of certain TSIG error messages described 
 in <a href="#on_error" class="xref">Section 5.3.2</a>, where it is
 permitted that the MAC Size be zero, this case <span class="bcp14">MUST NOT</span> be generated and, if received, <span class="bcp14">MUST</span>
 cause the DNS message to be dropped and RCODE 1 (FORMERR) to
 be returned.<a href="#section-5.2.2.1-3.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2.2.1-3.7">Otherwise:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2.2.1-3.8">This is sent when the signer has truncated the keyed hash
 output to an allowable length, as described in <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>, taking initial octets and
 discarding trailing octets.  TSIG truncation can only be to an
 integral number of octets.  On receipt of a DNS message with
 truncation thus indicated, the locally calculated MAC is
 similarly truncated, and only the truncated values are compared
 for authentication.  The request MAC used when calculating the
 TSIG MAC for a reply is the truncated request MAC.<a href="#section-5.2.2.1-3.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</section>
</div>
</section>
<div id="time_check">
<section id="section-5.2.3">
          <h4 id="name-time-check-and-error-handli">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-time-check-and-error-handli" class="section-name selfRef">Time Check and Error Handling</a>
          </h4>
<p id="section-5.2.3-1">If the server time is outside the time interval specified
          by the request (which is the Time Signed value plus/minus
   the Fudge value),
          the server <span class="bcp14">MUST</span> generate an error response with RCODE 9
          (NOTAUTH) and TSIG ERROR 18 (BADTIME).  The server <span class="bcp14">SHOULD</span>
          also cache the most recent Time Signed value in a message
          generated by a key and <span class="bcp14">SHOULD</span> return BADTIME if a message
          received later has an earlier Time Signed value.  A
          response indicating a BADTIME error <span class="bcp14">MUST</span> be signed by the
          same key as the request.  It <span class="bcp14">MUST</span> include the client's
          current time in the Time Signed field, the server's current
          time (an unsigned 48-bit integer) in the Other Data field, and 6 in the
          Other Len field.  This is done so that the client
          can verify a message with a BADTIME error without the
          verification failing due to another BADTIME error.  In
          addition, the Fudge field <span class="bcp14">MUST</span> be set to the fudge value
          received from the client.  The data signed is specified in
          <a href="#on_error" class="xref">Section 5.3.2</a>.  The server
   <span class="bcp14">SHOULD</span> log the error.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<p id="section-5.2.3-2">Caching the most recent Time Signed value and rejecting
          requests with an earlier one could lead to valid messages
          being rejected if transit through the network led to UDP
          packets arriving in a different order to the one in which
          they were sent.  Implementations should be aware of
          this possibility and be prepared to deal with it, e.g., by
          retransmitting the rejected request with a new TSIG once
          outstanding requests have completed or the time given by their
          Time Signed value plus the Fudge value has passed.  If implementations
          do retry requests in these cases, a limit <span class="bcp14">SHOULD</span> be placed
          on the maximum number of retries.<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="trunc_check">
<section id="section-5.2.4">
          <h4 id="name-truncation-check-and-error-">
<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-truncation-check-and-error-" class="section-name selfRef">Truncation Check and Error Handling</a>
          </h4>
<p id="section-5.2.4-1">If a TSIG is received with truncation that is permitted
          per <a href="#trunc" class="xref">Section 5.2.2.1</a> but the MAC is too short
          for the local policy in force, an RCODE 9 (NOTAUTH) and TSIG
          ERROR 22 (BADTRUNC) <span class="bcp14">MUST</span> be returned. The server <span class="bcp14">SHOULD</span>
          log the error.<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="answers">
<section id="section-5.3">
        <h3 id="name-generation-of-tsig-on-answe">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-generation-of-tsig-on-answe" class="section-name selfRef">Generation of TSIG on Answers</a>
        </h3>
<p id="section-5.3-1">When a server has generated a response to a signed request,
        it signs the response using the same algorithm and key.  The
        server <span class="bcp14">MUST NOT</span> generate a signed response to a request if
        either the key is invalid (e.g., key name or algorithm name are unknown)
        or the MAC fails validation; see <a href="#on_error" class="xref">Section 5.3.2</a> for
        details of responding in these cases.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">It also <span class="bcp14">MUST NOT</span> generate a signed
        response to an unsigned request, except in the case of a
        response to a client's unsigned TKEY request if the secret key
        is established on the server side after the server processed the
        client's request.  Signing responses to unsigned TKEY requests
        <span class="bcp14">MUST</span> be explicitly specified in the description of an individual
        secret key establishment algorithm <span>[<a href="#RFC3645" class="xref">RFC3645</a>]</span>.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">The digest components used to generate a TSIG on a response are:<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-5.3-4.1">Request MAC<a href="#section-5.3-4.1" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty compact" id="section-5.3-4.2">DNS Message (response)<a href="#section-5.3-4.2" class="pilcrow">¶</a>
</li>
          <li class="ulEmpty compact" id="section-5.3-4.3">TSIG Variables (response)<a href="#section-5.3-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.3-5">(This calculation is different for the second and subsequent message
        in a multi-message answer; see below.)<a href="#section-5.3-5" class="pilcrow">¶</a></p>
<p id="section-5.3-6">If addition of the TSIG record will cause the message to be truncated,
        the server <span class="bcp14">MUST</span> alter the response so that a TSIG can be included.
        This response contains only the question and a TSIG
        record, has the TC bit set, and has an RCODE of 0 (NOERROR).
 At this point, the
        client <span class="bcp14">SHOULD</span> retry the request using TCP
        (as per <span><a href="https://www.rfc-editor.org/rfc/rfc1035#section-4.2.2" class="relref">Section 4.2.2</a> of [<a href="#RFC1035" class="xref">RFC1035</a>]</span>).<a href="#section-5.3-6" class="pilcrow">¶</a></p>
<div id="tcp">
<section id="section-5.3.1">
          <h4 id="name-tsig-on-tcp-connections">
<a href="#section-5.3.1" class="section-number selfRef">5.3.1. </a><a href="#name-tsig-on-tcp-connections" class="section-name selfRef">TSIG on TCP Connections</a>
          </h4>
<p id="section-5.3.1-1">A DNS TCP session, such as a zone transfer, can include multiple
        DNS messages. Using TSIG on such a connection can protect the
        connection from an attack and provide data integrity.  The TSIG
        <span class="bcp14">MUST</span> be included on all DNS messages in the response.  For backward
        compatibility, a client that receives DNS messages and verifies
        TSIG <span class="bcp14">MUST</span> accept up to 99 intermediary messages without a TSIG and
        <span class="bcp14">MUST</span> verify that both the first and last message contain a TSIG.<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
<p id="section-5.3.1-2">The first message is processed as a standard answer (see <a href="#answers" class="xref">Section 5.3</a>), but subsequent messages have
   the following digest components:<a href="#section-5.3.1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-5.3.1-3.1">Prior MAC (running)<a href="#section-5.3.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="ulEmpty compact" id="section-5.3.1-3.2">DNS Messages (any unsigned messages since the last TSIG)<a href="#section-5.3.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="ulEmpty compact" id="section-5.3.1-3.3">TSIG Timers (current message)<a href="#section-5.3.1-3.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.3.1-4">The "Prior MAC" is the MAC from the TSIG attached to the last
        message containing a TSIG.  "DNS Messages" comprises the
        concatenation (in message order) of all messages after the last
        message that included a TSIG and includes the current message.
        "TSIG Timers" comprises the Time Signed and Fudge fields (in
        that order) pertaining to the message for which the TSIG was created;
        this means that the successive TSIG records in the stream will have
        non-decreasing Time Signed values. Note that only the
        timers are included in the second and subsequent messages, not all
        the TSIG variables.<a href="#section-5.3.1-4" class="pilcrow">¶</a></p>
<p id="section-5.3.1-5">This allows the client to rapidly detect when the session has
        been altered; at which point, it can close the connection and retry.
        If a client TSIG verification fails, the client <span class="bcp14">MUST</span> close the
        connection.  If the client does not receive TSIG records frequently
        enough (as specified above), it <span class="bcp14">SHOULD</span> assume the connection has
        been hijacked, and it <span class="bcp14">SHOULD</span> close the connection.  The
 client <span class="bcp14">SHOULD</span> 
        treat this the same way as they would any other interrupted transfer
        (although the exact behavior is not specified).<a href="#section-5.3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="on_error">
<section id="section-5.3.2">
          <h4 id="name-generation-of-tsig-on-error">
<a href="#section-5.3.2" class="section-number selfRef">5.3.2. </a><a href="#name-generation-of-tsig-on-error" class="section-name selfRef">Generation of TSIG on Error Returns</a>
          </h4>
<p id="section-5.3.2-1">When a server detects an error relating to the key or MAC in the
        incoming request, the
        server <span class="bcp14">SHOULD</span> send back an unsigned error message (MAC Size == 0
        and empty MAC). It <span class="bcp14">MUST NOT</span> send back a signed error message.<a href="#section-5.3.2-1" class="pilcrow">¶</a></p>
<p id="section-5.3.2-2">If an error is detected relating to the TSIG
        validity period or the MAC is too short for the local policy,
        the server <span class="bcp14">SHOULD</span> send back a signed error message.
        The digest components are:<a href="#section-5.3.2-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-5.3.2-3.1">Request MAC (if the request MAC validated)<a href="#section-5.3.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="ulEmpty compact" id="section-5.3.2-3.2">DNS Message (response)<a href="#section-5.3.2-3.2" class="pilcrow">¶</a>
</li>
            <li class="ulEmpty compact" id="section-5.3.2-3.3">TSIG Variables (response)<a href="#section-5.3.2-3.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.3.2-4">The reason that the request MAC is not included in this MAC in
        some cases is to make it possible for the client to verify the
        error.  If the error is not a TSIG error, the response <span class="bcp14">MUST</span> be
        generated as specified in <a href="#answers" class="xref">Section 5.3</a>.<a href="#section-5.3.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="client_proc_answer">
<section id="section-5.4">
        <h3 id="name-client-processing-of-answer">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-client-processing-of-answer" class="section-name selfRef">Client Processing of Answer</a>
        </h3>
<p id="section-5.4-1">When a client receives a response from a server and
     expects to see a TSIG, it first checks if the TSIG RR is
     present in the response.  If not, the response is treated as
     having a format error and is discarded.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">If the TSIG RR is present, the client performs the same checks as
        described in <a href="#request_processing" class="xref">Section 5.2</a>.  If the TSIG RR is
        unsigned as specified in <a href="#on_error" class="xref">Section 5.3.2</a> or does not
        validate, the message <span class="bcp14">MUST</span> be discarded unless the RCODE is 9 (NOAUTH).
        In this case, the client <span class="bcp14">SHOULD</span> attempt to verify the response as if it
        were a TSIG error, as described in the following subsections.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">Regardless of the RCODE, a message containing a TSIG RR that is
        unsigned as specified in <a href="#on_error" class="xref">Section 5.3.2</a> or that fails
        verification <span class="bcp14">SHOULD NOT</span> be considered an acceptable response, as it
        may have been spoofed or manipulated. Instead, the
        client <span class="bcp14">SHOULD</span> log an error and continue to wait for a signed response
        until the request times out.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<section id="section-5.4.1">
          <h4 id="name-key-error-handling">
<a href="#section-5.4.1" class="section-number selfRef">5.4.1. </a><a href="#name-key-error-handling" class="section-name selfRef">Key Error Handling</a>
          </h4>
<p id="section-5.4.1-1">If an RCODE on a response is 9 (NOTAUTH), but the response
          TSIG validates and the TSIG key is recognized by the client
          but is different from that used on the request, then this is a
          key-related error.  The client <span class="bcp14">MAY</span> retry the request using the key
          specified by the server.  However, this should never occur, as
          a server <span class="bcp14">MUST NOT</span> sign a response with a different key to that
          used to sign the request.<a href="#section-5.4.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.4.2">
          <h4 id="name-mac-error-handling">
<a href="#section-5.4.2" class="section-number selfRef">5.4.2. </a><a href="#name-mac-error-handling" class="section-name selfRef">MAC Error Handling</a>
          </h4>
<p id="section-5.4.2-1">If the response RCODE is 9 (NOTAUTH) and TSIG ERROR
          is 16 (BADSIG), this is a MAC-related error, and clients <span class="bcp14">MAY</span> retry
          the request with a new request ID, but it would be better
          to try a different shared key if one is available.  Clients
          <span class="bcp14">SHOULD</span> keep track of how many MAC errors are associated
          with each key.  Clients <span class="bcp14">SHOULD</span> log this event.<a href="#section-5.4.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.4.3">
          <h4 id="name-time-error-handling">
<a href="#section-5.4.3" class="section-number selfRef">5.4.3. </a><a href="#name-time-error-handling" class="section-name selfRef">Time Error Handling</a>
          </h4>
<p id="section-5.4.3-1">If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR
          is 18 (BADTIME) or the current time does not fall in the
          range specified in the TSIG record, then this is a time-related
          error.  This is an indication that the client and server
          clocks are not synchronized.  In this case, the client
          <span class="bcp14">SHOULD</span> log the event.  DNS resolvers <span class="bcp14">MUST NOT</span> adjust any clocks in the client based on BADTIME errors,
   but the server's time in the Other Data field <span class="bcp14">SHOULD</span>
   be logged.<a href="#section-5.4.3-1" class="pilcrow">¶</a></p>
</section>
<div id="trunc_err">
<section id="section-5.4.4">
          <h4 id="name-truncation-error-handling">
<a href="#section-5.4.4" class="section-number selfRef">5.4.4. </a><a href="#name-truncation-error-handling" class="section-name selfRef">Truncation Error Handling</a>
          </h4>
<p id="section-5.4.4-1">If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR
          is 22 (BADTRUNC), then this is a truncation-related error. The client
   <span class="bcp14">MAY</span> retry with a lesser truncation up to the full
   HMAC output (no truncation), using the truncation used in the
   response as a hint for what the server policy allowed (<a href="#trunc_pol" class="xref">Section 7</a>). Clients
   <span class="bcp14">SHOULD</span> log this event.<a href="#section-5.4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="forwarding">
<section id="section-5.5">
        <h3 id="name-special-considerations-for-">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-special-considerations-for-" class="section-name selfRef">Special Considerations for Forwarding Servers</a>
        </h3>
<p id="section-5.5-1">A server acting as a forwarding server of a DNS message
        <span class="bcp14">SHOULD</span> check for the existence of a TSIG record.  If the name on
        the TSIG is not of a secret that the server shares with the
        originator, the server <span class="bcp14">MUST</span> forward the message unchanged
        including the TSIG.  If the name of the TSIG is of a key this
        server shares with the originator, it <span class="bcp14">MUST</span> process the TSIG.  If
        the TSIG passes all checks, the forwarding server <span class="bcp14">MUST</span>, if
        possible, include a TSIG of its own to the destination or the
        next forwarder. If no transaction security is available to the
        destination and the message is a query, and if the
        corresponding response has the AD flag (see <span>[<a href="#RFC4035" class="xref">RFC4035</a>]</span>) set, the forwarder <span class="bcp14">MUST</span> clear the
 AD flag 
        before adding the TSIG to the response and returning the result
        to the system from which it received the query.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="algorithm_id">
<section id="section-6">
      <h2 id="name-algorithms-and-identifiers">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-algorithms-and-identifiers" class="section-name selfRef">Algorithms and Identifiers</a>
      </h2>
<p id="section-6-1">The only message digest algorithm specified in the first
      version of these specifications <span>[<a href="#RFC2845" class="xref">RFC2845</a>]</span> was
      "HMAC-MD5" (see <span>[<a href="#RFC1321" class="xref">RFC1321</a>]</span> and <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>). 
      Although a review of its security some years ago <span>[<a href="#RFC6151" class="xref">RFC6151</a>]</span> concluded 
      that "it may not be urgent to remove HMAC-MD5 from the existing
      protocols", with the availability of more secure alternatives, the
      opportunity has been taken to make the implementation of this
      algorithm optional.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2"><span>[<a href="#RFC4635" class="xref">RFC4635</a>]</span> added mandatory support in
      TSIG for SHA-1 <span>[<a href="#FIPS180-4" class="xref">FIPS180-4</a>]</span> <span>[<a href="#RFC3174" class="xref">RFC3174</a>]</span>. SHA-1 collisions have been
      demonstrated <span>[<a href="#SHA1SHAMBLES" class="xref">SHA1SHAMBLES</a>]</span>, so the MD5
      security considerations described in <span><a href="https://www.rfc-editor.org/rfc/rfc6151#section-2" class="relref">Section 2</a> of [<a href="#RFC6151" class="xref">RFC6151</a>]</span> apply to SHA-1 in a similar manner.
      Although support for hmac-sha1 in TSIG is still mandatory for
      compatibility reasons, existing uses <span class="bcp14">SHOULD</span> be replaced
      with hmac-sha256 or other SHA-2 digest algorithms (<span>[<a href="#FIPS180-4" class="xref">FIPS180-4</a>]</span>, <span>[<a href="#RFC3874" class="xref">RFC3874</a>]</span>, <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>).<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Use of TSIG between two DNS agents is by mutual
      agreement.  That agreement can include the support of additional
      algorithms and criteria as to which algorithms and truncations are
      acceptable, subject to the restriction and guidelines in
      <a href="#trunc" class="xref">Section 5.2.2.1</a>.
      Key agreement can be by the TKEY mechanism <span>[<a href="#RFC2930" class="xref">RFC2930</a>]</span>
      or some other mutually agreeable method.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">Implementations that support TSIG <span class="bcp14">MUST</span>
      also implement HMAC SHA1 and HMAC SHA256 and <span class="bcp14">MAY</span> implement
      gss-tsig and the other algorithms listed below.  SHA-1 truncated
      to 96 bits (12 octets) <span class="bcp14">SHOULD</span> be implemented.<a href="#section-6-4" class="pilcrow">¶</a></p>
<span id="name-algorithms-for-implementati"></span><div id="allowed-algorithms">
<table class="center" id="table-3">
        <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-algorithms-for-implementati" class="selfRef">Algorithms for Implementations Supporting TSIG</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Algorithm Name</th>
            <th class="text-left" rowspan="1" colspan="1">Implementation</th>
            <th class="text-left" rowspan="1" colspan="1">Use</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">HMAC-MD5.SIG-ALG.REG.INT</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MUST NOT</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">gss-tsig</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha1</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MUST</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">NOT RECOMMENDED</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha224</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha256</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MUST</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">RECOMMENDED</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha256-128</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha384</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha384-192</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha512</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">hmac-sha512-256</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <span class="bcp14">MAY</span>
</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="trunc_pol">
<section id="section-7">
      <h2 id="name-tsig-truncation-policy">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-tsig-truncation-policy" class="section-name selfRef">TSIG Truncation Policy</a>
      </h2>
<p id="section-7-1">As noted above, two DNS agents (e.g., resolver and server) must
      mutually agree to use TSIG.
      Implicit in such an "agreement" are criteria as to acceptable keys,
      algorithms, and (with the extensions in this document) truncations.
      Local policies <span class="bcp14">MAY</span> require the rejection of TSIGs, even though
      they use an algorithm for which implementation is mandatory.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">When a local policy permits acceptance of a TSIG with a particular
      algorithm and a particular non-zero amount of truncation, it <span class="bcp14">SHOULD</span>
      also permit the use of that algorithm with lesser truncation (a
      longer MAC) up to the full keyed hash output.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">Regardless of a lower acceptable truncated MAC length specified by
      local policy, a reply <span class="bcp14">SHOULD</span> be sent with a MAC at least as long as
      that in the corresponding request. Note, if the request specified a MAC
      length longer than the keyed hash output, it will be rejected by
      processing rules (<a href="#trunc" class="xref">Section 5.2.2.1</a>, case 1).<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">Implementations permitting multiple acceptable algorithms and/or
      truncations <span class="bcp14">SHOULD</span> permit this list to be ordered by presumed
      strength and <span class="bcp14">SHOULD</span> allow different truncations for the same
      algorithm to be treated as separate entities in this list.  When so
      implemented, policies <span class="bcp14">SHOULD</span> accept a presumed stronger algorithm and
      truncation than the minimum strength required by the policy.<a href="#section-7-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-shared-secrets">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-shared-secrets" class="section-name selfRef">Shared Secrets</a>
      </h2>
<p id="section-8-1">Secret keys are very sensitive information and all available
      steps should be taken to protect them on every host on which they
      are stored.  Generally, such hosts need to be physically protected.
      If they are multi-user machines, great care should be taken so that
      unprivileged users have no access to keying material.  Resolvers
      often run unprivileged, which means all users of a host would be
      able to see whatever configuration data are used by the resolver.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">A name server usually runs privileged, which means its
      configuration data need not be visible to all users of the host.
      For this reason, a host that implements transaction-based
      authentication should probably be configured with a "stub
      resolver" and a local caching and forwarding name server.  This
      presents a special problem for <span>[<a href="#RFC2136" class="xref">RFC2136</a>]</span>, which
      otherwise depends on clients to communicate only with a zone's
      authoritative name servers.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Use of strong, random shared secrets is essential to the
      security of TSIG.  See <span>[<a href="#RFC4086" class="xref">RFC4086</a>]</span> for a discussion
      of this issue.  The secret <span class="bcp14">SHOULD</span> be at least as long as the keyed hash
      output <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>.<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">IANA maintains a registry of algorithm names to be used as
      "Algorithm Names", as defined in <a href="#format" class="xref">Section 4.2</a> <span>[<a href="#IANA-TSIG" class="xref">IANA-TSIG</a>]</span>. Algorithm
      names are text strings encoded using the syntax of a domain name.  There
      is no structure to the names, and algorithm names are compared
      as if they were DNS names, i.e., comparison is case
      insensitive. Previous specifications (<span>[<a href="#RFC2845" class="xref">RFC2845</a>]</span> and <span>[<a href="#RFC4635" class="xref">RFC4635</a>]</span>)
      defined values for the HMAC-MD5 and some HMAC-SHA 
      algorithms. IANA has also registered "gss-tsig" as an identifier for TSIG
      authentication where the cryptographic operations are delegated to the
      Generic Security Service (GSS) <span>[<a href="#RFC3645" class="xref">RFC3645</a>]</span>.  This document
      adds to the allowed algorithms, and the registry has been updated with the
      names listed in <a href="#allowed-algorithms" class="xref">Table 3</a>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">New algorithms are assigned using
      the IETF Review policy defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.
      The algorithm name
      HMAC-MD5.SIG-ALG.REG.INT looks like a fully qualified domain
      name for historical reasons;
      other algorithm names are simple, single-component names.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">IANA maintains a registry of RCODEs (error codes) (see <span>[<a href="#IANA-RCODEs" class="xref">IANA-RCODEs</a>]</span>, including
      "TSIG Error values" to be used for "Error" values, as defined in
      <a href="#format" class="xref">Section 4.2</a>.  This document defines the RCODEs as
      described in <a href="#numbers" class="xref">Section 3</a>.  New error codes are assigned and
      specified as in <span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>.<a href="#section-9-3" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">The approach specified here is computationally much less
      expensive than the signatures specified in DNSSEC.  As long as
      the shared secret key is not compromised, strong authentication
      is provided between two DNS systems, e.g., for the last hop from
      a local name server to the user resolver or between primary and
      secondary name servers.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">Recommendations for choosing and maintaining secret keys can be found
      in <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>.  If the client host has been compromised,
      the server should suspend the use of all secrets known to that client.
      If possible, secrets should be stored in an encrypted form.  Secrets should
      never be transmitted in the clear over any network.  This document does
      not address the issue on how to distribute secrets except that it
      mentions the possibilities of manual configuration and the use of TKEY
      <span>[<a href="#RFC2930" class="xref">RFC2930</a>]</span>.  Secrets <span class="bcp14">SHOULD NOT</span> be shared by more than two 
      entities; any such additional sharing would allow any party knowing the
      key to impersonate any other such party to members of the group.<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="section-10-3">This mechanism does not authenticate source data, only its
      transmission between two parties who share some secret.  The
      original source data can come from a compromised zone master or
      can be corrupted during transit from an authentic zone master to
      some "caching forwarder".  However, if the server is faithfully
      performing the full DNSSEC security checks, then
      only security-checked data will be available to the client.<a href="#section-10-3" class="pilcrow">¶</a></p>
<p id="section-10-4">A Fudge value that is too large may leave the server open
      to replay attacks.  A Fudge value that is too small may cause
      failures if machines are not time synchronized or there are unexpected
      network delays.  The <span class="bcp14">RECOMMENDED</span> value in most situations is 300
      seconds.<a href="#section-10-4" class="pilcrow">¶</a></p>
<p id="section-10-5">To prevent cross-algorithm attacks, there <span class="bcp14">SHOULD</span> only be one
      algorithm associated with any given key name.<a href="#section-10-5" class="pilcrow">¶</a></p>
<p id="section-10-6">In several cases where errors are detected, an unsigned error
      message must be returned. This can allow for an attacker to spoof
      or manipulate these responses.  <a href="#client_proc_answer" class="xref">Section 5.4</a>
      recommends logging these as errors and continuing to wait for a
      signed response until the request times out.<a href="#section-10-6" class="pilcrow">¶</a></p>
<p id="section-10-7">Although the strength of an algorithm determines its security,
      there have been some arguments that mild truncation can
      strengthen a MAC by reducing the information available to an
      attacker.  However, excessive truncation clearly weakens authentication by
      reducing the number of bits an attacker has to try to break the
      authentication by brute force <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>.<a href="#section-10-7" class="pilcrow">¶</a></p>
<p id="section-10-8">Significant progress has been made recently in cryptanalysis of hash
      functions of the types used here.  While the results so far should not
      affect HMAC, the stronger SHA-256 algorithm is being made mandatory as a
      precaution.<a href="#section-10-8" class="pilcrow">¶</a></p>
<p id="section-10-9">See also the Security Considerations section of <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span> from which the limits on truncation
      in this RFC were taken.<a href="#section-10-9" class="pilcrow">¶</a></p>
<div id="issuesfixed">
<section id="section-10.1">
        <h3 id="name-issue-fixed-in-this-documen">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-issue-fixed-in-this-documen" class="section-name selfRef">Issue Fixed in This Document</a>
        </h3>
<p id="section-10.1-1">When signing a DNS reply message using TSIG, the MAC
         computation uses the request message's MAC as an input to
         cryptographically relate the reply to the request.  The
         original TSIG specification <span>[<a href="#RFC2845" class="xref">RFC2845</a>]</span> required
         that the time values be checked before the request's MAC.  If
         the time was invalid, some implementations failed to carry out
         further checks and could use an invalid request MAC in the
         signed reply.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<p id="section-10.1-2">This document makes it mandatory that the request MAC
         is considered to be invalid until it has been validated;
         until then, any answer must be unsigned.  For this reason, the
         request MAC is now checked before the time values.<a href="#section-10.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10.2">
        <h3 id="name-why-not-dnssec">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-why-not-dnssec" class="section-name selfRef">Why Not DNSSEC?</a>
        </h3>
<p id="section-10.2-1">DNS has been extended by DNSSEC
           (<span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span>, <span>[<a href="#RFC4034" class="xref">RFC4034</a>]</span>, and 
           <span>[<a href="#RFC4035" class="xref">RFC4035</a>]</span>) to provide for data origin
           authentication, and public key distribution, all based on
           public key cryptography and public key based digital
           signatures.  To be practical, this form of security
           generally requires extensive local caching of keys and
           tracing of authentication through multiple keys and
           signatures to a pre-trusted locally configured key.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<p id="section-10.2-2">One difficulty with the DNSSEC scheme is that common DNS
           implementations include simple "stub" resolvers which do not
           have caches.  Such resolvers typically rely on a caching DNS
           server on another host.  It is impractical for these stub
           resolvers to perform general DNSSEC authentication and they
           would naturally depend on their caching DNS server to
           perform such services for them.  To do so securely requires
           secure communication of queries and responses.  DNSSEC
           provides public key transaction signatures to support this,
           but such signatures are very expensive computationally to
           generate.  In general, these require the same complex public
           key logic that is impractical for stubs.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
<p id="section-10.2-3">A second area where use of straight DNSSEC public key based
   mechanisms may be impractical is authenticating dynamic update <span>[<a href="#RFC2136" class="xref">RFC2136</a>]</span> requests. DNSSEC provides for
   request signatures but with DNSSEC they, like transaction
   signatures, require computationally expensive public key
   cryptography and complex authentication logic. Secure Domain Name
   System Dynamic Update (<span>[<a href="#RFC3007" class="xref">RFC3007</a>]</span>)
   describes how different keys are used in dynamically updated
   zones.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="FIPS180-4">[FIPS180-4]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Secure Hash Standard (SHS)"</span>, <span class="seriesInfo">FIPS PUB 180-4</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.180-4</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.FIPS.180-4">https://doi.org/10.6028/NIST.FIPS.180-4</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="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="RFC2845">[RFC2845]</dt>
        <dd>
<span class="refAuthor">Vixie, P.</span><span class="refAuthor">, Gudmundsson, O.</span><span class="refAuthor">, Eastlake 3rd, D.</span><span class="refAuthor">, and B. Wellington</span>, <span class="refTitle">"Secret Key Transaction Authentication for DNS (TSIG)"</span>, <span class="seriesInfo">RFC 2845</span>, <span class="seriesInfo">DOI 10.17487/RFC2845</span>, <time datetime="2000-05" class="refDate">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2845">https://www.rfc-editor.org/info/rfc2845</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3597">[RFC3597]</dt>
        <dd>
<span class="refAuthor">Gustafsson, A.</span>, <span class="refTitle">"Handling of Unknown DNS Resource Record (RR) Types"</span>, <span class="seriesInfo">RFC 3597</span>, <span class="seriesInfo">DOI 10.17487/RFC3597</span>, <time datetime="2003-09" class="refDate">September 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3597">https://www.rfc-editor.org/info/rfc3597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4635">[RFC4635]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers"</span>, <span class="seriesInfo">RFC 4635</span>, <span class="seriesInfo">DOI 10.17487/RFC4635</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4635">https://www.rfc-editor.org/info/rfc4635</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>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CVE-2017-11104">[CVE-2017-11104]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2017-11104: Improper TSIG validity period check can allow TSIG forgery"</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11104">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2017-3142">[CVE-2017-3142]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2017-3142: An error in TSIG authentication can permit unauthorized zone transfers"</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3142">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3142</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2017-3143">[CVE-2017-3143]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2017-3143: An error in TSIG authentication can permit unauthorized dynamic updates"</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3143">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3143</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-RCODEs">[IANA-RCODEs]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"DNS RCODEs"</span>, <span>&lt;<a href="https://www.iana.org/assignments/dns-parameters/">https://www.iana.org/assignments/dns-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-TSIG">[IANA-TSIG]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TSIG Algorithm Names"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tsig-algorithm-names/">https://www.iana.org/assignments/tsig-algorithm-names/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1321">[RFC1321]</dt>
        <dd>
<span class="refAuthor">Rivest, R.</span>, <span class="refTitle">"The MD5 Message-Digest Algorithm"</span>, <span class="seriesInfo">RFC 1321</span>, <span class="seriesInfo">DOI 10.17487/RFC1321</span>, <time datetime="1992-04" class="refDate">April 1992</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1321">https://www.rfc-editor.org/info/rfc1321</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2104">[RFC2104]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor">, Bellare, M.</span><span class="refAuthor">, and R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02" class="refDate">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2136">[RFC2136]</dt>
        <dd>
<span class="refAuthor">Vixie, P., Ed.</span><span class="refAuthor">, Thomson, S.</span><span class="refAuthor">, Rekhter, Y.</span><span class="refAuthor">, and J. Bound</span>, <span class="refTitle">"Dynamic Updates in the Domain Name System (DNS UPDATE)"</span>, <span class="seriesInfo">RFC 2136</span>, <span class="seriesInfo">DOI 10.17487/RFC2136</span>, <time datetime="1997-04" class="refDate">April 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2136">https://www.rfc-editor.org/info/rfc2136</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2930">[RFC2930]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Secret Key Establishment for DNS (TKEY RR)"</span>, <span class="seriesInfo">RFC 2930</span>, <span class="seriesInfo">DOI 10.17487/RFC2930</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2930">https://www.rfc-editor.org/info/rfc2930</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3007">[RFC3007]</dt>
        <dd>
<span class="refAuthor">Wellington, B.</span>, <span class="refTitle">"Secure Domain Name System (DNS) Dynamic Update"</span>, <span class="seriesInfo">RFC 3007</span>, <span class="seriesInfo">DOI 10.17487/RFC3007</span>, <time datetime="2000-11" class="refDate">November 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3007">https://www.rfc-editor.org/info/rfc3007</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3174">[RFC3174]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor"> and P. Jones</span>, <span class="refTitle">"US Secure Hash Algorithm 1 (SHA1)"</span>, <span class="seriesInfo">RFC 3174</span>, <span class="seriesInfo">DOI 10.17487/RFC3174</span>, <time datetime="2001-09" class="refDate">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3174">https://www.rfc-editor.org/info/rfc3174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3645">[RFC3645]</dt>
        <dd>
<span class="refAuthor">Kwan, S.</span><span class="refAuthor">, Garg, P.</span><span class="refAuthor">, Gilroy, J.</span><span class="refAuthor">, Esibov, L.</span><span class="refAuthor">, Westhead, J.</span><span class="refAuthor">, and R. Hall</span>, <span class="refTitle">"Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)"</span>, <span class="seriesInfo">RFC 3645</span>, <span class="seriesInfo">DOI 10.17487/RFC3645</span>, <time datetime="2003-10" class="refDate">October 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3645">https://www.rfc-editor.org/info/rfc3645</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3874">[RFC3874]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"A 224-bit One-way Hash Function: SHA-224"</span>, <span class="seriesInfo">RFC 3874</span>, <span class="seriesInfo">DOI 10.17487/RFC3874</span>, <time datetime="2004-09" class="refDate">September 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3874">https://www.rfc-editor.org/info/rfc3874</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4033">[RFC4033]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"DNS Security Introduction and Requirements"</span>, <span class="seriesInfo">RFC 4033</span>, <span class="seriesInfo">DOI 10.17487/RFC4033</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4034">[RFC4034]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Resource Records for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4034</span>, <span class="seriesInfo">DOI 10.17487/RFC4034</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4034">https://www.rfc-editor.org/info/rfc4034</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4035">[RFC4035]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Protocol Modifications for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4035</span>, <span class="seriesInfo">DOI 10.17487/RFC4035</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4035">https://www.rfc-editor.org/info/rfc4035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4868">[RFC4868]</dt>
        <dd>
<span class="refAuthor">Kelly, S.</span><span class="refAuthor"> and S. Frankel</span>, <span class="refTitle">"Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec"</span>, <span class="seriesInfo">RFC 4868</span>, <span class="seriesInfo">DOI 10.17487/RFC4868</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4868">https://www.rfc-editor.org/info/rfc4868</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6151">[RFC6151]</dt>
        <dd>
<span class="refAuthor">Turner, S.</span><span class="refAuthor"> and L. Chen</span>, <span class="refTitle">"Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms"</span>, <span class="seriesInfo">RFC 6151</span>, <span class="seriesInfo">DOI 10.17487/RFC6151</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6151">https://www.rfc-editor.org/info/rfc6151</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6234">[RFC6234]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor"> and T. Hansen</span>, <span class="refTitle">"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"</span>, <span class="seriesInfo">RFC 6234</span>, <span class="seriesInfo">DOI 10.17487/RFC6234</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6234">https://www.rfc-editor.org/info/rfc6234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6895">[RFC6895]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>, <span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6895">https://www.rfc-editor.org/info/rfc6895</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7696">[RFC7696]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms"</span>, <span class="seriesInfo">BCP 201</span>, <span class="seriesInfo">RFC 7696</span>, <span class="seriesInfo">DOI 10.17487/RFC7696</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7696">https://www.rfc-editor.org/info/rfc7696</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SHA1SHAMBLES">[SHA1SHAMBLES]</dt>
      <dd>
<span class="refAuthor">Leurent, G.</span><span class="refAuthor"> and T. Peyrin</span>, <span class="refTitle">"SHA-1 is a Shambles"</span>, <time datetime="2020-01" class="refDate">January 2020</time>, <span>&lt;<a href="https://eprint.iacr.org/2020/014.pdf">https://eprint.iacr.org/2020/014.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acks">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The security problem addressed by this document was reported by
      <span class="contact-name">Clément Berthaux</span> from Synacktiv.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2"><span class="contact-name">Peter van Dijk</span>, <span class="contact-name">Benno       Overeinder</span>, <span class="contact-name">Willem Toroop</span>, <span class="contact-name">Ondrej Sury</span>, <span class="contact-name">Mukund Sivaraman</span>, and
      <span class="contact-name">Ralph Dolmans</span> participated in the discussions that
      prompted this document.  <span class="contact-name">Mukund Sivaraman</span>,
      <span class="contact-name">Martin Hoffman</span>, and <span class="contact-name">Tony       Finch</span> made extremely helpful suggestions concerning the structure and
      wording of the updated document.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Stephen Morris would like to thank Internet Systems Consortium for its
  support of his participation in the creation of this document.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Francis Dupont</span></div>
<div dir="auto" class="left"><span class="org">Internet Systems Consortium, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">PO Box 360</span></div>
<div dir="auto" class="left">
<span class="locality">Newmarket</span>, <span class="region">NH</span> <span class="postal-code">03857</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:Francis.Dupont@fdupont.fr" class="email">Francis.Dupont@fdupont.fr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stephen Morris</span></div>
<div dir="auto" class="left"><span class="org">Unaffiliated</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sa.morris8@gmail.com" class="email">sa.morris8@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Paul Vixie</span></div>
<div dir="auto" class="left"><span class="org">Farsight Security Inc</span></div>
<div dir="auto" class="left"><span class="extended-address">Suite 180</span></div>
<div dir="auto" class="left"><span class="street-address">177 Bovet Road</span></div>
<div dir="auto" class="left">
<span class="locality">San Mateo</span>, <span class="region">CA</span> <span class="postal-code">94402</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:paul@redbarn.org" class="email">paul@redbarn.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Donald E. Eastlake 3rd</span></div>
<div dir="auto" class="left"><span class="org">Futurewei Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">2386 Panoramic Circle</span></div>
<div dir="auto" class="left">
<span class="locality">Apopka</span>, <span class="region">FL</span> <span class="postal-code">32703</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:d3e3e3@gmail.com" class="email">d3e3e3@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Olafur Gudmundsson</span></div>
<div dir="auto" class="left"><span class="org">Cloudflare</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:olafur+ietf@cloudflare.com" class="email">olafur+ietf@cloudflare.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Brian Wellington</span></div>
<div dir="auto" class="left"><span class="org">Akamai</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:bwelling@akamai.com" class="email">bwelling@akamai.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>