File: rfc8764.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (2932 lines) | stat: -rw-r--r-- 128,653 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8764: Apple's DNS Long-Lived Queries Protocol</title>
<meta content="Stuart Cheshire" name="author">
<meta content="Marc Krochmal" name="author">
<meta content="
       
   Apple's DNS Long-Lived Queries (LLQ) is a mechanism
    for extending the DNS protocol to support change notification,
     thus allowing clients to learn about changes to DNS data
      without polling the server.  From 2005 onwards, LLQ was
       implemented in Apple products including Mac OS X, Bonjour for
        Windows, and AirPort wireless base stations.  In 2020, the LLQ
         protocol was superseded by the IETF Standards Track RFC 8765,
 &quot;DNS
  Push Notifications&quot;, which builds on experience gained with
   the LLQ protocol to create a superior replacement.
       
       
    The existing LLQ protocol deployed and used from 2005 to 2020 is
    documented here to give
    background regarding the operational experience that informed
    the development of DNS Push Notifications, and to help facilitate
    a smooth transition from LLQ to DNS Push Notifications.
       
    " name="description">
<meta content="xml2rfc 2.45.3" name="generator">
<meta content="Async" name="keyword">
<meta content="Asynchronous" name="keyword">
<meta content="Change Notification" name="keyword">
<meta content="Push Notification" name="keyword">
<meta content="8764" name="rfc.number">
<link href="rfc8764.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;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
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. */
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8764" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-sekar-dns-llq-06" 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 8764</td>
<td class="center">Apple's DNS LLQ</td>
<td class="right">June 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Cheshire &amp; Krochmal</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8764" class="eref">8764</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-06" class="published">June 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Cheshire</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">M. Krochmal</div>
<div class="org">Apple Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8764</h1>
<h1 id="title">Apple's DNS Long-Lived Queries Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   Apple's DNS Long-Lived Queries (LLQ) is a mechanism
    for extending the DNS protocol to support change notification,
     thus allowing clients to learn about changes to DNS data
      without polling the server.  From 2005 onwards, LLQ was
       implemented in Apple products including Mac OS X, Bonjour for
        Windows, and AirPort wireless base stations.  In 2020, the LLQ
         protocol was superseded by the IETF Standards Track RFC 8765,
 "DNS
  Push Notifications", which builds on experience gained with
   the LLQ protocol to create a superior replacement.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
    The existing LLQ protocol deployed and used from 2005 to 2020 is
    documented here to give
    background regarding the operational experience that informed
    the development of DNS Push Notifications, and to help facilitate
    a smooth transition from LLQ to DNS Push Notifications.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8764">https://www.rfc-editor.org/info/rfc8764</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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><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-transition-to-dns-push-noti" class="xref">Transition to DNS Push Notifications</a><a href="#section-toc.1-1.1.2.1.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" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology Used in This Document</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-mechanisms" class="xref">Mechanisms</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-assigned-numbers" class="xref">Assigned Numbers</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-opt-rr-format" class="xref">Opt-RR Format</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</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-llq-address-and-port-identi" class="xref">LLQ Address and Port Identification</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</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-llq-setup" class="xref">LLQ Setup</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-setup-message-retransmissio" class="xref">Setup Message Retransmission</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-llq-setup-four-way-handshak" class="xref">LLQ Setup Four-Way Handshake</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-setup-request" class="xref">Setup Request</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-setup-challenge" class="xref">Setup Challenge</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-challenge-response" class="xref">Challenge Response</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-ack-answers" class="xref">ACK + Answers</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-resource-record-ttls" class="xref">Resource Record TTLs</a><a href="#section-toc.1-1.5.2.3.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-event-responses" class="xref">Event Responses</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-add-events" class="xref">Add Events</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-remove-events" class="xref">Remove Events</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-gratuitous-response-acknowl" class="xref">Gratuitous Response Acknowledgments</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</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-llq-lease-life-expiration" class="xref">LLQ Lease-Life Expiration</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-refresh-request" class="xref">Refresh Request</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-llq-refresh-acknowledgment" class="xref">LLQ Refresh Acknowledgment</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-server-dos" class="xref">Server DoS</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-client-packet-storms" class="xref">Client Packet Storms</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-spoofing" class="xref">Spoofing</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</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-references" class="xref">References</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-normative-references" class="xref">Normative References</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-informative-references" class="xref">Informative References</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-appendix.a" class="xref">Appendix A</a>.  <a href="#name-problems-with-the-llq-proto" class="xref">Problems with the LLQ Protocol</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</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.c" 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>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
    In dynamic environments, DNS-based Service Discovery <span>[<a href="#RFC6763" class="xref">RFC6763</a>]</span> benefits
    significantly from clients being able to learn about changes to
    DNS information via a mechanism that is both more timely and more
    efficient than simple polling. Such a mechanism enables "live
    browses" that (a) learn when a new instance of a service appears, (b)
    learn when
    an existing service instance disappears from the network, and (c) allows
    clients
    to monitor status changes to a service instance (e.g., printer ink
    levels).
    Multicast DNS <span>[<a href="#RFC6762" class="xref">RFC6762</a>]</span> supports this
    natively. When a device on the network publishes or deletes Multicast DNS
    records, these changes are multicast to other hosts on the network.
    Those hosts deliver the change notifications to interested clients
    (applications
    running on that host). Hosts also send occasional queries to the
    network, in case gratuitous announcements are not received due to
    packet loss, and to detect records lost due to their publishers
    crashing or having become disconnected from the network.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   This document defines an Apple extension to unicast DNS that enables a
   client to
   issue long-lived queries that allow a unicast DNS server to notify clients
   about changes to DNS data. This is a more scalable and practical
   solution than can be achieved by polling of the name server, because
   a low polling rate could leave the client with stale information,
   while a high polling rate would have an adverse impact on the network
   and server.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   The mechanism defined in this document is now being replaced by DNS Push
   Notifications <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span> as explained
   in <a href="#trans" class="xref">Section 1.1</a>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4"></p>
<div id="trans">
<section id="section-1.1">
        <h3 id="name-transition-to-dns-push-noti">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-transition-to-dns-push-noti" class="section-name selfRef">Transition to DNS Push Notifications</a>
        </h3>
<p id="section-1.1-1">
    The LLQ protocol enjoyed over a decade of useful operation,
    enabling timely live updates for the service discovery user interface in
    Apple's Back to My Mac <span>[<a href="#RFC6281" class="xref">RFC6281</a>]</span>
    service.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
    However, some problems were discovered, as described in <a href="#problems" class="xref">Appendix A</a>.
    This operational
    experience with LLQ informed the design of its IETF Standards
    Track successor, DNS Push Notifications <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>.
    Since no further work is being done on the LLQ protocol, this LLQ
    specification will not be updated to remedy these problems.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
    All existing LLQ implementations are <span class="bcp14">RECOMMENDED</span> to migrate
    to using DNS Push Notifications instead.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
    Existing LLQ servers are <span class="bcp14">RECOMMENDED</span> to implement and
    support
    DNS Push Notifications so that clients can begin migrating to the
    newer protocol.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">
    Existing LLQ clients are <span class="bcp14">RECOMMENDED</span> to query for the
    <code>_dns‑push‑tls._tcp.&lt;zone&gt;</code> SRV record first, and
    then only if DNS Push Notifications fail, fall back to query for
    <code>_dns‑llq._udp.&lt;zone&gt;</code> instead.  Use of the
    <code>_dns‑llq._udp.&lt;zone&gt;</code> SRV record is described in <a href="#address-port" class="xref">Section 4</a>.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">
    This will cause clients to prefer the newer protocol when possible.  It is
    <span class="bcp14">RECOMMENDED</span> that clients always attempt DNS Push
    Notifications first for every new request, and only if that fails, then
    fall back to using LLQ.  Clients <span class="bcp14">SHOULD NOT</span> record that a
    given server only speaks LLQ and subsequently default to LLQ for that
    server, since server software gets updated and even a server that speaks
    only LLQ today may be updated to support DNS Push Notifications tomorrow.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<p id="section-1.1-7">
    New client and server implementations are <span class="bcp14">RECOMMENDED</span> to
    support only
    DNS Push Notifications.<a href="#section-1.1-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology Used in This Document</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>
