olaf/in-tree-hints
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b69bb416630d52564d6a7baf436e162e8e875ace
in-tree-hints/draft-kolkman-dns-in-tree-hints-00-20260317.html
olaf b69bb41663 00 version 20260317
2026-03-17 02:17:46 +00:00

1844 lines
68 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html lang="en" class="Internet-Draft">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>In-Tree Hints for DNS Resiliency</title>
<meta content="Olaf Kolkman" name="author">
<meta content="
We present a methodology by which networks that rely very strongly on
specific domain names can become more resilience to failures in the parent domain.
The approach presented uses a hints-file-like mechanism in recursive
nameservers in addition to having the authoritative servers follow a
few operational practices.
The suggested method can be seen as a means for increasing digital
sovereignty. We describe the approach, the necessary operational
practices, and the dilemmas this approach introduces.
" name="description">
<meta content="xml2rfc 3.31.0" name="generator">
<meta content="Internet-Draft" name="keyword">
<meta content="draft-kolkman-in-tree-hints" name="ietf.draft">
<!-- Generator version information:
xml2rfc 3.31.0
Python 3.13.12
ConfigArgParse 1.7.1
google-i18n-address 3.1.1
intervaltree 3.2.1
Jinja2 3.1.6
lxml 6.0.2
platformdirs 4.5.1
pycountry 24.6.1
pypdf 6.7.0
PyYAML 6.0.3
requests 2.32.5
wcwidth 0.4.0
-->
<link href="draft-kolkman-dns-in-tree-hints-00-20260317.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 necessary during the development of the v3
formatters.
*/
/* fonts */
@import url('https://static.ietf.org/fonts/noto-sans/import.css'); /* Sans-serif */
@import url('https://static.ietf.org/fonts/noto-serif/import.css'); /* Serif (print) */
@import url('https://static.ietf.org/fonts/roboto-mono/import.css'); /* Monospace */
:root {
--font-sans: 'Noto Sans', Arial, Helvetica, sans-serif;
--font-serif: 'Noto Serif', 'Times', 'Times New Roman', serif;
--font-mono: 'Roboto Mono', Courier, 'Courier New', monospace;
}
@viewport {
zoom: 1.0;
}
@-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: var(--font-sans);
line-height: 1.6;
scroll-behavior: smooth;
overflow-wrap: break-word;
}
.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;
}
@media print {
svg {
max-height: 850px;
max-width: 660px;
}
}
svg[font-family~="serif" i], svg [font-family~="serif" i] {
font-family: var(--font-serif);
}
svg[font-family~="sans-serif" i], svg [font-family~="sans-serif" i] {
font-family: var(--font-sans);
}
svg[font-family~="monospace" i], svg [font-family~="monospace" i] {
font-family: var(--font-mono);
}
.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 {
display: table;
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 {
background-color: #f9f9f9;
font-family: var(--font-mono);
}
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;
}
blockquote > *:last-child {
margin-bottom: 0;
}
cite {
display: block;
text-align: right;
font-style: italic;
}
.xref {
overflow-wrap: normal;
}
/* 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 {
max-width: 100%;
}
}
#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;
}
.refSubseries {
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: var(--font-sans);
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;
}
.breakable pre {
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 following 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 {
font-size: 95%;
}
/* Fix the height/width aspect for ascii art*/
.sourcecode pre,
.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 information 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,
.artwork > pre,
.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: upper-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 slightly */
table {
border: 1px solid #ddd;
}
td {
border-top: 1px solid #ddd;
}
tr {
break-inside: avoid;
}
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 bottom 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, dt tt, dt code {
background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
margin-top: 0.5px;
}
/* Tweak the compact 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 > blockquote:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div.sourcecode:first-child,
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:only-child {
margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<script type="application/javascript">async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(let t=0;t<e.length;t++)if(/#identifiers/.exec(e[t].selectorText)){const a=e[t].cssText.replace("#identifiers","#external-updates");document.styleSheets[0].insertRule(a,document.styleSheets[0].cssRules.length)}}catch(e){console.log(e)}const e=document.getElementById("external-metadata");if(e)try{var t,a="",o=function(e){const t=document.getElementsByTagName("meta");for(let a=0;a<t.length;a++)if(t[a].getAttribute("name")===e)return t[a].getAttribute("content");return""}("rfc.number");if(o){t="https://www.rfc-editor.org/rfc/rfc"+o+".json";try{const e=await fetch(t);a=await e.json()}catch(e){t=document.URL.indexOf("html")>=0?document.URL.replace(/html$/,"json"):document.URL+".json";const o=await fetch(t);a=await o.json()}}if(!a)return;e.style.display="block";const s="",d="https://datatracker.ietf.org/doc",n="https://datatracker.ietf.org/ipr/search",c="https://www.rfc-editor.org/info",l=a.doc_id.toLowerCase(),i=a.doc_id.slice(0,3).toLowerCase(),f=a.doc_id.slice(3).replace(/^0+/,""),u={status:"Status",obsoletes:"Obsoletes",obsoleted_by:"Obsoleted By",updates:"Updates",updated_by:"Updated By",see_also:"See Also",errata_url:"Errata"};let h="<dl style='overflow:hidden' id='external-updates'>";["status","obsoletes","obsoleted_by","updates","updated_by","see_also","errata_url"].forEach(e=>{if("status"==e){a[e]=a[e].toLowerCase();var t=a[e].split(" "),o=t.length,w="",p=1;for(let e=0;e<o;e++)p<o?w=w+r(t[e])+" ":w+=r(t[e]),p++;a[e]=w}else if("obsoletes"==e||"obsoleted_by"==e||"updates"==e||"updated_by"==e){var g,m="",b=1;g=a[e].length;for(let t=0;t<g;t++)a[e][t]&&(a[e][t]=String(a[e][t]).toLowerCase(),m=b<g?m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>, ":m+"<a href='"+s+"/rfc/".concat(a[e][t])+"'>"+a[e][t].slice(3)+"</a>",b++);a[e]=m}else if("see_also"==e){var y,L="",C=1;y=a[e].length;for(let t=0;t<y;t++)if(a[e][t]){a[e][t]=String(a[e][t]);var _=a[e][t].slice(0,3),v=a[e][t].slice(3).replace(/^0+/,"");L=C<y?"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>, ":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>, ":"RFC"!=_?L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+_+" "+v+"</a>":L+"<a href='"+s+"/info/"+_.toLowerCase().concat(v.toLowerCase())+"'>"+v+"</a>",C++}a[e]=L}else if("errata_url"==e){var R="";R=a[e]?R+"<a href='"+a[e]+"'>Errata exist</a> | <a href='"+d+"/"+l+"'>Datatracker</a>| <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>":"<a href='"+d+"/"+l+"'>Datatracker</a> | <a href='"+n+"/?"+i+"="+f+"&submit="+i+"'>IPR</a> | <a href='"+c+"/"+l+"'>Info page</a>",a[e]=R}""!=a[e]?"Errata"==u[e]?h+=`<dt>More info:</dt><dd>${a[e]}</dd>`:h+=`<dt>${u[e]}:</dt><dd>${a[e]}</dd>`:"Errata"==u[e]&&(h+=`<dt>More info:</dt><dd>${a[e]}</dd>`)}),h+="</dl>",e.innerHTML=h}catch(e){console.log(e)}else console.log("Could not locate metadata <div> element");function r(e){return e.charAt(0).toUpperCase()+e.slice(1)}}window.removeEventListener("load",addMetadata),window.addEventListener("load",addMetadata);</script>
</head>
<body class="xml2rfc">
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">in-tree-hints</td>
<td class="right">March 2026</td>
</tr></thead>
<tfoot><tr>
<td class="left">Kolkman</td>
<td class="center">Expires 18 September 2026</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-workgroup">Workgroup:</dt>
<dd class="workgroup">dnsop</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-kolkman-in-tree-hints</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2026-03-17" class="published">17 March 2026</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2026-09-18">18 September 2026</time></dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
<div class="author-name">O. Kolkman</div>
</div>
</dd>
</dl>
</div>
<h1 id="title">In-Tree Hints for DNS Resiliency</h1>
<section id="section-abstract">
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">We present a methodology by which networks that rely very strongly on
specific domain names can become more resilience to failures in the parent domain.<a href="#section-abstract-1" class="pilcrow"></a></p>
<p id="section-abstract-2">The approach presented uses a hints-file-like mechanism in recursive
nameservers in addition to having the authoritative servers follow a
few operational practices.<a href="#section-abstract-2" class="pilcrow"></a></p>
<p id="section-abstract-3">The suggested method can be seen as a means for increasing digital
sovereignty. We describe the approach, the necessary operational
practices, and the dilemmas this approach introduces.<a href="#section-abstract-3" class="pilcrow"></a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
<h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
</h2>
<p id="section-boilerplate.1-1">
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow"></a></p>
<p id="section-boilerplate.1-2">
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow"></a></p>
<p id="section-boilerplate.1-3">
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 18 September 2026.<a href="#section-boilerplate.1-4" 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) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow"></a></p>
<p id="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow"></a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
<a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
</h2>
<nav class="toc"><ul class="compact 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="auto internal xref">1</a>.  <a href="#name-introduction" class="internal 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"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-the-in-tree-hints-concept" class="internal xref">The in-tree hints concept</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
<p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="auto internal xref">2.1</a>.  <a href="#name-recursive-nameserver" class="internal xref">Recursive nameserver</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
<p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="auto internal xref">2.2</a>.  <a href="#name-domain-owner" class="internal xref">Domain Owner</a></p>
</li>
</ul>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
<p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-operational-considerations" class="internal xref">Operational Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
<p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-signaling" class="internal xref">Signaling</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-achieving-true-resiliency-o" class="internal xref">Achieving true resiliency of services within the domain.</a></p>
</li>
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
<p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>.  <a href="#name-serving-stale-data" class="internal xref">Serving stale data</a></p>
</li>
</ul>
</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="auto internal xref">4</a>.  <a href="#name-conclusions" class="internal xref">Conclusions</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="auto internal xref">5</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</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="auto internal xref">6</a>.  <a href="#name-policy-considerations" class="internal xref">Policy Considerations</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="auto internal xref">7</a>.  <a href="#name-iana-considerations" class="internal xref">IANA 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="auto internal xref">8</a>.  <a href="#name-acknowledgments" class="internal xref">Acknowledgments</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="auto internal xref">9</a>.  <a href="#name-references" class="internal 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="auto internal xref">9.1</a>.  <a href="#name-normative-references" class="internal 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="auto internal xref">9.2</a>.  <a href="#name-informative-references" class="internal 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="auto internal xref"></a><a href="#name-authors-address" class="internal xref">Author's Address</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"></p>
<p id="section-1-2">The Domain Name System (DNS) is a remarkably stable and resilient
system. However, in many environments people are looking on how they
can remain in control over the continuity of digital services in their
own environments and reduce external dependencies. One those
dependencies is the DNS, on which we focus in this document.<a href="#section-1-2" class="pilcrow"></a></p>
<p id="section-1-3">Consider the following failure case:<a href="#section-1-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-1-4.1">
<p id="section-1-4.1.1">A community of interest is highly dependent on services that are
discoverable with names within the example.net domain;<a href="#section-1-4.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-4.2">
<p id="section-1-4.2.1">A failure in DNS resolution occurs in the delegation between .net
and example.net;<a href="#section-1-4.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-1-4.3">
<p id="section-1-4.3.1">IP connectivity remains intact: The DNS servers that serve
example.net authoritatively are still reachable by the community of
interest. So are the recursive nameservers and the service of
interest.<a href="#section-1-4.3.1" class="pilcrow"></a></p>
</li>
</ul>
<p id="section-1-5">This failure case may sound relatively limited. But here are a few
less abstract examples of such failure.<a href="#section-1-5" class="pilcrow"></a></p>
<p id="section-1-6">Consider an enterprise campus operating under the domain example.net
that provides essential services, such as logistics, to users on its
campus. If the transit connection to the broader Internet were to
fail, the consequences could be significant. Even when all
infrastructure (DNS recursive and authoritative, and the servers for
the services themselves, etc) is on premise a failure to resolve the
delegation between top level domain .net and example.net would
eventually lead to inability to contact services.<a href="#section-1-6" class="pilcrow"></a></p>
<p id="section-1-7">Another example is a small island nation state that has a number of
its government services running on the island under its own TLD. Now
considers a cable cut scenario where all upstream connectivity is
lost. After a while, when authority information starts to time out
from caches (for some implementations after 24 hours), connections to
services on the island will start to fail.<a href="#section-1-7" class="pilcrow"></a></p>
<p id="section-1-8">A less benign example is an intervention in the DNS root. Where
delegation data for a country's level top level domain(ccTLD) gets
altered or removed. Such intervention would eventually debilitate
users which rely on services within that ccTLDs domain, usually
government services and local media outlets within that country.<a href="#section-1-8" class="pilcrow"></a></p>
<p id="section-1-9">While unthinkable even a few years ago these sort of scenario are now
being considered in the context of international stability in
cyberspace.<a href="#section-1-9" class="pilcrow"></a></p>
<p id="section-1-10">In this document we document an operational approach that, with minor
support of recursive nameserver can offer one of the elements towards
greater autonomy and resilience of infrastructure dependent on a
specific domain. While certainly not the only approach to increase
resiliency (e.g. the small island nation state example would be
solved by having a local anycast instance of the root) we introduce
this to offer confidence building mechanism that does not
fundamentally change the DNS design. This approach is consistent with
the architecture, design, and operation of the DNS. By following
practices herein we avoid namespace fragmentation. We also avoid
fundamental protocol changes, in particular we avoid alternative
roots.<a href="#section-1-10" class="pilcrow"></a></p>
<p id="section-1-11">The approach called 'in-tree hints', offers protection against various
attack vectors that could compromise the delegation process. For
instance, on-path attackers may attempt to alter delegation records,
which could lead to denial of service, particularly in systems
utilizing Domain Name System Security Extensions
(DNSSEC). Additionally, threats such as DNS supply chain attacks or
inadvertent errors can result in unauthorized changes to the
delegation, including DS (Delegation Signer) records. More general, we
solve for the case that a DNS resolver receives parental data that is
inconsistent with the intent from the domain owner, i.e. receiving
data that is inconsistent with what is published on authoritative
servers. That includes not receiving data at all.<a href="#section-1-11" class="pilcrow"></a></p>
<p id="section-1-12">In-tree hints can be seen as a building block for resiliency of
critical infrastructure or digital autonomy. The approach is
complementary to serving stale data from the cache <span>[<a href="#RFC8767" class="cite xref">RFC8767</a>]</span>, more
on this in section <a href="#stale" class="auto internal xref">Section 3.3</a>.<a href="#section-1-12" class="pilcrow"></a></p>
<p id="section-1-13">In this memo we describe what the parties that are critically
dependent on a specific domain and those that serve zones within that
domain will need to do in order to guarantee continuous operation.<a href="#section-1-13" class="pilcrow"></a></p>
<p id="section-1-14">In section <a href="#concept" class="auto internal xref">Section 2</a> we describe the idea and the requirements for a
recursive DNS server and the requirements of the zone associated with.
In section <a href="#resilience" class="auto internal xref">Section 3.2</a> we shortly point to other measures that must
be taken in combination with this mechanism. In section <a href="#policy" class="auto internal xref">Section 6</a> we
discuss some policy considerations and the dilemmas that exist with
respect to intentions of the DNS parent and child.<a href="#section-1-14" class="pilcrow"></a></p>
<p id="section-1-15">This document uses uppercase SHOULD, RECOMMENDED and MUST in the
meaning defined by <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span>. Their lowercase equivalents do not
have normative meaning.<a href="#section-1-15" class="pilcrow"></a></p>
</section>
</div>
<div id="concept">
<section id="section-2">
<h2 id="name-the-in-tree-hints-concept">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-the-in-tree-hints-concept" class="section-name selfRef">The in-tree hints concept</a>
</h2>
<p id="section-2-1"><span>[<a href="#RFC9499" class="cite xref">RFC9499</a>]</span> describes the root hints file "Operators who manage a DNS
recursive resolver typically need to configure a 'root hints
file'. This file contains the names and IP addresses of the
authoritative name servers for the root zone, so the software can
bootstrap the DNS resolution process. For many pieces of software,
this list comes built into the software."<a href="#section-2-1" class="pilcrow"></a></p>
<p id="section-2-2">The in-tree hints borrows this from this idea: by configuring a 'hints
file' for a specific domain one allows oneself to bootstrap from that
domain down, even if its parents are not available. Implementing it
requires a modification in recursive nameservers and adherence to some
operational practices.<a href="#section-2-2" class="pilcrow"></a></p>
<div id="rec">
<section id="section-2.1">
<h3 id="name-recursive-nameserver">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-recursive-nameserver" class="section-name selfRef">Recursive nameserver</a>
</h3>
<p id="section-2.1-1">Recursive nameserver software will need to be modified to deal to work
with in-tree hints.<a href="#section-2.1-1" class="pilcrow"></a></p>
<p id="section-2.1-2">An in-tree hints is configuration for a recursive resolver that
provides the names and IP addresses of authoritative name servers for
a specific domain. A recursive name server may be configured for
in-tree hints for multiple domains.<a href="#section-2.1-2" class="pilcrow"></a></p>
<p id="section-2.1-3">When there are no in-domain (in bailiwick) nameservers (<span>[<a href="#RFC9499" class="cite xref">RFC9499</a>]</span>)
in the NS set for the domain then this mechanism MUST [OMK: SHOULD?] not be
used. Without this requirement the resiliency properties can
potentially not be achieved as there are dependencies outside of
control of the domain. This requirement can be enforced by the
recursive nameserver software at the moment of configuration
parsing. In addition the in bailiwick server should fate share IP
connectivity with its dependendants. For instance, in our island
example one in-domain name server should be on the isle. In our
enterprise example one in-domain server should be on campus.<a href="#section-2.1-3" class="pilcrow"></a></p>
<p id="section-2.1-4">In-tree hints are only useful if the domain owner follows certain
practices. A recursive nameserver MAY only implement the in-tree hints
mechanism for a specific domain if the domain owner indicates it does
so. Section <a href="#signal" class="auto internal xref">Section 3.1</a> describes the RECOMMENDED way for domain name
owners to signal their intent. [OMK: REVIEW 2019 Keywords]<a href="#section-2.1-4" class="pilcrow"></a></p>
<p id="section-2.1-5">In-tree hints MUST only be used in combination with a DNSSEC
trust-anchor. i.e. a trusted public DNSSEC key that is associated with
the name. The trust-anchor MUST be maintained. It SHOULD be maintained
by the mechanism described in <span>[<a href="#RFC5011" class="cite xref">RFC5011</a>]</span>. Alternatively an
appropriate and trustworthy off-band mechanism MAY be used. The
operator of a recursive nameserver must validate that the domain
associated with the in-tree hints follows the operational practices
described in this memo. This can be achieved by out-of band
mechanisms, or by querying the TXT record as described in {#auth}<a href="#section-2.1-5" class="pilcrow"></a></p>
<p id="section-2.1-6">When a recursive nameserver is configured with an in-tree hint then
the NS Resource Record set contained in the in-tree hint MUST be used
during the resolution process. Which means that they always overwrite
the NS and DS resource records received from the parent.<a href="#section-2.1-6" class="pilcrow"></a></p>
<p id="section-2.1-7">When the NS RRset on the domain's authoritative server changes and has
been validated using DNSSEC against configured key then the in-hints
tree configuration SHOULD be updated with the changed authoritative NS
set. This requirement guarantees that the intent of the domain holder
will be followed.<a href="#section-2.1-7" class="pilcrow"></a></p>
<p id="section-2.1-8">The recursive nameserver should honor the TTLs to regular check a
change of the authoritative NS RRset. Operators that implement in-tree
hints SHOULD use tooling, possibly implemented in the recursive
nameserver, to log and signal inconsistencies between information in
the parents and the in-tree configuration to the operators of the
recursive nameserver, these inconsistencies need to be well
understood. They could be the result of a bona-fide re-delegation (in
which case the parental records are likely a subset of the
authoritative NS RR set), the withdrawal of the delegation by the
parent, or an error or attack.<a href="#section-2.1-8" class="pilcrow"></a></p>
<p id="section-2.1-9">The trust anchor MUST be used for the validation of record within the
tree-hint's domain even when a parental DS record exists. Nota bene,
section 5 of <span>[<a href="#RFC5011" class="cite xref">RFC5011</a>]</span> allows for deletion if a superior trust point
exists - when a trust anchor is part of an in-tree hint that deletion
with the motivation that a superior trust point exists MUST not
happen. When a tree-hint exists for a subordinate domain, that trust
anchor MUST take precedence.<a href="#section-2.1-9" class="pilcrow"></a></p>
<p id="section-2.1-10">Recursive nameservers that implement this mechanism SHOULD have a
fallback mechanism implemented that will eventually allow them to
reach the in-domain nameserver when other servers in the NS resource
record set fail. [OMK: I think this is an existing requirement
somewhere else in the mountain of RFCs]<a href="#section-2.1-10" class="pilcrow"></a></p>
</section>
</div>
<div id="auth">
<section id="section-2.2">
<h3 id="name-domain-owner">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-domain-owner" class="section-name selfRef">Domain Owner</a>
</h3>
<p id="section-2.2-1">This section describes the operational practices that the domain owner
has to follow in order to achieve the resiliency within the domain.<a href="#section-2.2-1" class="pilcrow"></a></p>
<p id="section-2.2-2">The domain owner MUST maintain its DNSSEC configuration using the
mechanism described in <span>[<a href="#RFC5011" class="cite xref">RFC5011</a>]</span>.<a href="#section-2.2-2" class="pilcrow"></a></p>
<p id="section-2.2-3">The domain owner MUST have at least one in-domain authoritative
nameserver in its NS set. If that nameserver's name is within a
delegated child domain, then the nameservers for that delegated domain
MUST also have at least one in-domain authoritative nameserver. This
requirement is recursive for further delegation.<a href="#section-2.2-3" class="pilcrow"></a></p>
<p id="section-2.2-4">In order to benefit from the resiliency properties provided by this
mechanism, the domain owner should require that delegated domains
(zones) within the domain all have one nameserver that are
in-domain. Note that delegated domains do not have to maintain a trust
anchor and can rely on there being a chain of trust established using
DS records from the trust-anchor down. [OMK: is this actually clear?
Domain, sub-domain, in-domain, may become confusing]<a href="#section-2.2-4" class="pilcrow"></a></p>
<p id="section-2.2-5">Furthermore, the in-domain nameserver SHOULD be positioned in a
network that shares connectivity fate with the clients. For instance,
in our enterprise example it should be in the enterprise campus
network. More generally the location is subject to a risk based
assessment about the likelihood of not being able to obtain an IP
connection the in-domain nameserver.<a href="#section-2.2-5" class="pilcrow"></a></p>
<p id="section-2.2-6">[OMK: should there be language here about out-of-domain nameservers?]<a href="#section-2.2-6" class="pilcrow"></a></p>
<p id="section-2.2-7">The domain owner should communicate to its community that it is
deploying practices that support in-tree hints. That communication MAY
be out of band. A RECOMMENDED in-band signaling mechanism in-band
described in section <a href="#signal" class="auto internal xref">Section 3.1</a>.<a href="#section-2.2-7" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="operational">
<section id="section-3">
<h2 id="name-operational-considerations">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
</h2>
<p id="section-3-1">bla<a href="#section-3-1" class="pilcrow"></a></p>
<div id="signal">
<section id="section-3.1">
<h3 id="name-signaling">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-signaling" class="section-name selfRef">Signaling</a>
</h3>
<p id="section-3.1-1">It is RECOMMENDED that a domain owner (the owner of <code>&lt;domain&gt;</code>)
signals to its user community that they are using the mechanism
described in this section. Signaling is done by putting a TXT
resource record with owner name <code>_in-tree.&lt;domain&gt;</code> containing an
expiry timestamp in <span>[<a href="#RFC3339" class="cite xref">RFC3339</a>]</span> format. The expiry timestamp indicates
the date to which the owner is committed to follow the instructions in
section <a href="#auth" class="auto internal xref">Section 2.2</a>.<a href="#section-3.1-1" class="pilcrow"></a></p>
<p id="section-3.1-2">The recursive nameserver operator should at first opportunity, but not
longer than 30 days after the expiration, validate if a new expiry
record has been published by the domain owner. If not, they SHOULD
disable the in-tree hints configuration for the domain.<a href="#section-3.1-2" class="pilcrow"></a></p>
<p id="section-3.1-3"><code>
_in-tree.&lt;domain&gt; TXT &lt;expiry timestamp&gt;
</code><a href="#section-3.1-3" class="pilcrow"></a></p>
<p id="section-3.1-4">[OMK: Alternatively we create a trivial RR type for this. EXP RR
containing a timestamp as defined in RFC4034 section-3.1.5 ]<a href="#section-3.1-4" class="pilcrow"></a></p>
<p id="section-3.1-5">Out of band signaling is not in scope for this memo.<a href="#section-3.1-5" class="pilcrow"></a></p>
</section>
</div>
<div id="resilience">
<section id="section-3.2">
<h3 id="name-achieving-true-resiliency-o">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-achieving-true-resiliency-o" class="section-name selfRef">Achieving true resiliency of services within the domain.</a>
</h3>
<p id="section-3.2-1">This memo describes a method to achieve resiliency of name resolution
for a community of interest of a particular domain. This is, by far,
not sufficient to achieve actual resiliency for services that are
provided within the domain. While a detailed discussion is out of
scope for this memo we like to remind the reader of the following:<a href="#section-3.2-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.2-2.1">
<p id="section-3.2-2.1.1">The in-domain nameservers should run on IP addresses that can
reasonably be expected to be reachable by the community of use. For
example, if a service is critical for on-campus enterprise use then
the in-domain nameserver should run on the campus network.<a href="#section-3.2-2.1.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.2-2.2">
<p id="section-3.2-2.2.1">Any service provider that offers a service under a certain name
within the domain should make sure that those services itself can be
reasonably expected to be reachable by the community of use. Any
service dependencies should also be local.<a href="#section-3.2-2.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-3.2-2.3">
<p id="section-3.2-2.3.1">In an effort to create local resiliency one should not forget that
resiliency is also achieved by having no single source of
failure. Having in-domain nameservers, and having services in reach
of the community of interest does not mean that one deploys
infrastructure elsewhere.<a href="#section-3.2-2.3.1" class="pilcrow"></a></p>
</li>
</ul>
</section>
</div>
<div id="stale">
<section id="section-3.3">
<h3 id="name-serving-stale-data">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-serving-stale-data" class="section-name selfRef">Serving stale data</a>
</h3>
<p id="section-3.3-1">In-tree hints are complementary to serving stale data
<span>[<a href="#RFC8767" class="cite xref">RFC8767</a>]</span>. Serving stale data will allow continuity for all zones
when their authoritative servers are not reachable and the data
happens to be in the resolvers cache. In-tree hints works for specific
domains when data does not happen to be available in recursive
nameserver caches or when the parent's server(s) deliver faulty
delegation data.<a href="#section-3.3-1" class="pilcrow"></a></p>
<p id="section-3.3-2">In-tree hints is not scalable in the sense that there is significant
operational overhead for both the domain owner, they have to run
in-domain nameservers and follow <span>[<a href="#RFC5011" class="cite xref">RFC5011</a>]</span>, and the recursive
nameserver operator as they will have to troubleshoot
inconsistencies. Serving stale data is highly scalable as it only
needs one configuration within the recursive nameserver and then it
applies for all domains.<a href="#section-3.3-2" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="conclusions">
<section id="section-4">
<h2 id="name-conclusions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-conclusions" class="section-name selfRef">Conclusions</a>
</h2>
<p id="section-4-1">[TODO]<a href="#section-4-1" class="pilcrow"></a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-5">
<h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-5-1">In-tree hints can be used in recursive nameservers in combination with
protective block-lists and does therefore not debilitate the available
mechanism to protect the community of users of a recursive nameserver.<a href="#section-5-1" class="pilcrow"></a></p>
<p id="section-5-2">Malwares that use their own recursive nameservers configured with
in-trees for their command and control domains to circumvent
de-delegation by the parents. However, those recursive nameservers are
likely under the control of the malware administrators and the risk
of disproportional damage for blocking these recursive nameservers DNS
after it has been established that they are used in command and
control seems proportionate.<a href="#section-5-2" class="pilcrow"></a></p>
<p id="section-5-3">This mechanism intends to provide resilience for network
failures. However, it adds complexity in software and operational
procedures, thereby increasing the fragility.<a href="#section-5-3" class="pilcrow"></a></p>
<p id="section-5-4">When DNS validation takes place by clients that are 'behind' a
recursive nameserver that is configured with in-tree hints for a
particular domain then behavior in case of inconsistencies between the
domain and its parent will lead to undefined behavior. These
validating clients SHOULD also implement in-tree hints.<a href="#section-5-4" class="pilcrow"></a></p>
</section>
</div>
<div id="policy">
<section id="section-6">
<h2 id="name-policy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-policy-considerations" class="section-name selfRef">Policy Considerations</a>
</h2>
<p id="section-6-1">Inherently the approach described in this memo provides a mechanism
for a community of users of a domain to overwrite the policies from
the parent domain. For instance, it allows the community of users to
continue to use the domain even when e.g. the delegation for that
domain expires. As such, this mechanism allows a community to
continue to use a domain when the parent has de-delegated the domain
for instance in the context of a court order. At the same time this
in-tree approach can be a building block to create resilience for a
critical infrastructure. It can potentially be applied to a country
code top-level domain (CCTLD) and its user community. While the
failure mode at CCTLD level is extremely low, this approach may add to
confidence in the domain name system as a whole in times of
international tensions.<a href="#section-6-1" class="pilcrow"></a></p>
<p id="section-6-2">When an inconsistency exists between what is published in the parent
and what is used as in-tree-hints there is a fragmentation of the DNS
namespace. The operators of the recursive nameservers should
pro-actively restore the situation to consistency. Note that there is
no technical enforcement mechanism to aid that restoration but it is
expected that if a recursive nameserver operator configures an in-tree
domain he is part of the community of interest and therefore has out
of band means to contact the domain administrator. Also note that the
operators of the domain (e.g. example.net) do not have communication
mechanism that can enforce the use or non-use of in-tree hints by
recursive nameserver operators.<a href="#section-6-2" class="pilcrow"></a></p>
<p id="section-6-3">The authority for using or not using in-tree hints is with the
operator of the recursive nameserver - as a user agent for its
community. Users have in general been able to overwrite their DNS
configuration since the first deployment of the DNS system. Users can
use a recursive nameserver that does not use in-tree hints for a
particular domain and therefore can opt-out of the mechanism.<a href="#section-6-3" class="pilcrow"></a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-7">
<h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-7-1">No IANA considerations herein.<a href="#section-7-1" class="pilcrow"></a></p>
</section>
</div>
<div id="acknowledgments">
<section id="section-8">
<h2 id="name-acknowledgments">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
</h2>
<p id="section-8-1">This document is inspired by various hallway conversations about digital autonomy.<a href="#section-8-1" class="pilcrow"></a></p>
<p id="section-8-2">The author is an employee of the Internet Society, this document does
not necessarily reflect the position of the Internet Society.<a href="#section-8-2" class="pilcrow"></a></p>
<p id="section-8-3">{olaf: source="olaf"}<a href="#section-8-3" class="pilcrow"></a></p>
</section>
</div>
<div id="sec-combined-references">
<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>
<div id="sec-normative-references">
<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="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3339">[RFC3339]</dt>
<dd>
<span class="refAuthor">Klyne, G.</span> and <span class="refAuthor">C. Newman</span>, <span class="refTitle">"Date and Time on the Internet: Timestamps"</span>, <span class="seriesInfo">RFC 3339</span>, <span class="seriesInfo">DOI 10.17487/RFC3339</span>, <time datetime="2002-07" class="refDate">July 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc3339">https://www.rfc-editor.org/rfc/rfc3339</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5011">[RFC5011]</dt>
<dd>
<span class="refAuthor">StJohns, M.</span>, <span class="refTitle">"Automated Updates of DNS Security (DNSSEC) Trust Anchors"</span>, <span class="seriesInfo">STD 74</span>, <span class="seriesInfo">RFC 5011</span>, <span class="seriesInfo">DOI 10.17487/RFC5011</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc5011">https://www.rfc-editor.org/rfc/rfc5011</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7344">[RFC7344]</dt>
<dd>
<span class="refAuthor">Kumari, W.</span>, <span class="refAuthor">Gudmundsson, O.</span>, and <span class="refAuthor">G. Barwood</span>, <span class="refTitle">"Automating DNSSEC Delegation Trust Maintenance"</span>, <span class="seriesInfo">RFC 7344</span>, <span class="seriesInfo">DOI 10.17487/RFC7344</span>, <time datetime="2014-09" class="refDate">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7344">https://www.rfc-editor.org/rfc/rfc7344</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</div>
<div id="sec-informative-references">
<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="E-Gov-Resilience">[E-Gov-Resilience]</dt>
<dd>
<span class="refAuthor">Sommese et al</span>, <span class="refTitle">"Assessing e-Government DNS Resilience"</span>, <span class="seriesInfo">IEEE Proceedings of the 2022 International Conference on Network and Service Management (CNSM 2022)</span>, <time datetime="2022" class="refDate">2022</time>. </dd>
<dd class="break"></dd>
<dt id="RFC8767">[RFC8767]</dt>
<dd>
<span class="refAuthor">Lawrence, D.</span>, <span class="refAuthor">Kumari, W.</span>, and <span class="refAuthor">P. Sood</span>, <span class="refTitle">"Serving Stale Data to Improve DNS Resiliency"</span>, <span class="seriesInfo">RFC 8767</span>, <span class="seriesInfo">DOI 10.17487/RFC8767</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8767">https://www.rfc-editor.org/rfc/rfc8767</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9499">[RFC9499]</dt>
<dd>
<span class="refAuthor">Hoffman, P.</span> and <span class="refAuthor">K. Fujiwara</span>, <span class="refTitle">"DNS Terminology"</span>, <span class="seriesInfo">BCP 219</span>, <span class="seriesInfo">RFC 9499</span>, <span class="seriesInfo">DOI 10.17487/RFC9499</span>, <time datetime="2024-03" class="refDate">March 2024</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9499">https://www.rfc-editor.org/rfc/rfc9499</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-A">
<h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
</h2>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Olaf Kolkman</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kolkman@isoc.org" class="email">kolkman@isoc.org</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>
Reference in New Issue View Git Blame Copy Permalink