File: rfc9267.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2176 lines) | stat: -rw-r--r-- 89,485 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9267: Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing</title>
<meta content="Stanislav Dashevskyi" name="author">
<meta content="Daniel dos Santos" name="author">
<meta content="Jos Wetzels" name="author">
<meta content="Amine Amri" name="author">
<meta content="
       
   This memo describes common vulnerabilities related to Domain Name
   System (DNS) resource record (RR) processing as seen in several DNS
   client implementations. These vulnerabilities may lead to successful
   Denial-of-Service and Remote Code Execution attacks against the
   affected software. Where applicable, violations of RFC 1035 are
   mentioned. 
    " name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="vulnerabilities" name="keyword">
<meta content="vulnerability" name="keyword">
<meta content="9267" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.10
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.7.1
    MarkupSafe 2.0.1
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9267.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;
  margin: 0 auto;
}

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

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

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

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

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

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

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

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

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

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9267" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-dashevskyi-dnsrr-antipatterns-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 9267</td>
<td class="center">Vulnerabilities in DNS RR Processing</td>
<td class="right">July 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Dashevskyi, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9267" class="eref">9267</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-07" class="published">July 2022</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. Dashevskyi</div>
<div class="org">Forescout Technologies</div>
</div>
<div class="author">
      <div class="author-name">D. dos Santos</div>
<div class="org">Forescout Technologies</div>
</div>
<div class="author">
      <div class="author-name">J. Wetzels</div>
<div class="org">Forescout Technologies</div>
</div>
<div class="author">
      <div class="author-name">A. Amri</div>
<div class="org">Forescout Technologies</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9267</h1>
<h1 id="title">Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   This memo describes common vulnerabilities related to Domain Name
   System (DNS) resource record (RR) processing as seen in several DNS
   client implementations. These vulnerabilities may lead to successful
   Denial-of-Service and Remote Code Execution attacks against the
   affected software. Where applicable, violations of RFC 1035 are
   mentioned.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This 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/rfc9267">https://www.rfc-editor.org/info/rfc9267</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) 2022 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="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-compression-pointer-and-off" class="xref">Compression Pointer and Offset Validation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-label-and-name-length-valid" class="xref">Label and Name Length Validation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-null-terminator-placement-v" class="xref">Null-Terminator Placement Validation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-response-data-length-valida" class="xref">Response Data Length Validation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-record-count-validation" class="xref">Record Count Validation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" 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-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<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">
   Major vulnerabilities in DNS implementations recently became evident and raised attention to this protocol as an important attack vector, as discussed in <span>[<a href="#SIGRED" class="xref">SIGRED</a>]</span>, <span>[<a href="#SADDNS" class="xref">SADDNS</a>]</span>, and
   <span>[<a href="#DNSPOOQ" class="xref">DNSPOOQ</a>]</span>, the latter being a set of 7 critical issues affecting the DNS
   forwarder "dnsmasq".<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   The authors of this memo have analyzed the DNS client implementations
   of several major TCP/IP protocol stacks and found a set of
   vulnerabilities that share common implementation flaws
   (anti-patterns). These flaws are related to processing DNS resource records (RRs)
   (discussed in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>) and may lead to critical security
   vulnerabilities.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   While implementation flaws may differ from one software project to
   another, these anti-patterns are highly likely to span
   multiple implementations. In fact, one of the first "Common Vulnerabilities and Exposures" (CVE) documents related to
   one of the anti-patterns <span>[<a href="#CVE-2000-0333" class="xref">CVE-2000-0333</a>]</span> dates back to the year 2000.
   The observations are not limited to DNS client implementations.
   Any software that processes DNS RRs may be affected, such as
   firewalls, intrusion detection systems, or general-purpose DNS packet
   dissectors (e.g., the DNS dissector in Wireshark; see <span>[<a href="#CVE-2017-9345" class="xref">CVE-2017-9345</a>]</span>). Similar issues may
   also occur in DNS-over-HTTPS <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span> and DNS-over-TLS <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span>
   implementations. However, any implementation that deals with the DNS
   wire format is subject to the considerations discussed in this document.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
   <span>[<a href="#I-D.ietf-dnsind-local-compression" class="xref">DNS-COMPRESSION</a>]</span> and <span>[<a href="#RFC5625" class="xref">RFC5625</a>]</span> briefly mention some of these
   anti-patterns, but the main purpose of this memo is to provide
   technical details behind these anti-patterns, so that the common
   mistakes can be eradicated.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
   We provide general recommendations on mitigating the anti-patterns.
   We also suggest that all implementations should drop
   malicious/malformed DNS replies and (optionally) log them.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-compression-pointer-and-off">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-compression-pointer-and-off" class="section-name selfRef">Compression Pointer and Offset Validation</a>
      </h2>
<p id="section-2-1">
   <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> defines the DNS message compression scheme that can be used
   to reduce the size of messages. When it is used, an entire domain
   name or several name labels are replaced with a (compression) pointer
   to a prior occurrence of the same name.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
   The compression pointer is a combination of two octets: the two most
   significant bits are set to 1, and the remaining 14 bits are the
   OFFSET field. This field specifies the offset from the beginning of
   the DNS header, at which another domain name or label is located:<a href="#section-2-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2-3">