<section id="section-3">
      <h2 id="name-mechanisms">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-mechanisms" class="section-name selfRef">Mechanisms</a>
      </h2>
<p id="section-3-1">
    DNS Long-Lived Queries (LLQ) are implemented using the standard
    DNS message format <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> in
    conjunction with an EDNS(0) OPT
    pseudo‑RR <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span> with a new
    OPTION‑CODE
    and OPTION‑DATA format specified here.  Encoding the LLQ request in
    an OPT pseudo‑RR
    allows for implementation of LLQ with minimal modification to a name
    server's front end.  If a DNS query containing an LLQ option is sent to a
    server that does not implement LLQ, a server that complies with the
    EDNS(0) specification <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span> will
    silently ignore the unrecognized option and answer the request as a normal
    DNS query without establishing any long-lived state and without
    returning an LLQ option in its response.  If a DNS query containing an LLQ
    option is sent to a server that does not implement EDNS(0) at all, the
    server may silently ignore the EDNS(0) OPT pseudo‑RR or it may
    return a nonzero RCODE.  However, in practice, this issue is mostly
    theoretical, since having a zone's _dns‑llq._udp.&lt;zone&gt; SRV
    record target a host that does not implement LLQ is a configuration error.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
    Note that this protocol is designed for data set sizes of a few dozen
    resource records at most and change rates no more than once every 10
    seconds on average. Data sets that frequently
    exceed a single IP packet, or that experience a rapid change rate, may
    have
    undesirable performance implications.<a href="#section-3-2" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-assigned-numbers">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-assigned-numbers" class="section-name selfRef">Assigned Numbers</a>
        </h3>
<p id="section-3.1-1">
       This section describes constants used in this document.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-3.1-2.1">
            <p id="section-3.1-2.1.1">EDNS(0) OPTION‑CODE (recorded with IANA):<a href="#section-3.1-2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-3.1-2.1.2.1">
                <dl class="dlParallel" id="section-3.1-2.1.2.1.1">
                  <dt id="section-3.1-2.1.2.1.1.1">LLQ
                  </dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.1.2.1.1.2">1<a href="#section-3.1-2.1.2.1.1.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</li>
</ul>
</li>
<li class="ulEmpty normal" id="section-3.1-2.2">
LLQ‑PORT 5352 (recorded with IANA)<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty normal" id="section-3.1-2.3">
            <p id="section-3.1-2.3.1">LLQ Opcodes (specific to this LLQ EDNS(0) Option):<a href="#section-3.1-2.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-3.1-2.3.2.1">
                <dl class="dlParallel dlCompact" id="section-3.1-2.3.2.1.1">
                  <dt id="section-3.1-2.3.2.1.1.1">LLQ‑SETUP
                  </dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.3.2.1.1.2">1<a href="#section-3.1-2.3.2.1.1.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.3.2.1.1.3">LLQ‑REFRESH
                  </dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.3.2.1.1.4">2<a href="#section-3.1-2.3.2.1.1.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.3.2.1.1.5">LLQ‑EVENT
                  </dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.3.2.1.1.6">3<a href="#section-3.1-2.3.2.1.1.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</li>
</ul>
</li>
<li class="ulEmpty normal" id="section-3.1-2.4">
            <p id="section-3.1-2.4.1">LLQ Error Codes (specific to this LLQ EDNS(0) Option):<a href="#section-3.1-2.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-3.1-2.4.2.1">
                <dl class="dlParallel dlCompact" id="section-3.1-2.4.2.1.1">
                  <dt id="section-3.1-2.4.2.1.1.1">
NO-ERROR
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.2">0<a href="#section-3.1-2.4.2.1.1.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.3">
SERV-FULL
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.4">1<a href="#section-3.1-2.4.2.1.1.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.5">
STATIC
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.6">2<a href="#section-3.1-2.4.2.1.1.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.7">
FORMAT-ERR
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.8">3<a href="#section-3.1-2.4.2.1.1.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.9">
NO-SUCH-LLQ
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.10">4<a href="#section-3.1-2.4.2.1.1.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.11">
BAD-VERS
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.12">5<a href="#section-3.1-2.4.2.1.1.12" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-3.1-2.4.2.1.1.13">
UNKNOWN-ERR
</dt>
<dd style="margin-left: 9.0em" id="section-3.1-2.4.2.1.1.14">6<a href="#section-3.1-2.4.2.1.1.14" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</li>
</ul>
</li>
</ul>
</section>
<section id="section-3.2">
        <h3 id="name-opt-rr-format">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-opt-rr-format" class="section-name selfRef">Opt-RR Format</a>
        </h3>
<p id="section-3.2-1">
    As required by the EDNS(0) specification <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span>,
    all OPT pseudo‑RRs used in LLQs are formatted as follows:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span id="name-opt-rrs-used-in-llqs"></span><div id="OPT-RRs">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-opt-rrs-used-in-llqs" class="selfRef">OPT-RRs Used in LLQs</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Field Name</th>
              <th class="text-left" rowspan="1" colspan="1">Field Type</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NAME</td>
              <td class="text-left" rowspan="1" colspan="1">domain name</td>
              <td class="text-left" rowspan="1" colspan="1">MUST be 0 (root domain)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">TYPE</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">OPT (41)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">CLASS</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">0*</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">TTL</td>
              <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RDLEN</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">length of all RDATA</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">RDATA</td>
              <td class="text-left" rowspan="1" colspan="1">octet stream</td>
              <td class="text-left" rowspan="1" colspan="1">(see below)</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.2-3">
    * The CLASS field indicates, as per the EDNS(0) specification <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span>, the sender's UDP payload
    size. However, clients and servers are not required to determine their
    reassembly buffer size, path MTU, etc., to support LLQ. Thus, the sender
    of
    an LLQ Request or Response <span class="bcp14">MAY</span> set the CLASS field to 0.
    The recipient <span class="bcp14">MUST</span> ignore the class field if it is set to
    0.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">
    The RDATA of an EDNS(0) OPT pseudo‑RR consists of zero or more
    options
    of the form { OPTION‑CODE, OPTION‑LENGTH, OPTION‑DATA }
    packed together,
    with the RDLEN field set accordingly to indicate the total size.
    An LLQ OPTION is illustrated below.
    An EDNS(0) OPT pseudo‑RR may contain zero or more LLQ OPTIONS in
    addition
    to zero or more other EDNS(0) options.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<span id="name-llq-option"></span><div id="LLQ-OPT-FORMAT">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-llq-option" class="selfRef">LLQ OPTION</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Field Name</th>
              <th class="text-left" rowspan="1" colspan="1">Field Type</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">OPTION-CODE</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">LLQ (1)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">OPTION-LENGTH</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">Length of following fields (18)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LLQ-VERSION</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">Version of LLQ protocol implemented</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LLQ-OPCODE</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">Identifies LLQ operation</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LLQ-ERROR</td>
              <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
              <td class="text-left" rowspan="1" colspan="1">Identifies LLQ errors</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LLQ-ID</td>
              <td class="text-left" rowspan="1" colspan="1">u_int64_t</td>
              <td class="text-left" rowspan="1" colspan="1">Identifier for an LLQ</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">LLQ-LEASE</td>
              <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
              <td class="text-left" rowspan="1" colspan="1">Requested or granted life of LLQ, in seconds</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.2-6">
   The size and meaning of the OPTION‑CODE and OPTION‑LENGTH fields
   are as described in the EDNS(0) specification <span>[<a href="#RFC6891" class="xref">RFC6891</a>]</span>.  The remainder of the fields comprise the
   OPTION‑DATA of the EDNS(0) LLQ OPTION.  Since for LLQ the
   OPTION‑DATA is a
   fixed size, in EDNS(0) LLQ OPTIONS the OPTION‑LENGTH field always has
   the value 18.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">
   In keeping with Internet convention, all multi-byte numeric quantities
   (u_int16_t, u_int32_t, and u_int64_t)
   are represented in big endian byte order (most significant byte first).<a href="#section-3.2-7" class="pilcrow">¶</a></p>
</section>
</section>
<div id="address-port">
<section id="section-4">
      <h2 id="name-llq-address-and-port-identi">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-llq-address-and-port-identi" class="section-name selfRef">LLQ Address and Port Identification</a>
      </h2>