<pre>
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1  1|                OFFSET                   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
</pre><a href="#section-2-3" class="pilcrow">¶</a>
</div>
<p id="section-2-4">
   The message compression scheme explicitly allows a domain name to be
   represented as one of the following: (1) a sequence of unpacked labels ending with a zero
   octet, (2) a pointer, or (3) a sequence of labels ending with a pointer.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">
   However, <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> does not explicitly state that blindly following
   compression pointers of any kind can be harmful <span>[<a href="#I-D.ietf-dnsind-local-compression" class="xref">DNS-COMPRESSION</a>]</span>, as we
   could not have had any assumptions about various implementations
   that would follow.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">
   Yet, any DNS packet parser that attempts to decompress domain names
   without validating the value of OFFSET is likely susceptible to
   memory corruption bugs and buffer overruns. These bugs make it easier to perform
   Denial-of-Service attacks and may result in successful Remote Code
   Execution attacks.<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">
   Pseudocode that illustrates a typical example of a broken domain name
   parsing implementation is shown below (<a href="#snippet_1" class="xref">Figure 1</a>):<a href="#section-2-7" class="pilcrow">¶</a></p>
<span id="name-a-broken-implementation-of-"></span><div id="snippet_1">
<figure id="figure-1">
        <div id="section-2-8.1">
<pre class="lang-pseudocode sourcecode">
 1: decompress_domain_name(*name, *dns_payload) {
 2:
 3:   name_buffer[255];
 4:   copy_offset = 0;
 5:
 6:   label_len_octet = name;
 7:   dest_octet = name_buffer;
 8:
 9:   while (*label_len_octet != 0x00) {
10:
11:      if (is_compression_pointer(*label_len_octet)) {
12:          ptr_offset = get_offset(label_len_octet,
                                        label_len_octet+1);
13:          label_len_octet = dns_payload + ptr_offset + 1;
14:      }
15:
16:      else {
17:          length = *label_len_octet;
18:          copy(dest_octet + copy_offset,
                        label_len_octet+1, *length);
19:
20:         copy_offset += length;
21:          label_len_octet += length + 1;
22:      }
23:
24:   }
25: }
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-a-broken-implementation-of-" class="selfRef">A Broken Implementation of a Function That Is Used for Decompressing DNS Domain Names (Pseudocode)</a>
        </figcaption></figure>
</div>
<p id="section-2-9">
   Such implementations typically have a dedicated function for
   decompressing domain names (for example, see <span>[<a href="#CVE-2020-24338" class="xref">CVE-2020-24338</a>]</span> and
   <span>[<a href="#CVE-2020-27738" class="xref">CVE-2020-27738</a>]</span>). Among other parameters, these functions may
   accept a pointer to the beginning of the first name label within an
   RR ("name") and a pointer to the beginning of the DNS payload to be
   used as a starting point for the compression pointer
   ("dns_payload"). The destination buffer for the domain name
   ("name_buffer") is typically limited to 255 bytes as per
   <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> and can be allocated either in the stack or in the heap
   memory region.<a href="#section-2-9" class="pilcrow">¶</a></p>
<p id="section-2-10">
   The code of the function in <a href="#snippet_1" class="xref">Figure 1</a> reads the domain name
   label by label from an RR until it reaches the NUL octet ("0x00") that
   signifies the end of a domain name. If the current label length octet
   ("label_len_octet") is a compression pointer, the code extracts the
   value of the compression offset and uses it to "jump" to another
   label length octet. If the current label length octet is not a
   compression pointer, the label bytes will be copied into the name
   buffer, and the number of bytes copied will correspond to the value
   of the current label length octet. After the copy operation, the code
   will move on to the next label length octet.<a href="#section-2-10" class="pilcrow">¶</a></p>
<p id="section-2-11">
   The first issue with this implementation is due to unchecked
   compression offset values. The second issue is due to the absence of
   checks that ensure that a pointer will eventually arrive at a
   decompressed domain label. We describe these issues in more detail
   below.<a href="#section-2-11" class="pilcrow">¶</a></p>
<p id="section-2-12">

   <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> states that a compression pointer is "a pointer to a prior occurance [sic] of the same name." Also, according to <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>,
   the maximum size of DNS packets that can be sent over UDP
   is limited to 512 octets.<a href="#section-2-12" class="pilcrow">¶</a></p>
<p id="section-2-13">
   The pseudocode in <a href="#snippet_1" class="xref">Figure 1</a>  violates these constraints, as it will
   accept a compression pointer that forces the code to read outside the
   bounds of a DNS packet. For instance, a compression pointer set to
   "0xffff" will produce an offset of 16383 octets, which is most
   definitely pointing to a label length octet somewhere past the bounds of the
   original DNS packet.  Supplying such offset values will most likely
   cause memory corruption issues and may lead to Denial-of-Service
   conditions (e.g., a Null pointer dereference after "label_len_octet"
   is set to an invalid address in memory). For additional examples,
   see <span>[<a href="#CVE-2020-25767" class="xref">CVE-2020-25767</a>]</span>, <span>[<a href="#CVE-2020-24339" class="xref">CVE-2020-24339</a>]</span>, and <span>[<a href="#CVE-2020-24335" class="xref">CVE-2020-24335</a>]</span>.<a href="#section-2-13" class="pilcrow">¶</a></p>
<p id="section-2-14">
   The pseudocode in <a href="#snippet_1" class="xref">Figure 1</a> allows jumping from a compression
   pointer to another compression pointer and does not restrict the
   number of such jumps. That is, if a label length octet that is
   currently being parsed is a compression pointer, the code will
   perform a jump to another label, and if that other label is a
   compression pointer as well, the code will perform another jump, and
   so forth until it reaches a decompressed label. This may lead to
   unforeseen side effects that result in security issues.<a href="#section-2-14" class="pilcrow">¶</a></p>
<p id="section-2-15">Consider the DNS packet excerpt illustrated below:<a href="#section-2-15" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2-16">
<pre>
        +----+----+----+----+----+----+----+----+----+----+----+----+
  +0x00 |    ID   |  FLAGS  | QDCOUNT | ANCOUNT | NSCOUNT | ARCOUNT |
        +----+----+----+----+----+----+----+----+----+----+----+----+
-&gt;+0x0c |0xc0|0x0c|   TYPE  |  CLASS  |0x04| t  | e  | s  | t  |0x03|
|       +----+--|-+----+----+----+----+----+----+----+----+----+----+
| +0x18 | c  | o| | m  |0x00|  TYPE   |  CLASS  | ................  |
|       +----+--|-+----+----+----+----+----+----+----+----+----+----+
|               |
-----------------
</pre><a href="#section-2-16" class="pilcrow">¶</a>
</div>
<p id="section-2-17">
   The packet begins with a DNS header at offset +0x00, and its DNS
   payload contains several RRs. The first RR begins at an offset of
   12 octets (+0x0c); its first label length octet is set to the
   value "0xc0", which indicates that it is a compression pointer. The
   compression pointer offset is computed from the two octets "0xc00c"
   and is equal to 12. Since the broken implementation in <a href="#snippet_1" class="xref">Figure 1</a>
   follows this offset value blindly, the pointer will jump back to
   the first octet of the first RR (+0x0c) over and over again.  The
   code in <a href="#snippet_1" class="xref">Figure 1</a> will enter an infinite-loop state, since it will
   never leave the "TRUE" branch of the "while" loop.<a href="#section-2-17" class="pilcrow">¶</a></p>
<p id="section-2-18">
   Apart from achieving infinite loops, the implementation flaws in
   <a href="#snippet_1" class="xref">Figure 1</a> make it possible to achieve various pointer loops that have
   other undesirable effects. For instance, consider the DNS packet excerpt shown
   below:<a href="#section-2-18" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2-19">
<pre>
        +----+----+----+----+----+----+----+----+----+----+----+----+
  +0x00 |    ID   |  FLAGS  | QDCOUNT | ANCOUNT | NSCOUNT | ARCOUNT |
        +----+----+----+----+----+----+----+----+----+----+----+----+
-&gt;+0x0c |0x04| t  | e  | s  | t  |0xc0|0x0c| ...................... |
|       +----+----+----+----+----+----+--|-+----+----+----+----+----+
|                                        |
------------------------------------------
</pre><a href="#section-2-19" class="pilcrow">¶</a>
</div>
<p id="section-2-20">
   With such a domain name, the implementation in <a href="#snippet_1" class="xref">Figure 1</a> will first
   copy the domain label at offset "0xc0" ("test"); it will then 
   fetch the next label length octet, which happens to be a compression pointer
   ("0xc0"). The compression pointer offset is computed from the two
   octets "0xc00c" and is equal to 12 octets. The code will jump back
   to offset "0xc0" where the first label "test" is located. The
   code will again copy the "test" label and then jump back to it,
   following the compression pointer, over and over again.<a href="#section-2-20" class="pilcrow">¶</a></p>
<p id="section-2-21">
   <a href="#snippet_1" class="xref">Figure 1</a> does not contain any logic that restricts multiple jumps
   from the same compression pointer and does not ensure that no more
   than 255 octets are copied into the name buffer ("name_buffer"). In
   fact,<a href="#section-2-21" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-22.1">the code will continue to write the label "test" into it,
   overwriting the name buffer and the stack of the heap metadata.<a href="#section-2-22.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-22.2">attackers would have a significant degree of freedom in
   constructing shell code, since they can create arbitrary copy chains
   with various combinations of labels and compression pointers.<a href="#section-2-22.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-23">Therefore, blindly following compression pointers may lead not only to
   Denial-of-Service conditions, as pointed out by <span>[<a href="#I-D.ietf-dnsind-local-compression" class="xref">DNS-COMPRESSION</a>]</span>, but also to successful Remote
   Code Execution attacks, as there may be other implementation issues present
   within the corresponding code.<a href="#section-2-23" class="pilcrow">¶</a></p>