<p id="section-4-1">
   The client
   requires a mechanism to determine to which server it should send LLQ
   operations.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   Additionally, some firewalls block direct communication with a name server
   on port 53 to avoid spoof responses. However, this direct communication is
   necessary for LLQs. Thus, servers <span class="bcp14">MAY</span> listen for LLQs on a
   different port (typically 5352). Clients, therefore, also need a
   mechanism to determine to which port to send LLQ operations.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
   The client determines the server responsible for a given LLQ much as a
   client determines to which server to send a DNS dynamic update. The client
   begins by sending a standard DNS query for the name of the LLQ, with type
   SOA.  If the record exists, then the server <span class="bcp14">MUST</span> answer with
   that SOA record in the Answer section.  If a record of type SOA with the
   LLQ name does not exist, then the server <span class="bcp14">SHOULD</span> include an
   SOA record for that name's zone in the Authority section.  For example, a
   query for "_ftp._tcp.example.com" with type SOA, when there is no SOA
   record with that name, might return an SOA record named "example.com" in
   the Authority section.  If the named SOA record does not exist and the
   server fails to include the enclosing SOA record in the Authority section,
   the client strips the leading label from the name and tries again,
   repeating until an answer is received.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
   This iterative zone apex discovery algorithm is described in more detail in
   the DNS Push Notifications specification <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
   Upon learning the zone apex (SOA), the client then constructs and sends an
   SRV query for the name, "_dns‑llq._udp.&lt;zone&gt;",
   e.g., "_dns‑llq._udp.example.com".<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   An authoritative server for a zone implementing LLQ <span class="bcp14">MUST</span>
   answer with an SRV record <span>[<a href="#RFC2782" class="xref">RFC2782</a>]</span>
   for this name. The SRV RDATA is as follows:<a href="#section-4-6" class="pilcrow">¶</a></p>
<span id="name-srv-rdata"></span><div id="SRV-RDATA">
<table class="center" id="table-3">
        <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-srv-rdata" class="selfRef">SRV RDATA</a>
        </caption>
<tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">PRIORITY</td>
            <td class="text-left" rowspan="1" colspan="1">typically 0</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">WEIGHT</td>
            <td class="text-left" rowspan="1" colspan="1">typically 0</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">PORT</td>
            <td class="text-left" rowspan="1" colspan="1">typically 53 or 5352</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">TARGET</td>
            <td class="text-left" rowspan="1" colspan="1">name of server providing LLQs for the requested zone</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-4-8">
   The server <span class="bcp14">SHOULD</span> include the address record(s) for the
   target host in the Additional
   section of the response.<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9">
   If the server does not include the target host's address record(s) in the
   Additional
   section, the client <span class="bcp14">SHOULD</span> query explicitly for the address
   record(s)
   with the name of the SRV target.<a href="#section-4-9" class="pilcrow">¶</a></p>
<p id="section-4-10">
   The client <span class="bcp14">MUST</span> send all LLQ requests, refreshes, and
   acknowledgments to the name server specified in the SRV target, at the
   address contained in the address record for that target. Note that the
   queries described in this section (including those for SOA and SRV records)
   <span class="bcp14">MAY</span> be sent to an intermediate DNS recursive resolver --
   they
   need not be sent directly to the name server.<a href="#section-4-10" class="pilcrow">¶</a></p>
<p id="section-4-11">
   If, on issuing the SRV query, the client receives a negative
   response indicating that the SRV record does not exist, the client
   <span class="bcp14">SHOULD</span> conclude that the zone does not support LLQ.
   The client then <span class="bcp14">SHOULD NOT</span> send an LLQ request for
   the desired name, instead utilizing the behavior for LLQ-unaware
   servers described in <a href="#llq-setup" class="xref">Section 5</a>, "<a href="#llq-setup" class="xref">LLQ Setup</a>".<a href="#section-4-11" class="pilcrow">¶</a></p>
<p id="section-4-12">
   Servers should send all messages to the source address and port of
   the LLQ setup message received from the client.<a href="#section-4-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="llq-setup">
<section id="section-5">
      <h2 id="name-llq-setup">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-llq-setup" class="section-name selfRef">LLQ Setup</a>
      </h2>
<p id="section-5-1">
   An LLQ is initiated by a client and is completed via a four-way
   handshake. This handshake provides resilience to packet loss,
   demonstrates client reachability, and reduces denial-of-service
   attack opportunities (see <a href="#security-considerations" class="xref">Section 8</a>, "<a href="#security-considerations" class="xref">Security Considerations</a>").<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="setup-message-retransmission">
<section id="section-5.1">
        <h3 id="name-setup-message-retransmissio">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-setup-message-retransmissio" class="section-name selfRef">Setup Message Retransmission</a>
        </h3>
<p id="section-5.1-1">
   LLQ Setup Requests and Responses sent by the client <span class="bcp14">SHOULD</span>
   be
   retransmitted if no acknowledgments are received. The client
   <span class="bcp14">SHOULD</span>
   retry up to two more times (for a total of 3 attempts) before
   considering the server down or unreachable. The client <span class="bcp14">MUST</span>
   wait at
   least 2 seconds before the first retransmission and 4 seconds between
   the first and second retransmissions. The client <span class="bcp14">SHOULD</span>
   listen for a
   response for at least 8 seconds after the 3rd attempt before
   considering the server down or unreachable. Upon determining a
   server to be down, a client <span class="bcp14">MAY</span> periodically attempt to
   re-initiate
   an LLQ setup at a rate of not more than once per hour.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">
   Servers <span class="bcp14">MUST NOT</span> retransmit acknowledgments that do not
   generate
   responses from the client. Retransmission in setup is client driven,
   freeing servers from maintaining timers for incomplete LLQ setups. If
   servers receive duplicate messages from clients (perhaps due to the
   loss of the server's responses mid-flight), the server <span class="bcp14">MUST</span>
   resend
   its reply (possibly modifying the LLQ‑LEASE as described in <a href="#ack-answers" class="xref">Section 5.2.4</a>, "<a href="#ack-answers" class="xref">ACK + Answers</a>").<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">
   Servers <span class="bcp14">MUST NOT</span> garbage collect LLQs that fail to complete
   the four-way handshake until the initially granted LLQ‑LEASE has
   elapsed.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="four-way-handshake">
<section id="section-5.2">
        <h3 id="name-llq-setup-four-way-handshak">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-llq-setup-four-way-handshak" class="section-name selfRef">LLQ Setup Four-Way Handshake</a>
        </h3>
<p id="section-5.2-1">The four phases of the handshake include:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2-2.1">
            <dl class="dlParallel" id="section-5.2-2.1.1">
              <dt id="section-5.2-2.1.1.1">1)  Setup Request
</dt>
<dd style="margin-left: 12.0em" id="section-5.2-2.1.1.2">client to server, identifies LLQ(s) requested<a href="#section-5.2-2.1.1.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2-2.1.1.3">2)  Setup Challenge
</dt>
<dd style="margin-left: 12.0em" id="section-5.2-2.1.1.4">server to client, provides
unique identifiers for successful requested LLQs, and
error(s) for unsuccessful requested LLQs.<a href="#section-5.2-2.1.1.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2-2.1.1.5">3)  Challenge Response
</dt>
<dd style="margin-left: 12.0em" id="section-5.2-2.1.1.6">client to server, echoes identifier(s), demonstrating client's
reachability and willingness to participate<a href="#section-5.2-2.1.1.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2-2.1.1.7">4)  ACK + Answers
</dt>
<dd style="margin-left: 12.0em" id="section-5.2-2.1.1.8">server to client, confirms setup and provides initial answers<a href="#section-5.2-2.1.1.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</li>
</ul>
<div id="setup-request">
<section id="section-5.2.1">
          <h4 id="name-setup-request">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-setup-request" class="section-name selfRef">Setup Request</a>
          </h4>