<p id="section-2-24">
   Some implementations may not follow <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>, which states:<a href="#section-2-24" class="pilcrow">¶</a></p>
<blockquote id="section-2-25">The first two bits are ones.  This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less.  (The 10 and 01 combinations
are reserved for future use.)<a href="#section-2-25" class="pilcrow">¶</a>
</blockquote>
<p id="section-2-26">
Figures <a href="#snippet_2" class="xref">2</a> and <a href="#snippet_3" class="xref">3</a> show pseudocode that implements two functions that check whether a given octet is a compression pointer; <a href="#snippet_2" class="xref">Figure 2</a> shows a correct implementation, and <a href="#snippet_3" class="xref">Figure 3</a> shows an incorrect (broken) implementation.<a href="#section-2-26" class="pilcrow">¶</a></p>
<span id="name-correct-compression-pointer"></span><div id="snippet_2">
<figure id="figure-2">
        <div id="section-2-27.1">
<pre class="lang-pseudocode sourcecode">
1: unsigned char is_compression_pointer(*octet) {
2:     if ((*octet &amp; 0xc0) == 0xc0)
3:         return true;
4:     } else {
5:         return false;
6:     }
7: }
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-correct-compression-pointer" class="selfRef">Correct Compression Pointer Check</a>
        </figcaption></figure>
</div>
<span id="name-broken-compression-pointer-"></span><div id="snippet_3">
<figure id="figure-3">
        <div id="section-2-28.1">
<pre class="lang-pseudocode sourcecode">
1: unsigned char is_compression_pointer(*octet) {
2:     if (*octet &amp; 0xc0) {
3:         return true;
4:     } else {
5:         return false;
6:     }
7: }
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-broken-compression-pointer-" class="selfRef">Broken Compression Pointer Check</a>
        </figcaption></figure>
</div>
<p id="section-2-29">
The correct implementation (<a href="#snippet_2" class="xref">Figure 2</a>) ensures that the two most
significant bits of an octet are both set, while the broken
implementation (<a href="#snippet_3" class="xref">Figure 3</a>) would consider an octet with only one of
the two bits set to be a compression pointer. This is likely an
implementation mistake rather than an intended violation of
<span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>, because there are no benefits in supporting such
compression pointer values. The implementations related to
<span>[<a href="#CVE-2020-24338" class="xref">CVE-2020-24338</a>]</span> and <span>[<a href="#CVE-2020-24335" class="xref">CVE-2020-24335</a>]</span> had a broken
compression pointer check, similar to the code shown in <a href="#snippet_3" class="xref">Figure 3</a>.<a href="#section-2-29" class="pilcrow">¶</a></p>
<p id="section-2-30">
   While incorrect implementations alone do not lead to vulnerabilities,
   they may have unforeseen side effects when combined with other
   vulnerabilities. For instance, the first octet of the value "0x4130"
   may be incorrectly interpreted as a label length by a broken
   implementation. Such a label length (65) is invalid and is larger
   than 63 (as per <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>); a packet that has this value should
   be discarded. However, the function shown in <a href="#snippet_3" class="xref">Figure 3</a> will
   consider "0x41" to be a valid compression pointer, and the packet
   may pass the validation steps.<a href="#section-2-30" class="pilcrow">¶</a></p>
<p id="section-2-31">
   This might give attackers additional leverage for constructing
   payloads and circumventing the existing DNS packet validation
   mechanisms.<a href="#section-2-31" class="pilcrow">¶</a></p>
<p id="section-2-32">
   The first occurrence of a compression pointer in an RR (an octet with
   the two highest bits set to 1) must resolve to an octet within a DNS
   record with a value that is greater than 0 (i.e., it must not be a
   Null-terminator) and less than 64. The offset at which this octet is
   located must be smaller than the offset at which the compression
   pointer is located; once an implementation makes sure of that,
   compression pointer loops can never occur.<a href="#section-2-32" class="pilcrow">¶</a></p>
<p id="section-2-33">
   In small DNS implementations (e.g., embedded TCP/IP stacks),
   support for nested compression pointers (pointers that point to a
   compressed name) should be discouraged: there is very little to be
   gained in terms of performance versus the high probability of
   introducing errors such as those discussed above.<a href="#section-2-33" class="pilcrow">¶</a></p>
<p id="section-2-34">
   The code that implements domain name parsing should check the offset
   with respect to not only the bounds of a packet but also its
   position with respect to the compression pointer in question. A
   compression pointer must not be "followed" more than once. We have
   seen several implementations using a check that ensures that
   a compression pointer is not followed more than several times. A
   better alternative may be to ensure that the target of a compression
   pointer is always located before the location of the pointer in the
   packet.<a href="#section-2-34" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-label-and-name-length-valid">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-label-and-name-length-valid" class="section-name selfRef">Label and Name Length Validation</a>
      </h2>
<p id="section-3-1">
   <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> restricts the length of name labels to 63 octets and
   lengths of domain names to 255 octets (i.e., label octets and label
   length octets). Some implementations do not explicitly enforce these
   restrictions.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
   Consider the function "copy_domain_name()" shown in <a href="#snippet_4" class="xref">Figure 4</a> below.
   The function is a variant of the "decompress_domain_name()" function
   (<a href="#snippet_1" class="xref">Figure 1</a>), with the difference that it does not support compressed
   labels and only copies decompressed labels into the name buffer.<a href="#section-3-2" class="pilcrow">¶</a></p>
<span id="name-a-broken-implementation-of-a"></span><div id="snippet_4">
<figure id="figure-4">
        <div id="section-3-3.1">
<pre class="lang-pseudocode sourcecode">
 1: copy_domain_name(*name, *dns_payload) {
 2:
 3:   name_buffer[255];
 4:   copy_offset = 0;
 5:
 6:   label_len_octet = name;
 7:   dest_octet = name_buffer;
 8:
 9:   while (*label_len_octet != 0x00) {
10:
11:      if (is_compression_pointer(*label_len_octet)) {
12:          length = 2;
13:          label_len_octet += length + 1;
14:      }
15:
16:      else {
17:          length = *label_len_octet;
18:          copy(dest_octet + copy_offset,
                             label_len_octet+1, *length);
19:
20:         copy_offset += length;
21:          label_len_octet += length + 1;
22:      }
23:
24:  }
25: }
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-a-broken-implementation-of-a" class="selfRef">A Broken Implementation of a Function That Is Used for Copying Non-⁠compressed Domain Names</a>
        </figcaption></figure>
</div>
<p id="section-3-4">
   This implementation does not explicitly check for the value of the
   label length octet: this value can be up to 255 octets, and a single
   label can fill the name buffer. Depending on the memory layout of the
   target, how the name buffer is allocated, and the size of the
   malformed packet, it is possible to trigger various memory corruption
   issues.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
   Both Figures <a href="#snippet_1" class="xref">1</a> and <a href="#snippet_4" class="xref">4</a> restrict the size of the name buffer to 255
   octets; however, there are no restrictions on the actual number of
   octets that will be copied into this buffer. In this particular case,
   a subsequent copy operation (if another label is present in the
   packet) will write past the name buffer, allowing heap
   or stack metadata to be overwritten in a controlled manner.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">
   Similar examples of vulnerable implementations can be found in the
   code relevant to <span>[<a href="#CVE-2020-25110" class="xref">CVE-2020-25110</a>]</span>, <span>[<a href="#CVE-2020-15795" class="xref">CVE-2020-15795</a>]</span>, and
   <span>[<a href="#CVE-2020-27009" class="xref">CVE-2020-27009</a>]</span>.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">
   As a general recommendation, a domain label length octet must have a
   value of more than 0 and less than 64 <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>. If this is not the case,
   an invalid value has been provided within the packet, or a value at an
   invalid position might be interpreted as a domain name length due to other
   errors in the packet (e.g., misplaced Null-terminator or invalid
   compression pointer).<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">
   The number of domain label characters must correspond to the value of
   the domain label octet. To avoid possible errors when interpreting
   the characters of a domain label, developers may consider
   recommendations for the preferred domain name syntax outlined in
   <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">
   The domain name length must not be more than 255 octets, including
   the size of decompressed domain names. The NUL octet ("0x00") must
   be present at the end of the domain name and must be within the maximum name
   length (255 octets).<a href="#section-3-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-null-terminator-placement-v">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-null-terminator-placement-v" class="section-name selfRef">Null-Terminator Placement Validation</a>
      </h2>
<p id="section-4-1">
   A domain name must end with a NUL ("0x00") octet, as per <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>.
   The implementations shown in Figures <a href="#snippet_1" class="xref">1</a> and <a href="#snippet_4" class="xref">4</a> assume that this is the
   case for the RRs that they process; however, names that do not have a
   NUL octet placed at the proper position within an RR are not
   discarded.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
   This issue is closely related to the absence of label and name length
   checks. For example, the logic behind Figures <a href="#snippet_1" class="xref">1</a> and <a href="#snippet_4" class="xref">4</a> will continue
   to copy octets into the name buffer until a NUL octet is
   encountered. This octet can be placed at an arbitrary position
   within an RR or not placed at all.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
   Consider the pseudocode function shown in <a href="#snippet_5" class="xref">Figure 5</a>. The function
   returns the length of a domain name ("name") in octets to be used
   elsewhere (e.g., to allocate a name buffer of a certain size): for
   compressed domain names, the function returns 2; for decompressed
   names, it returns their true length using the "strlen(3)" function.<a href="#section-4-3" class="pilcrow">¶</a></p>
<span id="name-a-broken-implementation-of-a-"></span><div id="snippet_5">
<figure id="figure-5">
        <div id="section-4-4.1">