<p id="section-5.2.1-1">
   A request for an LLQ is formatted like a standard DNS query but with
   an OPT pseudo‑RR containing LLQ metadata in its Additional
   section. LLQ
   Setup Requests are identified by the LLQ‑SETUP opcode and a
   zero‑valued LLQ‑ID.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">
   The request <span class="bcp14">MAY</span> contain multiple questions to set up
   multiple LLQs.
   A Setup Request consisting of multiple questions <span class="bcp14">MUST</span>
   contain multiple LLQ
   OPTIONS, one per question, with the LLQ OPTIONS in the
   same order as the questions they correspond to (i.e., the first
   LLQ OPTION corresponds to the first question, the second
   LLQ OPTION corresponds to the second question, etc.). If
   requesting multiple LLQs, clients <span class="bcp14">SHOULD</span> request the same
   LLQ‑LEASE
   for each LLQ. Requests over UDP <span class="bcp14">MUST NOT</span> contain multiple
   questions
   if doing so would cause the message to exceed a single IP packet.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3">
   A client <span class="bcp14">MUST NOT</span> request multiple identical LLQs (i.e.,
   containing
   the same qname/type/class) from the same source IP address and port.
   This requirement is to avoid unnecessary load on servers.

   In the case of multiple independent client implementations that
   may run on the same device without knowledge of each other,
   it is allowable if they by chance send LLQ requests for the same
   qname/type/class. These independent implementations on the same
   client will be using different source ports. Likewise,
   to the server,
   multiple independent clients behind the same NAT gateway
   will appear as if they were
   multiple independent clients using different ports on the same host,
   and this is also allowable.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<p id="section-5.2.1-4">
   The query <span class="bcp14">MUST NOT</span> be for record type ANY (255), class ANY
   (255), or
   class NONE (0).<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