<pre class="lang-pseudocode sourcecode">
1: get_name_length(*name) {
2:
3:     if (is_compression_pointer(name))
4:         return 2;
5:
6:     name_len = strlen(name) + 1;
7:     return name_len;
8: }
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-a-broken-implementation-of-a-" class="selfRef">A Broken Implementation of a Function That Returns the Length of a Domain Name</a>
        </figcaption></figure>
</div>
<p id="section-4-5">
   "strlen(3)" is a standard C library function that returns the length
   of a given sequence of characters terminated by the NUL ("0x00")
   octet. Since this function also expects names to be explicitly
   Null-terminated, the return value "strlen(3)" may also be controlled
   by attackers. Through the value of "name_len", attackers may control
   the allocation of internal buffers or specify the number by octets
   copied into these buffers, or they may perform other operations, depending on the
   implementation specifics.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   The absence of explicit checks for placement of the NUL octet may also
   facilitate controlled memory reads and writes. An example of
   vulnerable implementations can be found in the code relevant to
   <span>[<a href="#CVE-2020-25107" class="xref">CVE-2020-25107</a>]</span>, <span>[<a href="#CVE-2020-17440" class="xref">CVE-2020-17440</a>]</span>, <span>[<a href="#CVE-2020-24383" class="xref">CVE-2020-24383</a>]</span>, and
   <span>[<a href="#CVE-2020-27736" class="xref">CVE-2020-27736</a>]</span>.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">
   As a general recommendation for mitigating such issues, developers
   should never trust user data to be Null-terminated. For example, to
   fix/mitigate the issue shown in the code in <a href="#snippet_5" class="xref">Figure 5</a>, developers should use
   the function "strnlen(3)", which reads at most X characters (the second
   argument of the function), and ensure that X is not larger than the
   buffer allocated for the name.<a href="#section-4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-response-data-length-valida">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-response-data-length-valida" class="section-name selfRef">Response Data Length Validation</a>
      </h2>
<p id="section-5-1">
   As stated in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>, every RR contains a variable-length string of
   octets that contains the retrieved resource data (RDATA) (e.g., an IP
   address that corresponds to a domain name in question). The length of
   the RDATA field is regulated by the resource data length field
   (RDLENGTH), which is also present in an RR.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
   Implementations that process RRs may not check for the validity of
   the RDLENGTH field value when retrieving RDATA. Failing to do so may
   lead to out-of-bound read issues, whose impact may
   vary significantly, depending on the implementation specifics. We have
   observed instances of Denial-of-Service conditions and information
   leaks.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
   Therefore, the value of the data length byte in response DNS records
   (RDLENGTH) must reflect the number of bytes available in the field
   that describes the resource (RDATA). The format of RDATA must
   conform to the TYPE and CLASS fields of the RR.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
   Examples of vulnerable implementations can be found in the code
   relevant to <span>[<a href="#CVE-2020-25108" class="xref">CVE-2020-25108</a>]</span>, <span>[<a href="#CVE-2020-24336" class="xref">CVE-2020-24336</a>]</span>, and <span>[<a href="#CVE-2020-27009" class="xref">CVE-2020-27009</a>]</span>.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-record-count-validation">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-record-count-validation" class="section-name selfRef">Record Count Validation</a>
      </h2>
<p id="section-6-1">
   According to <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span>, the DNS header contains four two-octet
   fields that specify the amount of question records (QDCOUNT), answer
   records (ANCOUNT), authority records (NSCOUNT), and additional
   records (ARCOUNT).<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
   <a href="#snippet_6" class="xref">Figure 6</a> illustrates a recurring implementation anti-pattern for a
   function that processes DNS RRs. The function "process_dns_records()"
   extracts the value of ANCOUNT ("num_answers") and the pointer to the
   DNS data payload ("data_ptr"). The function processes answer records
   in a loop, decrementing the "num_answers" value after processing each
   record until the value of "num_answers" becomes zero. For
   simplicity, we assume that there is only one domain name per answer.
   Inside the loop, the code calculates the domain name length
   ("name_length") and adjusts the data payload pointer ("data_ptr") by the
   offset that corresponds to "name_length + 1", so that the pointer
   lands on the first answer record. Next, the answer record is
   retrieved and processed, and the "num_answers" value is decremented.<a href="#section-6-2" class="pilcrow">¶</a></p>
<span id="name-a-broken-implementation-of-a-f"></span><div id="snippet_6">
<figure id="figure-6">
        <div id="section-6-3.1">
<pre class="lang-pseudocode sourcecode">
 1: process_dns_records(dns_header, ...) {
        // ...
 2:     num_answers = dns_header-&gt;ancount
 3:     data_ptr = dns_header-&gt;data
 4:
 5:     while (num_answers &gt; 0) {
 6:         name_length = get_name_length(data_ptr);
 7:         data_ptr += name_length + 1;
 8:
 9:         answer = (struct dns_answer_record *)data_ptr;
10:
11:         // process the answer record
12:
13:         --num_answers;
14:     }
        // ...
15: }
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-a-broken-implementation-of-a-f" class="selfRef">A Broken Implementation of a Function That Processes RRs</a>
        </figcaption></figure>