<span id="name-setup-request-llq-option-fo"></span><div id="OPT-RR-LLQ">
<table class="center" id="table-4">
            <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-setup-request-llq-option-fo" class="selfRef">Setup Request LLQ OPTION Format</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Field Name</th>
                <th class="text-left" rowspan="1" colspan="1">Field Type</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-CODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-LENGTH</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Length of following fields (18)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-VERSION</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Version of LLQ protocol implemented by requester (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-OPCODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ-SETUP (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ERROR</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">NO-ERROR (0)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ID</td>
                <td class="text-left" rowspan="1" colspan="1">u_int64_t</td>
                <td class="text-left" rowspan="1" colspan="1">0</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-LEASE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
                <td class="text-left" rowspan="1" colspan="1">Desired life of LLQ request</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.2.1-6">The Setup Request LLQ OPTION <span class="bcp14">MUST</span> be repeated once for each
additional query in the
Question section.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="setup-challenge">
<section id="section-5.2.2">
          <h4 id="name-setup-challenge">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-setup-challenge" class="section-name selfRef">Setup Challenge</a>
          </h4>
<p id="section-5.2.2-1">
   Upon receiving an LLQ Setup Request, a server implementing LLQs will
   send a Setup Challenge to the requester (client). An LLQ Setup
   Challenge is a DNS response, with the DNS message ID matching that of
   the Setup Request, and with all questions contained in the Setup Request
   present
   in the Question section of the response. Additionally, the
   challenge contains a single OPT pseudo‑RR with an LLQ OPTION for
   each LLQ request, indicating the success or failure of each request.
   The LLQ OPTIONS <span class="bcp14">MUST</span> be in the same order as the questions
   they
   correspond to. Note that in a Setup Request containing multiple
   questions, some LLQs may succeed while others may fail.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<span id="name-setup-challenge-llq-option-"></span><div id="CHALLENGE-OPT-RR-DATA">
<table class="center" id="table-5">
            <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-setup-challenge-llq-option-" class="selfRef">Setup Challenge LLQ OPTION Format</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Field Name</th>
                <th class="text-left" rowspan="1" colspan="1">Field Type</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-CODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-LENGTH</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Length of following fields (18)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-VERSION</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Version of LLQ protocol implemented in server (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-OPCODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ-SETUP (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ERROR</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">[As Appropriate]</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ID</td>
                <td class="text-left" rowspan="1" colspan="1">u_int64_t</td>
                <td class="text-left" rowspan="1" colspan="1">[As Appropriate]</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-LEASE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
                <td class="text-left" rowspan="1" colspan="1">[As Appropriate]</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.2.2-3">
   The Setup Challenge LLQ OPTION <span class="bcp14">MUST</span> be repeated once for
   each query in the Questions
   section of the Setup Challenge.
   Further details for LLQ‑ERROR, LLQ‑ID and LLQ‑LEASE are
   given below.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2.2-4">
   LLQ‑ERROR:<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
<ul class="ulEmpty normal">
<li class="ulEmpty normal" id="section-5.2.2-5.1">
              <dl class="dlParallel" id="section-5.2.2-5.1.1">
                <dt id="section-5.2.2-5.1.1.1">NO-ERROR:
                </dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.2">The LLQ Setup Request was successful.<a href="#section-5.2.2-5.1.1.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-5.1.1.3">FORMAT-ERR:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.4">The LLQ was improperly formatted.  Note that if the rest of the DNS
message is properly formatted, the DNS header error code <span class="bcp14">MUST NOT</span> include a format error code, since to do so would cause ambiguity
between the case where a client sends a valid LLQ Setup Request to a server
that does not understand LLQ and the case where a client sends a malformed
LLQ Setup Request to a server that does understand LLQ.<a href="#section-5.2.2-5.1.1.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-5.1.1.5">SERV-FULL:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.6">The server cannot grant the LLQ request because it is overloaded or the
request exceeds the server's rate limit (see <a href="#security-considerations" class="xref">Section 8</a>, <a href="#security-considerations" class="xref">Security Considerations</a>).  Upon
returning this error, the server <span class="bcp14">MUST</span> include in the LLQ-LEASE
field a time interval, in seconds, after which the client may retry the LLQ
Setup.<a href="#section-5.2.2-5.1.1.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-5.1.1.7">STATIC:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.8">The data for this name and type is not expected to change frequently, and
the server, therefore, does not support the requested LLQ.  The client
<span class="bcp14">MUST</span> honor the resource record TTLs returned and
<span class="bcp14">MUST NOT</span> poll sooner than indicated by those TTLs,
nor should it retry the LLQ Setup for this name and type.<a href="#section-5.2.2-5.1.1.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-5.1.1.9">BAD-VERS:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.10">The protocol version specified in the client's Setup Request is not
supported by
the server.<a href="#section-5.2.2-5.1.1.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-5.1.1.11">UNKNOWN-ERR:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-5.1.1.12">The LLQ was not granted for some other reason not covered by the preceding
error code values.<a href="#section-5.2.2-5.1.1.12" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</li>
</ul>
<dl class="dlParallel" id="section-5.2.2-6">
            <dt id="section-5.2.2-6.1">LLQ‑ID:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-6.2">On success, a random number generated by the server that is unique on the
server for the
requested name/type/class. The LLQ‑ID <span class="bcp14">SHOULD</span> be an
unpredictable random number. A possible method of allocating LLQ‑IDs with
minimal bookkeeping would be to store the time, in seconds since the Epoch, in
the high 32 bits of the field, and a cryptographically generated 32-bit random
integer in the low 32 bits.<a href="#section-5.2.2-6.2" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-6.3">
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-6.4">
On error, the LLQ‑ID is set to 0.<a href="#section-5.2.2-6.4" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-6.5">LLQ‑LEASE:
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-6.6">On success, the actual life of the LLQ, in seconds.  Value may be greater
than, less than, or equal to the value requested by the client, as per the
server administrator's policy. The server <span class="bcp14">MAY</span> discard the LLQ
after this LLQ‑LEASE expires unless the LLQ has been renewed by the
client (see <a href="#LLQ-LLE" class="xref">Section 7</a>, "<a href="#LLQ-LLE" class="xref">LLQ Lease-Life Expiration</a>").  The server <span class="bcp14">MUST NOT</span> generate events (see
<a href="#event-responses" class="xref">Section 6</a>, "<a href="#event-responses" class="xref">Event Responses</a>") for expired LLQs.<a href="#section-5.2.2-6.6" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-6.7"></dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-6.8">
 On SERV‑FULL error, LLQ‑LEASE <span class="bcp14">MUST</span> be set to a time
 interval, in seconds, after which the client may retry the LLQ Setup.<a href="#section-5.2.2-6.8" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
<dt id="section-5.2.2-6.9">
</dt>
<dd style="margin-left: 9.0em" id="section-5.2.2-6.10">
On other errors, the LLQ‑LEASE <span class="bcp14">MUST</span> be set to 0.<a href="#section-5.2.2-6.10" class="pilcrow">¶</a>
</dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="challenge-response">
<section id="section-5.2.3">
          <h4 id="name-challenge-response">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-challenge-response" class="section-name selfRef">Challenge Response</a>
          </h4>
<p id="section-5.2.3-1">

   Upon issuing a Setup Request, a client listens for a Setup Challenge
   (<a href="#setup-challenge" class="xref">Section 5.2.2</a>) retransmitting the Setup Request as
   necessary
   (<a href="#setup-message-retransmission" class="xref">Section 5.1</a>). After
   receiving a successful Setup Challenge, the client <span class="bcp14">SHOULD</span>
   send a Challenge
   Response to the server. This Challenge Response is a DNS request
   with questions as in the Setup Request and Setup Challenge, and a single
   OPT pseudo‑RR in
   the Additional section, with the LLQ OPTIONS corresponding to the
   LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for
   each LLQ OPTION, the random LLQ‑ID and the granted LLQ‑LEASE). If
   the Challenge Response contains multiple questions, the first
   question <span class="bcp14">MUST</span> correspond to the first LLQ OPTION, etc.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<p id="section-5.2.3-2">
   If the Setup Request for a particular LLQ fails with a STATIC error, the
   client <span class="bcp14">MUST NOT</span>
   poll the server for that LLQ. The client <span class="bcp14">SHOULD</span> honor the
   resource record TTLs
   contained in the response.<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
<p id="section-5.2.3-3">
   If a Setup Request fails with a SERV‑FULL error, the client
   <span class="bcp14">MAY</span>
   retry the LLQ Setup Request (<a href="#setup-request" class="xref">Section 5.2.1</a>) after the time
   indicated in the
   LLQ‑LEASE field.<a href="#section-5.2.3-3" class="pilcrow">¶</a></p>
<p id="section-5.2.3-4">
   If the Setup Request fails with an error other than STATIC or
   SERV‑FULL, or the server is determined not to support LLQ
   (i.e., the client receives a DNS response with a nonzero RCODE,
   or a DNS response containing no LLQ option), the
   client <span class="bcp14">MAY</span> poll the server periodically with standard DNS
   queries,
   inferring Add and Remove Events (see <a href="#event-responses" class="xref">Section 6</a>,
   "Event Responses")
   by comparing answers to these queries. The client
   <span class="bcp14">SHOULD NOT</span> poll more than once every 15 minutes for a given
   query.
   The client <span class="bcp14">MUST NOT</span> poll if it receives a STATIC error code
   in the
   acknowledgment.<a href="#section-5.2.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ack-answers">
<section id="section-5.2.4">
          <h4 id="name-ack-answers">
<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-ack-answers" class="section-name selfRef">ACK + Answers</a>
          </h4>
<p id="section-5.2.4-1">

   Upon receiving a correct Challenge Response, a server <span class="bcp14">MUST</span>
   return an
   acknowledgment, completing the LLQ setup, and provide all current
   answers to the question(s).<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
<p id="section-5.2.4-2">
   To acknowledge a successful Challenge Response, i.e., a Challenge
   Response in which the LLQ‑ID and LLQ‑LEASE echoed by the client
   match the values issued by the server, the server <span class="bcp14">MUST</span> send
   a DNS
   response containing all available answers to the question(s)
   contained in the original Setup Request, along with all additional
   resource records appropriate for those answers in the Additional
   section. The Additional section also contains LLQ OPTIONS formatted as
   follows:<a href="#section-5.2.4-2" class="pilcrow">¶</a></p>
<span id="name-successful-ack-answers-llq-"></span><div id="SUCCESSFUL-ACK-ANSWERS-OPT-RR-RDATA">
<table class="center" id="table-6">
            <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-successful-ack-answers-llq-" class="selfRef">Successful ACK + Answers LLQ OPTION Format</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Field Name</th>
                <th class="text-left" rowspan="1" colspan="1">Field Type</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-CODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">OPTION-LENGTH</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Length of following fields (18)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-VERSION</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">Version of LLQ protocol implemented in server (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-OPCODE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">LLQ-SETUP (1)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ERROR</td>
                <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
                <td class="text-left" rowspan="1" colspan="1">NO-ERROR (0)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-ID</td>
                <td class="text-left" rowspan="1" colspan="1">u_int64_t</td>
                <td class="text-left" rowspan="1" colspan="1">Originally granted ID, echoed in client's Response</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">LLQ-LEASE</td>
                <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
                <td class="text-left" rowspan="1" colspan="1">Remaining life of LLQ, in seconds</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-5.2.4-4">
   If there is a significant delay in receiving a Challenge Response, or
   multiple Challenge Responses are issued (possibly because they were lost
   en route to the client, causing the client to resend the Challenge
   Response), the server <span class="bcp14">MAY</span> decrement the LLQ‑LEASE by
   the time
   elapsed since the Setup Challenge was initially issued.<a href="#section-5.2.4-4" class="pilcrow">¶</a></p>
<p id="section-5.2.4-5">
   If the setup is completed over UDP and all initially available
   answers to the question(s), additional records, and the OPT pseudo‑RR
   do not
   fit in a single IP packet, some or all additional records (excluding the
   OPT pseudo‑RR) <span class="bcp14">MUST</span> be omitted. If, after omission of
   all additional
   records, the answers still do not fit in a single message, answers
   <span class="bcp14">MUST</span> be removed until the message fits in a single IP
   packet. These
   answers not delivered in the ACK + Answers <span class="bcp14">MUST</span> be delivered
   without undue delay to the client via Add Events (<a href="#event-responses" class="xref">Section 6</a>, "<a href="#event-responses" class="xref">Event Responses</a>").<a href="#section-5.2.4-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="resource-record-ttls">
<section id="section-5.3">
        <h3 id="name-resource-record-ttls">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-resource-record-ttls" class="section-name selfRef">Resource Record TTLs</a>
        </h3>
<p id="section-5.3-1">
   The TTLs of resource records contained in answers to successful LLQs
   <span class="bcp14">SHOULD</span> be ignored by the client. The client
   <span class="bcp14">MAY</span> cache LLQ answers until the client receives a gratuitous
   announcement (see <a href="#event-responses" class="xref">Section 6</a>, "<a href="#event-responses" class="xref">Event Responses</a>")
   indicating that the answer to the LLQ has changed.  The client
   <span class="bcp14">SHOULD NOT</span> cache answers after the LLQs LLQ‑LEASE
   expires without being refreshed (see <a href="#LLQ-LLE" class="xref">Section 7</a>, "LLQ
   Lease-Life Expiration").  If an LLQ request fails, the client <span class="bcp14">SHOULD NOT</span> cache answers for a period longer than the client's polling
   interval.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
   Note that resource records intended specifically to be transmitted
   via LLQs (e.g., DNS-based Service Discovery resource records) may have
   unusually short TTLs. This is because it is assumed that the records
   may change frequently, and that a client's cache coherence will be
   maintained via the LLQ and gratuitous responses. Short TTLs prevent
   stale information from residing in intermediate DNS recursive resolvers
   that are
   not LLQ aware.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">
   TTLs of resource records included in the Additional section of an
   LLQ response (which do not directly answer the LLQ) <span class="bcp14">SHOULD</span>
   be honored
   by the client.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="event-responses">
<section id="section-6">
      <h2 id="name-event-responses">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-event-responses" class="section-name selfRef">Event Responses</a>
      </h2>
<p id="section-6-1">
   When a change ("event") occurs to a name server's zone, the server
   <span class="bcp14">MUST</span> check if the new or deleted resource records answer any
   LLQs.
   If so, the changes <span class="bcp14">MUST</span> be communicated to the LLQ
   requesters in
   the form of a gratuitous DNS response sent to the client, with the
   relevant question(s) in the Question section, and the corresponding answers
   in the Answer section. The response also includes
   an OPT pseudo‑RR in the Additional section. This OPT pseudo‑RR
   contains, in its
   RDATA, an LLQ OPTION for each LLQ being answered in the message. Each LLQ
   OPTION
   must include the LLQ‑ID. This reduces the potential for spoof events
   being sent to a client.<a href="#section-6-1" class="pilcrow">¶</a></p>
<span id="name-event-response-llq-option-f"></span><div id="EVENT-RESPONSE-OPT-RR-RDATA">
<table class="center" id="table-7">
        <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-event-response-llq-option-f" class="selfRef">Event Response LLQ OPTION Format</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Field Name</th>
            <th class="text-left" rowspan="1" colspan="1">Field Type</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">OPTION-CODE</td>
            <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
            <td class="text-left" rowspan="1" colspan="1">LLQ (1)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">OPTION-LENGTH</td>
            <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
            <td class="text-left" rowspan="1" colspan="1">Length of following fields (18)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">LLQ-VERSION</td>
            <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
            <td class="text-left" rowspan="1" colspan="1">Version of LLQ protocol implemented in server (1)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">LLQ-OPCODE</td>
            <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
            <td class="text-left" rowspan="1" colspan="1">LLQ-EVENT (3)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">LLQ-ERROR</td>
            <td class="text-left" rowspan="1" colspan="1">u_int16_t</td>
            <td class="text-left" rowspan="1" colspan="1">NO-ERROR (0)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">LLQ-ID</td>
            <td class="text-left" rowspan="1" colspan="1">u_int64_t</td>
            <td class="text-left" rowspan="1" colspan="1">[As Appropriate]</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">LLQ-LEASE</td>
            <td class="text-left" rowspan="1" colspan="1">u_int32_t</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-6-3">
   Gratuitous responses for a single LLQ <span class="bcp14">MAY</span> be batched such
   that
   multiple changes are communicated in a single message.
   Responses <span class="bcp14">MUST NOT</span> be batched if this would cause a message
   that
   would otherwise fit in a single IP packet to be truncated. While
   responses <span class="bcp14">MAY</span> be deferred to provide opportunities for
   batching,
   responses <span class="bcp14">SHOULD NOT</span> be delayed, for purposes of batching,
   for more
   than 30 seconds, as this would cause an unacceptable latency for the
   client.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
   After sending a gratuitous response, the server <span class="bcp14">MUST</span> listen
   for an
   acknowledgment from the client. If the client does not respond, the
   server <span class="bcp14">MUST</span> resend the response. The server
   <span class="bcp14">MUST</span> resend two times
   (for a total of 3 transmissions), after which the server
   <span class="bcp14">MUST</span>
   consider the client to be unreachable and delete its LLQ. The server
   <span class="bcp14">MUST</span> listen for 2 seconds before resending the response, 4
   more
   seconds before resending again, and must wait an additional 8
   seconds after the 3rd transmission before terminating the LLQ.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
   The DNS message header of the response <span class="bcp14">SHOULD</span> include an
   unpredictable
   random number in the DNS message ID field, which is to be echoed in
   the client's acknowledgment.<a href="#section-6-5" class="pilcrow">¶</a></p>
<section id="section-6.1">
        <h3 id="name-add-events">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-add-events" class="section-name selfRef">Add Events</a>
        </h3>
<p id="section-6.1-1">
   Add Events occur when a new resource record appears, usually as the
   result of a dynamic update <span>[<a href="#RFC2136" class="xref">RFC2136</a>]</span>, that
   answers an LLQ. This
   record must be sent in the Answer section of the event to the client.
   Records that normally accompany this record in responses <span class="bcp14">MAY</span>
   be
   included in the Additional section as per truncation restrictions
   described above.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-remove-events">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-remove-events" class="section-name selfRef">Remove Events</a>
        </h3>
<p id="section-6.2-1">
   Remove Events occur when a resource record previously sent to a
   client, either in an initial response or in an Add Event, becomes
   invalid (normally as a result of being removed via a dynamic update).
   The deleted resource record is sent in the Answer section of the
   event to the client. The resource record TTL is set to -1,
   indicating that the record has been removed.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-6.3">
        <h3 id="name-gratuitous-response-acknowl">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-gratuitous-response-acknowl" class="section-name selfRef">Gratuitous Response Acknowledgments</a>
        </h3>
<p id="section-6.3-1">
   Upon receiving a gratuitous response ("event"), the client
   <span class="bcp14">MUST</span> send
   an acknowledgment to the server. This acknowledgment is a DNS
   response echoing the OPT pseudo‑RR contained in the event, with the
   message
   ID of the gratuitous response echoed in the message header. The
   acknowledgment <span class="bcp14">MUST</span> be sent to the source IP address and
   port from
   which the event originated.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="LLQ-LLE">
<section id="section-7">
      <h2 id="name-llq-lease-life-expiration">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-llq-lease-life-expiration" class="section-name selfRef">LLQ Lease-Life Expiration</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-refresh-request">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-refresh-request" class="section-name selfRef">Refresh Request</a>
        </h3>
<p id="section-7.1-1">
   If the client desires to maintain the LLQ beyond the duration specified in
   the LLQ‑LEASE field of the ACK + Answers (<a href="#ack-answers" class="xref">Section 5.2.4</a>), the client <span class="bcp14">MUST</span> send a
   Refresh Request. A Refresh Request is identical to an LLQ Challenge
   Response (<a href="#challenge-response" class="xref">Section 5.2.3</a>) but with the LLQ‑OPCODE
   set to
   LLQ‑REFRESH. Unlike a Challenge Response, a Refresh Request returns no
   answers.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">
   The client <span class="bcp14">SHOULD</span> refresh an LLQ when 80% of its
   LLQ‑LEASE has
   elapsed.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">
   As a means of reducing network traffic, when constructing refresh
   messages the client <span class="bcp14">SHOULD</span> include all LLQs established with
   a given
   server, even those not yet close to expiration. However, at least
   one LLQ <span class="bcp14">MUST</span> have elapsed at least 80% of its original
   LLQ‑LEASE.
   The client <span class="bcp14">MUST NOT</span> include additional LLQs if doing so
   would cause
   the message to no longer fit in a single IP packet. In this case, the
   LLQs furthest from expiration should be omitted such that the message
   fits in a single IP packet.  (These LLQs <span class="bcp14">SHOULD</span> be refreshed
   in a
   separate message when 80% of one or more of their lease lives have
   elapsed.)  When refreshing multiple LLQs simultaneously, the message
   contains multiple questions and a single OPT pseudo‑RR with multiple
   LLQ
   OPTIONS, one per question, with the LLQ OPTIONS in
   the same order as the questions they correspond to.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">
   The client <span class="bcp14">SHOULD</span> specify the original LLQ‑LEASE
   granted in the LLQ
   response as the desired LLQ‑LEASE in the Refresh Request. If
   refreshing multiple LLQs simultaneously, the client <span class="bcp14">SHOULD</span>
   request
   the same LLQ‑LEASE for all LLQs being refreshed (with the exception
   of termination requests; see below).<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">
   To terminate an LLQ prior
   to its scheduled expiration (for instance, when the client terminates
   a DNS-based Service Discovery browse operation or when a client is about to go
   to sleep or shut down), the client specifies an LLQ‑LEASE value of 0.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
<p id="section-7.1-6">
   The client <span class="bcp14">MUST</span> listen for an acknowledgment from the
   server. The
   client <span class="bcp14">MAY</span> retry up to two more times (for a total of 3
   attempts)
   before considering the server down or unreachable. The client <span class="bcp14">MUST NOT</span> retry a first time before 90% of the LLQ‑LEASE has expired
   and
   <span class="bcp14">MUST NOT</span> retry again before 95% of the LLQ‑LEASE has
   expired. If
   the server is determined to be down, the client <span class="bcp14">MAY</span>
   periodically
   attempt to re-establish the LLQ via an LLQ Setup Request message.
   The client <span class="bcp14">MUST NOT</span> attempt the LLQ Setup Request more than
   once per
   hour.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
</section>
<section id="section-7.2">
        <h3 id="name-llq-refresh-acknowledgment">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-llq-refresh-acknowledgment" class="section-name selfRef">LLQ Refresh Acknowledgment</a>
        </h3>
<p id="section-7.2-1">
   Upon receiving an LLQ Refresh message, a server <span class="bcp14">MUST</span> send an
   acknowledgment of the Refresh. This acknowledgment is formatted like
   the "ACK + Answers" message described in <a href="#ack-answers" class="xref">Section 5.2.4</a>, but
   with the following variations:<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2-2.1">
            <p id="section-7.2-2.1.1">
   It contains no answers.<a href="#section-7.2-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-7.2-2.2">
            <p id="section-7.2-2.2.1">
   The LLQ‑OPCODE is set to LLQ‑REFRESH.<a href="#section-7.2-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-7.2-2.3">
            <p id="section-7.2-2.3.1">
   NO‑SUCH‑LLQ <span class="bcp14">MUST</span> be returned as an error code if
   the client attempts
   to refresh an expired or non-existent LLQ (as determined by the
   LLQ‑ID in the request).<a href="#section-7.2-2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="normal" id="section-7.2-2.4">
            <p id="section-7.2-2.4.1">
   The LLQ‑ID in the acknowledgment is set to the LLQ‑ID in the
   request.<a href="#section-7.2-2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</section>
</section>
</div>
<div id="security-considerations">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">
   In datagram-based protocols
   (i.e., protocols running over UDP, or directly over IP, or similar), servers
   may be susceptible to denial-of-service (DoS) attacks, and clients
   may be subjected to packet storms. Carefully designed mechanisms are needed
   to limit potential for these attacks.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
   Note: This section contains no new protocol elements -- it serves
   only to explain the rationale behind protocol elements described
   above as they relate to security.<a href="#section-8-2" class="pilcrow">¶</a></p>
<div id="server-dos">
<section id="section-8.1">
        <h3 id="name-server-dos">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-server-dos" class="section-name selfRef">Server DoS</a>
        </h3>
<p id="section-8.1-1">
   LLQs require that servers be stateful, maintaining entries for each LLQ
   over a potentially long period of time. If unbounded in quantity, these
   entries may overload the server. By returning SERV‑FULL in Setup
   Challenges, the server may limit the maximum number of LLQs it
   maintains. Additionally, the server may return SERV‑FULL to limit the
   number of LLQs requested for a single name and type, or by a single
   client. This throttling may be in the form of a hard limit, or, preferably,
   by token-bucket rate limiting. Such rate limiting should occur rarely in
   normal use and is intended to prevent DoS attacks -- thus, it is not built
   into the protocol explicitly but is instead implemented at the discretion
   of an administrator via the SERV‑FULL error and the LLQ‑LEASE
   field to indicate a retry time to the client.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8.2">
        <h3 id="name-client-packet-storms">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-client-packet-storms" class="section-name selfRef">Client Packet Storms</a>
        </h3>
<p id="section-8.2-1">
   In addition to protecting the server from DoS attacks, the LLQ protocol
   limits the ability of a malicious host to cause the server to flood a
   client with packets. This is achieved via the four-way handshake
   upon setup, demonstrating reachability and willingness of the client
   to participate, and by requiring that gratuitous responses be ACK'd
   by the client.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">
   Additionally, rate limiting by LLQ client address, as described in
   <a href="#server-dos" class="xref">Section 8.1</a>, serves to limit the number of packets that can
   be delivered to
   an unsuspecting client.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-8.3">
        <h3 id="name-spoofing">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-spoofing" class="section-name selfRef">Spoofing</a>
        </h3>
<p id="section-8.3-1">
   A large random ID greatly reduces the risk of an off-path attacker
   sending spoof packets to the client (containing spoof events)
   or to the server (containing phony requests or refreshes).<a href="#section-8.3-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<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">
  The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension.
  IANA has updated the record in the "DNS EDNS0 Option Codes (OPT)" registry
  from "On-hold" to "Optional" and has set the reference to this document.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">
  TCP and UDP ports 5352 have already been assigned for LLQ.  IANA has
  added a reference to this document.<a href="#section-9-2" class="pilcrow">¶</a></p>
</section>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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">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">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="RFC2782">[RFC2782]</dt>
<dd>
<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, P.</span><span class="refAuthor">, and L. Esibov</span>, <span class="refTitle">"A DNS RR for specifying the location of services (DNS SRV)"</span>, <span class="seriesInfo">RFC 2782</span>, <span class="seriesInfo">DOI 10.17487/RFC2782</span>, <time datetime="2000-02">February 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6891">[RFC6891]</dt>
<dd>
<span class="refAuthor">Damas, J.</span><span class="refAuthor">, Graff, M.</span><span class="refAuthor">, and P. Vixie</span>, <span class="refTitle">"Extension Mechanisms for DNS (EDNS(0))"</span>, <span class="seriesInfo">STD 75</span>, <span class="seriesInfo">RFC 6891</span>, <span class="seriesInfo">DOI 10.17487/RFC6891</span>, <time datetime="2013-04">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6891">https://www.rfc-editor.org/info/rfc6891</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8765">[RFC8765]</dt>
<dd>
<span class="refAuthor">Pusateri, T.</span><span class="refAuthor"> and S. Cheshire</span>, <span class="refTitle">"DNS Push Notifications"</span>, <span class="seriesInfo">RFC 8765</span>, <span class="seriesInfo">DOI 10.17487/RFC8765</span>, <time datetime="2020-06">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8765">https://www.rfc-editor.org/info/rfc8765</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<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">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="RFC4787">[RFC4787]</dt>
<dd>
<span class="refAuthor">Audet, F., Ed.</span><span class="refAuthor"> and C. Jennings</span>, <span class="refTitle">"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"</span>, <span class="seriesInfo">BCP 127</span>, <span class="seriesInfo">RFC 4787</span>, <span class="seriesInfo">DOI 10.17487/RFC4787</span>, <time datetime="2007-01">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4787">https://www.rfc-editor.org/info/rfc4787</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4953">[RFC4953]</dt>
<dd>
<span class="refAuthor">Touch, J.</span>, <span class="refTitle">"Defending TCP Against Spoofing Attacks"</span>, <span class="seriesInfo">RFC 4953</span>, <span class="seriesInfo">DOI 10.17487/RFC4953</span>, <time datetime="2007-07">July 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4953">https://www.rfc-editor.org/info/rfc4953</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5382">[RFC5382]</dt>
<dd>
<span class="refAuthor">Guha, S., Ed.</span><span class="refAuthor">, Biswas, K.</span><span class="refAuthor">, Ford, B.</span><span class="refAuthor">, Sivakumar, S.</span><span class="refAuthor">, and P. Srisuresh</span>, <span class="refTitle">"NAT Behavioral Requirements for TCP"</span>, <span class="seriesInfo">BCP 142</span>, <span class="seriesInfo">RFC 5382</span>, <span class="seriesInfo">DOI 10.17487/RFC5382</span>, <time datetime="2008-10">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5382">https://www.rfc-editor.org/info/rfc5382</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6281">[RFC6281]</dt>
<dd>
<span class="refAuthor">Cheshire, S.</span><span class="refAuthor">, Zhu, Z.</span><span class="refAuthor">, Wakikawa, R.</span><span class="refAuthor">, and L. Zhang</span>, <span class="refTitle">"Understanding Apple's Back to My Mac (BTMM) Service"</span>, <span class="seriesInfo">RFC 6281</span>, <span class="seriesInfo">DOI 10.17487/RFC6281</span>, <time datetime="2011-06">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6281">https://www.rfc-editor.org/info/rfc6281</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6762">[RFC6762]</dt>
<dd>
<span class="refAuthor">Cheshire, S.</span><span class="refAuthor"> and M. Krochmal</span>, <span class="refTitle">"Multicast DNS"</span>, <span class="seriesInfo">RFC 6762</span>, <span class="seriesInfo">DOI 10.17487/RFC6762</span>, <time datetime="2013-02">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6762">https://www.rfc-editor.org/info/rfc6762</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6763">[RFC6763]</dt>
<dd>
<span class="refAuthor">Cheshire, S.</span><span class="refAuthor"> and M. Krochmal</span>, <span class="refTitle">"DNS-Based Service Discovery"</span>, <span class="seriesInfo">RFC 6763</span>, <span class="seriesInfo">DOI 10.17487/RFC6763</span>, <time datetime="2013-02">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6763">https://www.rfc-editor.org/info/rfc6763</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6886">[RFC6886]</dt>
<dd>
<span class="refAuthor">Cheshire, S.</span><span class="refAuthor"> and M. Krochmal</span>, <span class="refTitle">"NAT Port Mapping Protocol (NAT-PMP)"</span>, <span class="seriesInfo">RFC 6886</span>, <span class="seriesInfo">DOI 10.17487/RFC6886</span>, <time datetime="2013-04">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6886">https://www.rfc-editor.org/info/rfc6886</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6887">[RFC6887]</dt>
<dd>
<span class="refAuthor">Wing, D., Ed.</span><span class="refAuthor">, Cheshire, S.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Penno, R.</span><span class="refAuthor">, and P. Selkirk</span>, <span class="refTitle">"Port Control Protocol (PCP)"</span>, <span class="seriesInfo">RFC 6887</span>, <span class="seriesInfo">DOI 10.17487/RFC6887</span>, <time datetime="2013-04">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6887">https://www.rfc-editor.org/info/rfc6887</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7857">[RFC7857]</dt>
<dd>
<span class="refAuthor">Penno, R.</span><span class="refAuthor">, Perreault, S.</span><span class="refAuthor">, Boucadair, M., Ed.</span><span class="refAuthor">, Sivakumar, S.</span><span class="refAuthor">, and K. Naito</span>, <span class="refTitle">"Updates to Network Address Translation (NAT) Behavioral Requirements"</span>, <span class="seriesInfo">BCP 127</span>, <span class="seriesInfo">RFC 7857</span>, <span class="seriesInfo">DOI 10.17487/RFC7857</span>, <time datetime="2016-04">April 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7857">https://www.rfc-editor.org/info/rfc7857</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8490">[RFC8490]</dt>
<dd>
<span class="refAuthor">Bellis, R.</span><span class="refAuthor">, Cheshire, S.</span><span class="refAuthor">, Dickinson, J.</span><span class="refAuthor">, Dickinson, S.</span><span class="refAuthor">, Lemon, T.</span><span class="refAuthor">, and T. Pusateri</span>, <span class="refTitle">"DNS Stateful Operations"</span>, <span class="seriesInfo">RFC 8490</span>, <span class="seriesInfo">DOI 10.17487/RFC8490</span>, <time datetime="2019-03">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8490">https://www.rfc-editor.org/info/rfc8490</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SYN">[SYN]</dt>
<dd>
<span class="refAuthor">Eddy, W.</span>, <span class="refTitle">"Defenses Against TCP SYN Flooding Attacks"</span>, <span class="seriesInfo">Volume 9</span>, <span class="seriesInfo">Number 4</span>, <span class="seriesInfo">The Internet Protocol Journal, Cisco              Systems</span>, <time datetime="2006-12">December 2006</time>, <span>&lt;<a href="https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf">https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="problems">
<section id="section-appendix.a">
      <h2 id="name-problems-with-the-llq-proto">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-problems-with-the-llq-proto" class="section-name selfRef">Problems with the LLQ Protocol</a>
      </h2>
<p id="section-appendix.a-1">
 In the course of using LLQ since 2005, some problems were discovered.
 Since no further work is being done on the LLQ protocol,
 this LLQ specification will not be updated to remedy these problems.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
 LLQ's IETF Standards Track successor, "DNS Push Notifications"
 <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>, does not
 suffer from these problems, so all existing LLQ
 implementations are <span class="bcp14">RECOMMENDED</span> to migrate to
 using DNS Push Notifications, and all new implementations are
 <span class="bcp14">RECOMMENDED</span> to implement DNS Push Notifications
 instead of LLQ.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">
 Known problems with LLQ are documented here as a cautionary tale
 about the challenges of building an application protocol directly
 using datagrams (like IP or UDP) without the benefit of a
 mature and thoroughly reviewed
 intervening transport layer (such as TCP or QUIC).<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">
 An LLQ "Setup Challenge" message from server to client is identical to
 an LLQ "ACK + Answers" message from server to client
 when there are no current answers for the query.
 If there is packet loss, retransmission, and duplication in the
 network,
 then a duplicated "Setup Challenge" message arriving late at the
 client
 would look like an "ACK + Answers" message with no answers,
 causing the client to clear its cache of any
 records matching the query.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">
 <a href="#setup-message-retransmission" class="xref">Section 5.1</a> of this LLQ
 specification states, "Servers <span class="bcp14">MUST NOT</span> garbage collect LLQs that fail to complete the
 four-way handshake until the initially granted LLQ-LEASE has
 elapsed." This is probably a mistake since it exposes LLQ
 servers to an easy resource-exhaustion denial-of-service
 attack.
 LLQ's replacement,
 DNS Push Notifications <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>,
 is built using DNS Stateful
 Operations <span>[<a href="#RFC8490" class="xref">RFC8490</a>]</span>, which
 uses TLS over TCP; a benefit of building on TCP is that there
 are already established industry best practices to guard
 against SYN flooding and similar attacks <span>[<a href="#SYN" class="xref">SYN</a>]</span> <span>[<a href="#RFC4953" class="xref">RFC4953</a>]</span>.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
<p id="section-appendix.a-6">
 The attempts here to pack multiple questions into a single UDP/IP
 packet for efficiency are awkward and lead to error-prone programming
 to deal with cases where some requests in a packet succeed and other
 requests in the same packet fail.  Fully specifying the correct
 handling in all possible cases would be a lot of work to document, a
 lot of work to implement, and even more work to thoroughly test.  DNS
 Push Notifications <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>
 avoids this problem by using an underlying stream protocol (TLS/TCP)
 to deal with packing small multiple messages into larger IP packets
 for efficiency.<a href="#section-appendix.a-6" class="pilcrow">¶</a></p>
<p id="section-appendix.a-7">
 In some cases, initial LLQ answers are delivered in the "ACK +
 Answers" message, and in other cases, such as when all the initial
 answers will not fit in a single IP packet, some of the initial
 answers are delivered in a subsequent "Add Event" message.
 Having two different ways to accomplish the same thing increases
 the possibility for programming errors.
 DNS Push Notifications <span>[<a href="#RFC8765" class="xref">RFC8765</a>]</span>
 corrects this error by having only one single consistent way to
 deliver results.<a href="#section-appendix.a-7" class="pilcrow">¶</a></p>
<p id="section-appendix.a-8">
 LLQ is built using UDP, and because UDP has no
 standardized way of indicating the start and end of a session,
 firewalls and NAT gateways tend to be fairly aggressive about
 recycling UDP mappings that they believe to be disused <span>[<a href="#RFC4787" class="xref">RFC4787</a>]</span> <span>[<a href="#RFC5382" class="xref">RFC5382</a>]</span> <span>[<a href="#RFC7857" class="xref">RFC7857</a>]</span>.
 Using a high keepalive traffic rate to maintain firewall or
 NAT mapping state could remedy this but would largely defeat
 the purpose of using LLQ in the first place, which is to
 provide efficient change notification without wasteful
 polling.  Because of this, existing LLQ clients use the NAT
 Port Mapping Protocol (NAT-PMP) <span>[<a href="#RFC6886" class="xref">RFC6886</a>]</span> and/or Port Control Protocol (PCP)
 <span>[<a href="#RFC6887" class="xref">RFC6887</a>]</span> to establish
 longer port mapping lifetimes.  This solves the problem but
 adds extra complexity and doesn't work with firewalls and NAT
 gateways that don't support NAT-PMP or PCP.  By using TCP
 instead of UDP, the DNS Push Notifications protocol benefits
 from better longevity of sessions through firewalls and NAT
 gateways that don't support NAT-PMP or PCP.<a href="#section-appendix.a-8" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-appendix.b">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.b-1">
   The concepts described in this document were originally explored,
   developed,
   and implemented with help from <span class="contact-name">Chris Sharp</span> and
   <span class="contact-name">Roger Pantos</span>.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2"><span class="contact-name">Kiren Sekar</span> made significant contributions to
      the first draft of this document and he wrote much of the code for the
      implementation of LLQ that shipped in Mac OS X 10.4 Tiger in April
      2005.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">Thanks to Independent Stream Editor <span class="contact-name">Adrian Farrel</span> for his support and
assistance in the publication of this RFC.<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.c">
      <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">Stuart Cheshire</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">CA</span> <span class="postal-code">95014</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20(408)%20996-1010" class="tel">+1 (408) 996-1010</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:cheshire@apple.com" class="email">cheshire@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Marc Krochmal</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">CA</span> <span class="postal-code">95014</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20(408)%20996-1010" class="tel">+1 (408) 996-1010</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:marc@apple.com" class="email">marc@apple.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>