</div>
<p id="section-6-4">
   If the ANCOUNT number retrieved from the header
   ("dns_header-&gt;ancount") is not checked against the amount of data
   available in the packet and it is, for example, larger than the number of
   answer records available, the data pointer ("data_ptr") will read outside
   the bounds of the packet.  This may result in Denial-of-Service
   conditions.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
   In this section, we used an example of processing answer records.
   However, the same logic is often reused for implementing the
   processing of other types of records, e.g., the number of question
   (QDCOUNT), authority (NSCOUNT), and additional (ARCOUNT) records. The
   specified numbers of these records must correspond to the actual data
   present within the packet. Therefore, all record count fields must
   be checked before fully parsing the contents of a packet.
   Specifically, <span><a href="https://www.rfc-editor.org/rfc/rfc5625#section-6.3" class="relref">Section 6.3</a> of [<a href="#RFC5625" class="xref">RFC5625</a>]</span> recommends that such malformed
   DNS packets should be dropped and (optionally) logged.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">
   Examples of vulnerable implementations can be found in the code
   relevant to <span>[<a href="#CVE-2020-25109" class="xref">CVE-2020-25109</a>]</span>, <span>[<a href="#CVE-2020-24340" class="xref">CVE-2020-24340</a>]</span>, <span>[<a href="#CVE-2020-24334" class="xref">CVE-2020-24334</a>]</span>, and
   <span>[<a href="#CVE-2020-27737" class="xref">CVE-2020-27737</a>]</span>.<a href="#section-6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">
   Security issues are discussed throughout this memo; it
   discusses implementation flaws (anti-patterns) that affect the
   functionality of processing DNS RRs. The presence of such
   anti-patterns leads to bugs that cause buffer overflows,
   read-out-of-bounds, and infinite-loop issues. These issues have the
   following security impacts: information leaks, Denial-of-Service attacks, and
   Remote Code Execution attacks.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
   This document lists general recommendations for the developers of DNS
   record parsing functionality that allow those developers to prevent such
   implementation flaws, e.g., by rigorously checking the data received
   over the wire before processing it.<a href="#section-7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">
   This document has no IANA actions. Please see
   <span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span> for a complete review of the IANA considerations
   introduced by DNS.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.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" class="refDate">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5625">[RFC5625]</dt>
      <dd>
<span class="refAuthor">Bellis, R.</span>, <span class="refTitle">"DNS Proxy Implementation Guidelines"</span>, <span class="seriesInfo">BCP 152</span>, <span class="seriesInfo">RFC 5625</span>, <span class="seriesInfo">DOI 10.17487/RFC5625</span>, <time datetime="2009-08" class="refDate">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5625">https://www.rfc-editor.org/info/rfc5625</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CVE-2000-0333">[CVE-2000-0333]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2000-0333: A denial-of-service vulnerability in tcpdump, Ethereal, and other sniffer packages via malformed DNS packets"</span>, <time datetime="2000" class="refDate">2000</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0333">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0333</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2017-9345">[CVE-2017-9345]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2017-9345: An infinite loop in the DNS dissector of Wireshark"</span>, <time datetime="2017" class="refDate">2017</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9345">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9345</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-15795">[CVE-2020-15795]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-15795: A denial-of-service and remote code execution vulnerability DNS domain name label parsing functionality of Nucleus NET"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15795">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15795</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-17440">[CVE-2020-17440]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-17440 A denial-of-service vulnerability in the DNS name parsing implementation of uIP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17440">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17440</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24334">[CVE-2020-24334]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24334: An out-of-bounds read and denial-of-service vulnerability in the DNS response parsing functionality of uIP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24334">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24334</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24335">[CVE-2020-24335]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24335: A memory corruption vulnerability in domain name parsing routines of uIP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24335">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24335</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24336">[CVE-2020-24336]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24336: A buffer overflow vulnerability in the DNS implementation of Contiki and Contiki-NG"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24336">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24336</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24338">[CVE-2020-24338]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24338: A denial-of-service and remote code execution vulnerability in the DNS domain name record decompression functionality of picoTCP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24338">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24338</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24339">[CVE-2020-24339]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24339: An out-of-bounds read and denial-of-service vulnerability in the DNS domain name record decompression functionality of picoTCP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24339">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24339</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24340">[CVE-2020-24340]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24340: An out-of-bounds read and denial-of-service vulnerability in the DNS response parsing functionality of picoTCP"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24340">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-24383">[CVE-2020-24383]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-24383: An information leak and denial-of-service vulnerability while parsing mDNS resource records in FNET"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24383">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24383</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-25107">[CVE-2020-25107]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-25107: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25107">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25107</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-25108">[CVE-2020-25108]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-25108: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25108">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25108</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-25109">[CVE-2020-25109]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-25109: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25109">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25109</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-25110">[CVE-2020-25110]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-25110: A denial-of-service and remote code execution vulnerability in the DNS implementation of Ethernut Nut/OS"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25110">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25110</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-25767">[CVE-2020-25767]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-25767: An out-of-bounds read and denial-of-service vulnerability in the DNS name parsing routine of HCC Embedded NicheStack"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25767">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25767</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-27009">[CVE-2020-27009]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-27009: A denial-of-service and remote code execution vulnerability DNS domain name record decompression functionality of Nucleus NET"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27009">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27009</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-27736">[CVE-2020-27736]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-27736: An information leak and denial-of-service vulnerability in the DNS name parsing functionality of Nucleus NET"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27736">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27736</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-27737">[CVE-2020-27737]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-27737: An information leak and denial-of-service vulnerability in the DNS response parsing functionality of Nucleus NET"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27737">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27737</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CVE-2020-27738">[CVE-2020-27738]</dt>
        <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-27738: A denial-of-service and remote code execution vulnerability DNS domain name record decompression functionality of Nucleus NET"</span>, <time datetime="2021" class="refDate">2021</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27738">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27738</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-dnsind-local-compression">[DNS-COMPRESSION]</dt>
        <dd>
<span class="refAuthor">Koch, P.</span>, <span class="refTitle">"A New Scheme for the Compression of Domain Names"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dnsind-local-compression-05</span>, <time datetime="1999-06-30" class="refDate">30 June 1999</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-dnsind-local-compression-05">https://datatracker.ietf.org/doc/html/draft-ietf-dnsind-local-compression-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DNSPOOQ">[DNSPOOQ]</dt>
        <dd>
<span class="refAuthor">Kol, M.</span> and <span class="refAuthor">S. Oberman</span>, <span class="refTitle">"DNSpooq: Cache Poisoning and RCE in Popular DNS Forwarder dnsmasq"</span>, <span class="refContent">JSOF Technical Report</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq-Technical-WP.pdf">https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq-Technical-WP.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6895">[RFC6895]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>, <span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6895">https://www.rfc-editor.org/info/rfc6895</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7858">[RFC7858]</dt>
        <dd>
<span class="refAuthor">Hu, Z.</span>, <span class="refAuthor">Zhu, L.</span>, <span class="refAuthor">Heidemann, J.</span>, <span class="refAuthor">Mankin, A.</span>, <span class="refAuthor">Wessels, D.</span>, and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Specification for DNS over Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 7858</span>, <span class="seriesInfo">DOI 10.17487/RFC7858</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7858">https://www.rfc-editor.org/info/rfc7858</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8484">[RFC8484]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span> and <span class="refAuthor">P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SADDNS">[SADDNS]</dt>
        <dd>
<span class="refAuthor">Man, K.</span>, <span class="refAuthor">Qian, Z.</span>, <span class="refAuthor">Wang, Z.</span>, <span class="refAuthor">Zheng, X.</span>, <span class="refAuthor">Huang, Y.</span>, and <span class="refAuthor">H. Duan</span>, <span class="refTitle">"DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels"</span>, <span class="refContent">Proc. 2020 ACM SIGSAC Conference on Computer and Communications Security, CCS '20</span>, <span class="seriesInfo">DOI 10.1145/3372297.3417280</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://dl.acm.org/doi/pdf/10.1145/3372297.3417280">https://dl.acm.org/doi/pdf/10.1145/3372297.3417280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SIGRED">[SIGRED]</dt>
      <dd>
<span class="refAuthor">Common Vulnerabilities and Exposures</span>, <span class="refTitle">"CVE-2020-1350: A remote code execution vulnerability in Windows Domain Name System servers"</span>, <time datetime="2020" class="refDate">2020</time>, <span>&lt;<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1350">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1350</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgements">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
   We would like to thank <span class="contact-name">Shlomi Oberman</span>, who has greatly contributed to
   the research that led to the creation of this document.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stanislav Dashevskyi</span></div>
<div dir="auto" class="left"><span class="org">Forescout Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">John F. Kennedylaan, 2</span></div>
<div dir="auto" class="left">
<span class="postal-code">5612AB</span> <span class="locality">Eindhoven</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:stanislav.dashevskyi@forescout.com" class="email">stanislav.dashevskyi@forescout.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Daniel dos Santos</span></div>
<div dir="auto" class="left"><span class="org">Forescout Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">John F. Kennedylaan, 2</span></div>
<div dir="auto" class="left">
<span class="postal-code">5612AB</span> <span class="locality">Eindhoven</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:daniel.dossantos@forescout.com" class="email">daniel.dossantos@forescout.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jos Wetzels</span></div>
<div dir="auto" class="left"><span class="org">Forescout Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">John F. Kennedylaan, 2</span></div>
<div dir="auto" class="left">
<span class="postal-code">5612AB</span> <span class="locality">Eindhoven</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jos.wetzels@forescout.com" class="email">jos.wetzels@forescout.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Amine Amri</span></div>
<div dir="auto" class="left"><span class="org">Forescout Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">John F. Kennedylaan, 2</span></div>
<div dir="auto" class="left">
<span class="postal-code">5612AB</span> <span class="locality">Eindhoven</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:amine.amri@forescout.com" class="email">amine.amri@forescout.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>