00 version 20260317
This commit is contained in:
olaf
7
Makefile
7
Makefile
@@ -1,6 +1,7 @@
|
|||||||
|
|
||||||
DRAFTS = in-tree-hints
|
DRAFT = kolkman-dns-in-tree-hints
|
||||||
OUTPUTS = $(foreach draft,$(DRAFTS),draft-${draft}.html draft-${draft}.xml draft-${draft}.txt)
|
SUFFIX = 00-20260317
|
||||||
|
OUTPUTS = $(foreach draft,$(DRAFT)-$(SUFFIX),draft-${draft}.html draft-${draft}.xml draft-${draft}.txt)
|
||||||
STAGING = staging.xml
|
STAGING = staging.xml
|
||||||
|
|
||||||
all: $(OUTPUTS)
|
all: $(OUTPUTS)
|
||||||
@@ -11,7 +12,7 @@ clean:
|
|||||||
draft-%.html: draft-%.xml
|
draft-%.html: draft-%.xml
|
||||||
xml2rfc $< --html
|
xml2rfc $< --html
|
||||||
|
|
||||||
draft-%.xml: draft-%.md
|
draft-%.xml: draft-$(DRAFT).md
|
||||||
kramdown-rfc2629 $< > $*.$(STAGING)
|
kramdown-rfc2629 $< > $*.$(STAGING)
|
||||||
mv $*.$(STAGING) $@
|
mv $*.$(STAGING) $@
|
||||||
|
|
||||||
|
|||||||
@@ -1,197 +0,0 @@
|
|||||||
---
|
|
||||||
title: In-tree Hints for DNS Resilliency
|
|
||||||
abbrev: in-tree-hints
|
|
||||||
docname: draft-kolkman-in-tree-hints
|
|
||||||
category: info
|
|
||||||
|
|
||||||
ipr: trust200902
|
|
||||||
area: ops
|
|
||||||
workgroup: dnsop
|
|
||||||
keyword: Internet-Draft
|
|
||||||
stand_alone: yes
|
|
||||||
pi:
|
|
||||||
RFCedstyle: yes
|
|
||||||
toc: yes
|
|
||||||
tocindent: yes
|
|
||||||
sortrefs: yes
|
|
||||||
symrefs: yes
|
|
||||||
strict: yes
|
|
||||||
comments: yes
|
|
||||||
inline: yes
|
|
||||||
text-list-symbols: -o*+
|
|
||||||
|
|
||||||
author:
|
|
||||||
ins: O. Kolkman
|
|
||||||
name: Olaf Kolkman
|
|
||||||
email: kolkman@isoc.org
|
|
||||||
|
|
||||||
normative:
|
|
||||||
RFC2119:
|
|
||||||
RFC3339:
|
|
||||||
RFC5011:
|
|
||||||
RFC7344:
|
|
||||||
|
|
||||||
|
|
||||||
informative:
|
|
||||||
RFC9499:
|
|
||||||
RFC8767:
|
|
||||||
E-Gov-Resilience:
|
|
||||||
title: "Assessing e-Government DNS Resilience"
|
|
||||||
date: 2022
|
|
||||||
author:
|
|
||||||
- ins: Sommese et al.
|
|
||||||
seriesinfo:
|
|
||||||
"IEEE": Proceedings of the 2022 International Conference on Network and Service Management (CNSM 2022)
|
|
||||||
|
|
||||||
|
|
||||||
--- abstract
|
|
||||||
|
|
||||||
Lorem ipsum dolor sit amet, has no senserit reformidans liberavisse. Laudem signiferumque pri in, et vix facer maluisset interesset. Sit consul minimum recusabo at, causae scriptorem cu qui. Cetero democritum consetetur eos ea. Brute delenit invenire eu vix, pri illum iusto definitionem et, altera quaeque quo ut. Quem offendit eu vel. Ea sumo utroque tacimates has.
|
|
||||||
|
|
||||||
|
|
||||||
--- middle
|
|
||||||
|
|
||||||
Introduction
|
|
||||||
============
|
|
||||||
|
|
||||||
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 their own environments and reduce external dependencies.
|
|
||||||
|
|
||||||
In this document we design 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.
|
|
||||||
|
|
||||||
An imaginary case in which this approach is useful where an enterprise with domain example.net has a critical function (e.g. financial service) to customers that are on networks that connect a set of campus networks that are interconnected but share one transit connection. If the transit connection breaks, and thereby the connection to the rest of the Internet breaks, the DNS resolution on the campus networks will fail when the domain data is not in cache and the delegation from .net to example.net is not available. At that moment customers will fail to do business with the enterprise, even when the enterprise services the customers from one of the campus networks. Another failure case that this mechanism protects against are attacks that target the delegation. Either MITM attacks that change delegation records (leading to denial of service in case of the use of DNSSEC) or DNS supply chain attacks or errors by which the delegation, including DS records, are changed.
|
|
||||||
|
|
||||||
The approach is designed for proving resiliency for the Internet's naming function and does not bring full resiliency by itself. But we see this as a building block for resiliency of critical infrastructure or digital autonomy. The approach is complementary to serving stale data from the cache {{RFC8767}}, more on this in section {{stale}}.
|
|
||||||
|
|
||||||
Our approach is designed to be consistent with the architecture, design, and operation of the DNS. We avoid namespace fragmentation or fundamental protocol changes, in particular we avoid the need for alternative roots.
|
|
||||||
|
|
||||||
The approach describes 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 in the case that there is breakage such as their nameservers not being reachable or a broken delegation from the ancestor domain. In More general, breakage means that DNS resolver receives 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 include not receiving data at all.
|
|
||||||
|
|
||||||
In section {{concept}} we describe the idea and the requirements for a recursive DNS server and the requirements of the zone associated with. In section {{resilience}} we shortly point to other measures that must be taken in combination with this mechanism. In section {{policy}} we discuss some policy considerations.
|
|
||||||
|
|
||||||
This document uses uppercase SHOULD, RECOMMENDED and MUST in the meaning defined by {{RFC2119}}. Their lowercase equivalents do not have normative meaning.
|
|
||||||
|
|
||||||
The in-tree hints concept {#concept}
|
|
||||||
==========================
|
|
||||||
|
|
||||||
{{RFC9499}} 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."
|
|
||||||
|
|
||||||
The in-tree hints borrows this from this idea. It requires a modification in recursive nameservers and adherence to some operational practices.
|
|
||||||
|
|
||||||
|
|
||||||
Recursive nameserver {#rec}
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
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. One recursive name server may be configured for in-tree hints for multiple domains.
|
|
||||||
|
|
||||||
If there are no in-domain nameservers ({{RFC9499}}) in the NS set for the domain then this mechanism MUST not be used. The reason for this requirement is that when there is no in-domain nameserver the resiliency properties cannot be achieved as there are external name dependencies.
|
|
||||||
|
|
||||||
In-tree hints are only useful if the domain owner follows certain practices and MAY only be followed if the domain owner indicates it does so. Section {{signal}} describes the RECOMMENDED way for signaling the intent.
|
|
||||||
|
|
||||||
In-tree hints MUST only be used in combination with a 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 {{RFC5011}}. 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}
|
|
||||||
|
|
||||||
When a recursive nameserver is configured with an in-tree hint then the NS Resource Record set contained in the in-tree hint configuration should be refreshed and used in the cache.
|
|
||||||
|
|
||||||
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 {{RFC5011}} 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.
|
|
||||||
|
|
||||||
Once the NS set is its data MUST be used forthwith as an indication for the location of the authoritative NS records. Recursive nameservers should own cache these records and respect the resource record's TTL and actively refresh them from the authoritative servers. In addition, the data will occasionally need to be refreshed in the configuration. This can be achieved with external automation. 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, in particular for changes for the in-domain nameservers.
|
|
||||||
|
|
||||||
It is assumed that all modern nameservers 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.
|
|
||||||
|
|
||||||
Domain Owner {#auth}
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
This section describes the operational practices that the domain owner has to follow in order to achieve the resiliency within the domain.
|
|
||||||
|
|
||||||
The domain owner MUST maintain its DNSSEC configuration using the mechanism described in {{RFC5011}}.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
In order to benefit from the resiliency properties provided by this mechanism, the domain owner should require that zones within the domain all have one in-domain nameserver. 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.
|
|
||||||
|
|
||||||
TODO OMK: should there be language here about out-of-domain nameservers?
|
|
||||||
|
|
||||||
|
|
||||||
The domain owner should communicate to its community that it is using this method. That communication MAY be out of band. A RECOMMENDED in-band signalling mechanism in-band described in section {{signal}}.
|
|
||||||
|
|
||||||
|
|
||||||
Operational Considerations {#operational}
|
|
||||||
======================
|
|
||||||
|
|
||||||
bla
|
|
||||||
|
|
||||||
Signalling {#signal}
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
It is RECOMMENDED that a domain owner (the owner of `<domain>`) signals to its user community that they are using the mechanism described in this section. Signalling is done by putting a TXT resource record with owner name `_in-tree.<domain>` containing an expiry timestamp in {{RFC3339}} format. The expiry timestamp indicates the date to which the owner is committed to follow the instructions in section {{auth}}.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
```
|
|
||||||
_in-tree.<domain> TXT <expiry timestamp>
|
|
||||||
```
|
|
||||||
[OMK: Alternatively we create a trivial RR type for this. EXP RR containing a timestamp as defined in RFC4034 section-3.1.5 ]
|
|
||||||
|
|
||||||
Out of band signalling is not in scope for this memo.
|
|
||||||
|
|
||||||
|
|
||||||
Achieving true resiliency of services within the domain. {#resilience}
|
|
||||||
--------------
|
|
||||||
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 further out of scope for this memo we like to remind the reader of the following:
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
* 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.
|
|
||||||
|
|
||||||
Serving stale data {#stale}
|
|
||||||
----------------
|
|
||||||
|
|
||||||
In-tree hints are complementary to serving stale data {{RFC8767}}. 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.
|
|
||||||
|
|
||||||
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 {{RFC5011}}, 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.
|
|
||||||
|
|
||||||
Conclusions
|
|
||||||
=============
|
|
||||||
|
|
||||||
[TODO]
|
|
||||||
|
|
||||||
|
|
||||||
Security Considerations
|
|
||||||
=======================
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Mallwares 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 mallware 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.
|
|
||||||
|
|
||||||
|
|
||||||
Policy Considerations {#policy}
|
|
||||||
=====================
|
|
||||||
|
|
||||||
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 in the context of a court order. At the same time this in-tree approach, when applied to a country code top-level domain (CCTLD) and its user community, can be a building block to create resilience for a countries critical infrastructure. While the failure mode at CCTLD level is extremely low, this approach may add to confidence in the domain name system as a whole.
|
|
||||||
|
|
||||||
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 proactively 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.
|
|
||||||
|
|
||||||
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 can in general overwrite their DNS configuration to use a recursive nameserver that does not use in-tree hints for a particular domain and therefore can opt-out.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
IANA Considerations
|
|
||||||
===================
|
|
||||||
|
|
||||||
The authore
|
|
||||||
|
|
||||||
Acknowledgements
|
|
||||||
=================
|
|
||||||
|
|
||||||
This document is inspired by a conversation with [that guy from Internet.nl] in a discussion during about digital autonomy.
|
|
||||||
|
|
||||||
The author is an employee of the Internet Society, this document does not necessarily reflect the position of the Internet Society.
|
|
||||||
|
|
||||||
|
|
||||||
{olaf: source="olaf"}
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
1843
draft-kolkman-dns-in-tree-hints-00-20260317.html
Normal file
1843
draft-kolkman-dns-in-tree-hints-00-20260317.html
Normal file
File diff suppressed because it is too large
Load Diff
616
draft-kolkman-dns-in-tree-hints-00-20260317.txt
Normal file
616
draft-kolkman-dns-in-tree-hints-00-20260317.txt
Normal file
@@ -0,0 +1,616 @@
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
dnsop O. Kolkman
|
||||||
|
Internet-Draft 17 March 2026
|
||||||
|
Intended status: Informational
|
||||||
|
Expires: 18 September 2026
|
||||||
|
|
||||||
|
|
||||||
|
In-Tree Hints for DNS Resiliency
|
||||||
|
draft-kolkman-in-tree-hints
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Status of This Memo
|
||||||
|
|
||||||
|
This Internet-Draft is submitted in full conformance with the
|
||||||
|
provisions of BCP 78 and BCP 79.
|
||||||
|
|
||||||
|
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 https://datatracker.ietf.org/drafts/current/.
|
||||||
|
|
||||||
|
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."
|
||||||
|
|
||||||
|
This Internet-Draft will expire on 18 September 2026.
|
||||||
|
|
||||||
|
Copyright Notice
|
||||||
|
|
||||||
|
Copyright (c) 2026 IETF Trust and the persons identified as the
|
||||||
|
document authors. All rights reserved.
|
||||||
|
|
||||||
|
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||||
|
Provisions Relating to IETF Documents (https://trustee.ietf.org/
|
||||||
|
license-info) in effect on the date of publication of this document.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 1]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Table of Contents
|
||||||
|
|
||||||
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||||
|
2. The in-tree hints concept . . . . . . . . . . . . . . . . . . 4
|
||||||
|
2.1. Recursive nameserver . . . . . . . . . . . . . . . . . . 4
|
||||||
|
2.2. Domain Owner . . . . . . . . . . . . . . . . . . . . . . 6
|
||||||
|
3. Operational Considerations . . . . . . . . . . . . . . . . . 7
|
||||||
|
3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||||
|
3.2. Achieving true resiliency of services within the
|
||||||
|
domain. . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||||
|
3.3. Serving stale data . . . . . . . . . . . . . . . . . . . 8
|
||||||
|
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||||
|
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
|
||||||
|
6. Policy Considerations . . . . . . . . . . . . . . . . . . . . 9
|
||||||
|
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
|
||||||
|
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||||
|
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||||
|
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
|
||||||
|
9.2. Informative References . . . . . . . . . . . . . . . . . 10
|
||||||
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||||
|
|
||||||
|
1. Introduction
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Consider the following failure case:
|
||||||
|
|
||||||
|
* A community of interest is highly dependent on services that are
|
||||||
|
discoverable with names within the example.net domain;
|
||||||
|
|
||||||
|
* A failure in DNS resolution occurs in the delegation between .net
|
||||||
|
and example.net;
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 2]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
This failure case may sound relatively limited. But here are a few
|
||||||
|
less abstract examples of such failure.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 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.
|
||||||
|
|
||||||
|
While unthinkable even a few years ago these sort of scenario are now
|
||||||
|
being considered in the context of international stability in
|
||||||
|
cyberspace.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 3]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 [RFC8767], more on
|
||||||
|
this in section Section 3.3.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In section Section 2 we describe the idea and the requirements for a
|
||||||
|
recursive DNS server and the requirements of the zone associated
|
||||||
|
with. In section Section 3.2 we shortly point to other measures that
|
||||||
|
must be taken in combination with this mechanism. In section
|
||||||
|
Section 6 we discuss some policy considerations and the dilemmas that
|
||||||
|
exist with respect to intentions of the DNS parent and child.
|
||||||
|
|
||||||
|
This document uses uppercase SHOULD, RECOMMENDED and MUST in the
|
||||||
|
meaning defined by [RFC2119]. Their lowercase equivalents do not
|
||||||
|
have normative meaning.
|
||||||
|
|
||||||
|
2. The in-tree hints concept
|
||||||
|
|
||||||
|
[RFC9499] 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."
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
2.1. Recursive nameserver
|
||||||
|
|
||||||
|
Recursive nameserver software will need to be modified to deal to
|
||||||
|
work with in-tree hints.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 4]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
When there are no in-domain (in bailiwick) nameservers ([RFC9499]) 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.
|
||||||
|
|
||||||
|
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 Section 3.1 describes the RECOMMENDED way for
|
||||||
|
domain name owners to signal their intent. [OMK: REVIEW 2019
|
||||||
|
Keywords]
|
||||||
|
|
||||||
|
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 [RFC5011]. 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}
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 5]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 [RFC5011] 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.
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
|
2.2. Domain Owner
|
||||||
|
|
||||||
|
This section describes the operational practices that the domain
|
||||||
|
owner has to follow in order to achieve the resiliency within the
|
||||||
|
domain.
|
||||||
|
|
||||||
|
The domain owner MUST maintain its DNSSEC configuration using the
|
||||||
|
mechanism described in [RFC5011].
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 6]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
[OMK: should there be language here about out-of-domain nameservers?]
|
||||||
|
|
||||||
|
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 Section 3.1.
|
||||||
|
|
||||||
|
3. Operational Considerations
|
||||||
|
|
||||||
|
bla
|
||||||
|
|
||||||
|
3.1. Signaling
|
||||||
|
|
||||||
|
It is RECOMMENDED that a domain owner (the owner of <domain>) 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 _in-tree.<domain> containing an expiry timestamp in
|
||||||
|
[RFC3339] format. The expiry timestamp indicates the date to which
|
||||||
|
the owner is committed to follow the instructions in section
|
||||||
|
Section 2.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.
|
||||||
|
|
||||||
|
_in-tree.<domain> TXT <expiry timestamp>
|
||||||
|
|
||||||
|
[OMK: Alternatively we create a trivial RR type for this. EXP RR
|
||||||
|
containing a timestamp as defined in RFC4034 section-3.1.5 ]
|
||||||
|
|
||||||
|
Out of band signaling is not in scope for this memo.
|
||||||
|
|
||||||
|
3.2. Achieving true resiliency of services within the domain.
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 7]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
3.3. Serving stale data
|
||||||
|
|
||||||
|
In-tree hints are complementary to serving stale data [RFC8767].
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 [RFC5011], 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.
|
||||||
|
|
||||||
|
4. Conclusions
|
||||||
|
|
||||||
|
[TODO]
|
||||||
|
|
||||||
|
5. Security Considerations
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 8]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
This mechanism intends to provide resilience for network failures.
|
||||||
|
However, it adds complexity in software and operational procedures,
|
||||||
|
thereby increasing the fragility.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
6. Policy Considerations
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 9]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
7. IANA Considerations
|
||||||
|
|
||||||
|
No IANA considerations herein.
|
||||||
|
|
||||||
|
8. Acknowledgments
|
||||||
|
|
||||||
|
This document is inspired by various hallway conversations about
|
||||||
|
digital autonomy.
|
||||||
|
|
||||||
|
The author is an employee of the Internet Society, this document does
|
||||||
|
not necessarily reflect the position of the Internet Society.
|
||||||
|
|
||||||
|
{olaf: source="olaf"}
|
||||||
|
|
||||||
|
9. References
|
||||||
|
|
||||||
|
9.1. Normative References
|
||||||
|
|
||||||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||||
|
Requirement Levels", BCP 14, RFC 2119,
|
||||||
|
DOI 10.17487/RFC2119, March 1997,
|
||||||
|
<https://www.rfc-editor.org/rfc/rfc2119>.
|
||||||
|
|
||||||
|
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
|
||||||
|
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
|
||||||
|
<https://www.rfc-editor.org/rfc/rfc3339>.
|
||||||
|
|
||||||
|
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
|
||||||
|
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
|
||||||
|
September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.
|
||||||
|
|
||||||
|
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
|
||||||
|
DNSSEC Delegation Trust Maintenance", RFC 7344,
|
||||||
|
DOI 10.17487/RFC7344, September 2014,
|
||||||
|
<https://www.rfc-editor.org/rfc/rfc7344>.
|
||||||
|
|
||||||
|
9.2. Informative References
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 10]
|
||||||
|
|
||||||
|
Internet-Draft in-tree-hints March 2026
|
||||||
|
|
||||||
|
|
||||||
|
[E-Gov-Resilience]
|
||||||
|
Sommese et al, "Assessing e-Government DNS Resilience",
|
||||||
|
IEEE Proceedings of the 2022 International Conference on
|
||||||
|
Network and Service Management (CNSM 2022), 2022.
|
||||||
|
|
||||||
|
[RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
|
||||||
|
to Improve DNS Resiliency", RFC 8767,
|
||||||
|
DOI 10.17487/RFC8767, March 2020,
|
||||||
|
<https://www.rfc-editor.org/rfc/rfc8767>.
|
||||||
|
|
||||||
|
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
|
||||||
|
RFC 9499, DOI 10.17487/RFC9499, March 2024,
|
||||||
|
<https://www.rfc-editor.org/rfc/rfc9499>.
|
||||||
|
|
||||||
|
Author's Address
|
||||||
|
|
||||||
|
Olaf Kolkman
|
||||||
|
Email: kolkman@isoc.org
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Kolkman Expires 18 September 2026 [Page 11]
|
||||||
736
draft-kolkman-dns-in-tree-hints-00-20260317.xml
Normal file
736
draft-kolkman-dns-in-tree-hints-00-20260317.xml
Normal file
@@ -0,0 +1,736 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
|
||||||
|
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.8) -->
|
||||||
|
|
||||||
|
|
||||||
|
<!DOCTYPE rfc [
|
||||||
|
<!ENTITY nbsp " ">
|
||||||
|
<!ENTITY zwsp "​">
|
||||||
|
<!ENTITY nbhy "‑">
|
||||||
|
<!ENTITY wj "⁠">
|
||||||
|
|
||||||
|
]>
|
||||||
|
|
||||||
|
<?rfc RFCedstyle="yes"?>
|
||||||
|
<?rfc tocindent="yes"?>
|
||||||
|
<?rfc strict="yes"?>
|
||||||
|
<?rfc comments="yes"?>
|
||||||
|
<?rfc inline="yes"?>
|
||||||
|
<?rfc text-list-symbols="-o*+"?>
|
||||||
|
|
||||||
|
<rfc ipr="trust200902" docName="draft-kolkman-in-tree-hints" category="info" tocInclude="true" sortRefs="true" symRefs="true">
|
||||||
|
<front>
|
||||||
|
<title abbrev="in-tree-hints">In-Tree Hints for DNS Resiliency</title>
|
||||||
|
|
||||||
|
<author initials="O." surname="Kolkman" fullname="Olaf Kolkman">
|
||||||
|
<organization></organization>
|
||||||
|
<address>
|
||||||
|
<email>kolkman@isoc.org</email>
|
||||||
|
</address>
|
||||||
|
</author>
|
||||||
|
|
||||||
|
<date year="2026" month="March" day="17"/>
|
||||||
|
|
||||||
|
<area>ops</area>
|
||||||
|
<workgroup>dnsop</workgroup>
|
||||||
|
<keyword>Internet-Draft</keyword>
|
||||||
|
|
||||||
|
<abstract>
|
||||||
|
|
||||||
|
|
||||||
|
<?line 47?>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>The approach presented uses a hints-file-like mechanism in recursive
|
||||||
|
nameservers in addition to having the authoritative servers follow a
|
||||||
|
few operational practices.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</abstract>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</front>
|
||||||
|
|
||||||
|
<middle>
|
||||||
|
|
||||||
|
|
||||||
|
<?line 60?>
|
||||||
|
|
||||||
|
<section anchor="introduction"><name>Introduction</name>
|
||||||
|
<t><vspace blankLines='999' /></t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>Consider the following failure case:</t>
|
||||||
|
|
||||||
|
<t><list style="symbols">
|
||||||
|
<t>A community of interest is highly dependent on services that are
|
||||||
|
discoverable with names within the example.net domain;</t>
|
||||||
|
<t>A failure in DNS resolution occurs in the delegation between .net
|
||||||
|
and example.net;</t>
|
||||||
|
<t>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.</t>
|
||||||
|
</list></t>
|
||||||
|
|
||||||
|
<t>This failure case may sound relatively limited. But here are a few
|
||||||
|
less abstract examples of such failure.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>While unthinkable even a few years ago these sort of scenario are now
|
||||||
|
being considered in the context of international stability in
|
||||||
|
cyberspace.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="RFC8767"/>, more
|
||||||
|
on this in section <xref target="stale"/>.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>In section <xref target="concept"/> we describe the idea and the requirements for a
|
||||||
|
recursive DNS server and the requirements of the zone associated with.
|
||||||
|
In section <xref target="resilience"/> we shortly point to other measures that must
|
||||||
|
be taken in combination with this mechanism. In section <xref target="policy"/> we
|
||||||
|
discuss some policy considerations and the dilemmas that exist with
|
||||||
|
respect to intentions of the DNS parent and child.</t>
|
||||||
|
|
||||||
|
<t>This document uses uppercase SHOULD, RECOMMENDED and MUST in the
|
||||||
|
meaning defined by <xref target="RFC2119"/>. Their lowercase equivalents do not
|
||||||
|
have normative meaning.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="concept"><name>The in-tree hints concept</name>
|
||||||
|
|
||||||
|
<t><xref target="RFC9499"/> 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."</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<section anchor="rec"><name>Recursive nameserver</name>
|
||||||
|
|
||||||
|
<t>Recursive nameserver software will need to be modified to deal to work
|
||||||
|
with in-tree hints.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>When there are no in-domain (in bailiwick) nameservers (<xref target="RFC9499"/>)
|
||||||
|
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.</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="signal"/> describes the RECOMMENDED way for domain name
|
||||||
|
owners to signal their intent. [OMK: REVIEW 2019 Keywords]</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="RFC5011"/>. 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}</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="RFC5011"/> 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.</t>
|
||||||
|
|
||||||
|
<t>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]</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="auth"><name>Domain Owner</name>
|
||||||
|
|
||||||
|
<t>This section describes the operational practices that the domain owner
|
||||||
|
has to follow in order to achieve the resiliency within the domain.</t>
|
||||||
|
|
||||||
|
<t>The domain owner MUST maintain its DNSSEC configuration using the
|
||||||
|
mechanism described in <xref target="RFC5011"/>.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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]</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>[OMK: should there be language here about out-of-domain nameservers?]</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="signal"/>.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section anchor="operational"><name>Operational Considerations</name>
|
||||||
|
|
||||||
|
<t>bla</t>
|
||||||
|
|
||||||
|
<section anchor="signal"><name>Signaling</name>
|
||||||
|
|
||||||
|
<t>It is RECOMMENDED that a domain owner (the owner of <spanx style="verb"><domain></spanx>)
|
||||||
|
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 <spanx style="verb">_in-tree.<domain></spanx> containing an
|
||||||
|
expiry timestamp in <xref target="RFC3339"/> format. The expiry timestamp indicates
|
||||||
|
the date to which the owner is committed to follow the instructions in
|
||||||
|
section <xref target="auth"/>.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t><spanx style="verb">
|
||||||
|
_in-tree.<domain> TXT <expiry timestamp>
|
||||||
|
</spanx></t>
|
||||||
|
|
||||||
|
<t>[OMK: Alternatively we create a trivial RR type for this. EXP RR
|
||||||
|
containing a timestamp as defined in RFC4034 section-3.1.5 ]</t>
|
||||||
|
|
||||||
|
<t>Out of band signaling is not in scope for this memo.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="resilience"><name>Achieving true resiliency of services within the domain.</name>
|
||||||
|
|
||||||
|
<t>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:</t>
|
||||||
|
|
||||||
|
<t><list style="symbols">
|
||||||
|
<t>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.</t>
|
||||||
|
<t>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.</t>
|
||||||
|
<t>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.</t>
|
||||||
|
</list></t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="stale"><name>Serving stale data</name>
|
||||||
|
|
||||||
|
<t>In-tree hints are complementary to serving stale data
|
||||||
|
<xref target="RFC8767"/>. 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.</t>
|
||||||
|
|
||||||
|
<t>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 <xref target="RFC5011"/>, 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.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
<section anchor="conclusions"><name>Conclusions</name>
|
||||||
|
|
||||||
|
<t>[TODO]</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="security-considerations"><name>Security Considerations</name>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>This mechanism intends to provide resilience for network
|
||||||
|
failures. However, it adds complexity in software and operational
|
||||||
|
procedures, thereby increasing the fragility.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="policy"><name>Policy Considerations</name>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
<t>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.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="iana-considerations"><name>IANA Considerations</name>
|
||||||
|
|
||||||
|
<t>No IANA considerations herein.</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
<section anchor="acknowledgments"><name>Acknowledgments</name>
|
||||||
|
|
||||||
|
<t>This document is inspired by various hallway conversations about digital autonomy.</t>
|
||||||
|
|
||||||
|
<t>The author is an employee of the Internet Society, this document does
|
||||||
|
not necessarily reflect the position of the Internet Society.</t>
|
||||||
|
|
||||||
|
<t>{olaf: source="olaf"}</t>
|
||||||
|
|
||||||
|
</section>
|
||||||
|
|
||||||
|
|
||||||
|
</middle>
|
||||||
|
|
||||||
|
<back>
|
||||||
|
|
||||||
|
|
||||||
|
<references title='References' anchor="sec-combined-references">
|
||||||
|
|
||||||
|
<references title='Normative References' anchor="sec-normative-references">
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<reference anchor="RFC2119">
|
||||||
|
<front>
|
||||||
|
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
|
||||||
|
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
|
||||||
|
<date month="March" year="1997"/>
|
||||||
|
<abstract>
|
||||||
|
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="BCP" value="14"/>
|
||||||
|
<seriesInfo name="RFC" value="2119"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
|
||||||
|
</reference>
|
||||||
|
<reference anchor="RFC3339">
|
||||||
|
<front>
|
||||||
|
<title>Date and Time on the Internet: Timestamps</title>
|
||||||
|
<author fullname="G. Klyne" initials="G." surname="Klyne"/>
|
||||||
|
<author fullname="C. Newman" initials="C." surname="Newman"/>
|
||||||
|
<date month="July" year="2002"/>
|
||||||
|
<abstract>
|
||||||
|
<t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="RFC" value="3339"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC3339"/>
|
||||||
|
</reference>
|
||||||
|
<reference anchor="RFC5011">
|
||||||
|
<front>
|
||||||
|
<title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
|
||||||
|
<author fullname="M. StJohns" initials="M." surname="StJohns"/>
|
||||||
|
<date month="September" year="2007"/>
|
||||||
|
<abstract>
|
||||||
|
<t>This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t>
|
||||||
|
<t>This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="STD" value="74"/>
|
||||||
|
<seriesInfo name="RFC" value="5011"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC5011"/>
|
||||||
|
</reference>
|
||||||
|
<reference anchor="RFC7344">
|
||||||
|
<front>
|
||||||
|
<title>Automating DNSSEC Delegation Trust Maintenance</title>
|
||||||
|
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
|
||||||
|
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
|
||||||
|
<author fullname="G. Barwood" initials="G." surname="Barwood"/>
|
||||||
|
<date month="September" year="2014"/>
|
||||||
|
<abstract>
|
||||||
|
<t>This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="RFC" value="7344"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC7344"/>
|
||||||
|
</reference>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</references>
|
||||||
|
|
||||||
|
<references title='Informative References' anchor="sec-informative-references">
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<reference anchor="RFC9499">
|
||||||
|
<front>
|
||||||
|
<title>DNS Terminology</title>
|
||||||
|
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
|
||||||
|
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
|
||||||
|
<date month="March" year="2024"/>
|
||||||
|
<abstract>
|
||||||
|
<t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
|
||||||
|
<t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="BCP" value="219"/>
|
||||||
|
<seriesInfo name="RFC" value="9499"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
|
||||||
|
</reference>
|
||||||
|
<reference anchor="RFC8767">
|
||||||
|
<front>
|
||||||
|
<title>Serving Stale Data to Improve DNS Resiliency</title>
|
||||||
|
<author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
|
||||||
|
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
|
||||||
|
<author fullname="P. Sood" initials="P." surname="Sood"/>
|
||||||
|
<date month="March" year="2020"/>
|
||||||
|
<abstract>
|
||||||
|
<t>This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.</t>
|
||||||
|
</abstract>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="RFC" value="8767"/>
|
||||||
|
<seriesInfo name="DOI" value="10.17487/RFC8767"/>
|
||||||
|
</reference>
|
||||||
|
|
||||||
|
<reference anchor="E-Gov-Resilience" >
|
||||||
|
<front>
|
||||||
|
<title>Assessing e-Government DNS Resilience</title>
|
||||||
|
<author initials="" surname="Sommese et al">
|
||||||
|
<organization></organization>
|
||||||
|
</author>
|
||||||
|
<date year="2022"/>
|
||||||
|
</front>
|
||||||
|
<seriesInfo name="IEEE" value="Proceedings of the 2022 International Conference on Network and Service Management (CNSM 2022)"/>
|
||||||
|
</reference>
|
||||||
|
|
||||||
|
|
||||||
|
</references>
|
||||||
|
|
||||||
|
</references>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</back>
|
||||||
|
|
||||||
|
<!-- ##markdown-source:
|
||||||
|
H4sIAAAAAAAAA5Vca5PbyHX9PlXzH7q0H6RxSJZWWsdZxY/I0jg7ZUva0shZ
|
||||||
|
p1xbXhBokp0B0TQaGJpW6b/n3Ec3GiDoOCq7doYE+nH73nPPffQsl8vrq851
|
||||||
|
tX1l7prlp9Za851rumA2vjVv39+bjza42tmmPF1fFet1ax9fGdcsOzy53NGT
|
||||||
|
11eVL5tijxGqtth0ywdfP+yLZjl5qiw6u/XtiV7f+Our6yt3aF+Zru1D9+L5
|
||||||
|
82+fv8AErS1eGX/A40ffPmxb3x8wbBP84frqwZ7wYUUL7Wzb2G75lua7vgpd
|
||||||
|
0VR/KWrfYA0ni5cP7tX1lTEff/fGVqE71fFzYzpf5j+7prJNlz4JvsWSN2H4
|
||||||
|
4LQf/961rhyeL/1+j/eH711Tuyabzf6tW9YudEsMtPY1Hlz6n/0Lbb7ou51v
|
||||||
|
eZn8zzX48sPK/F6klz4XyX6oi83ZV3ZfuPqVUXn/hwu+XPl2S6M3vt0XnXu0
|
||||||
|
UQ4vvv762/jzy5cv088/f/711/HnX7z85ptX9DaOBkc0GeHbb75Nb/3bL/71
|
||||||
|
F/zz7fI//eMy6YiN+1GVevI6BBuCa7bG0pM4NpLXWLHsE32pgoa8Mi+ev3ih
|
||||||
|
H0xlZJYipnsSe7DGdqaoV/p1sK3DkFh4euHJ3e3t7ZNX5vvWl9ZWWEYwfmO6
|
||||||
|
neVZVJGwS98UtXnjm41taUHGN+a97UgFDVTL3Nv20eHjd0VTbC3v4Nmb9/fv
|
||||||
|
eJQbkdhyuTTFGvpRlB39/oM1hxaLxLOF2VtspPK1357M+mSOO1fuTCMzBKyn
|
||||||
|
6Exr65OBgE6kY77Z4jePow4HW7qNK03lcdoNq0MwZdGYtYX2WbP3rcXLUZZQ
|
||||||
|
arOBWvT4CMLivR5gVliGjLCixX3Cp8Xh0PoC69Bl2sr0OCyslg12uXG1he4+
|
||||||
|
YApb7orGhT0N2NqybwP0AkpGa4FobMtTFVXlSJS0hF3xSIdOs8shuo6VycTn
|
||||||
|
N76u/dEU11cbe4TF2zYew4EkCGmHtNLQb7c20AJFjrp9jGUxa2D5Fo1AlmtK
|
||||||
|
YAhrXOW2mLWGDEnxrNs23WllcC6VDWXrMECXiWHBvzUWE4cCp5AtCXgS17Rg
|
||||||
|
faAnK4hnvy/o9FwYhAnRtb7q4/JJK/auqmpLv93plzTs9dWvsn/8JP2Le34r
|
||||||
|
x/0eIjb3J2x+b57Bam4MTYZD2BftQ7GuSVvwH8vLilpAkMivrMx3/mix+QWd
|
||||||
|
DzDiZGzz6KBejFrmYP2B3oUG1d4/kNBwfDucC3Z4IshueCq8jP+VnpZfG5Im
|
||||||
|
i4A+cE3vuhNZlYqbT5hEpdrn2usrf2zGE8tqSUwGCEk2WONUDpbQuIQVr8yH
|
||||||
|
ho7HB8gt/4K2T1NDFAtaq1jS0eLsy16nxCPwSD3NxGcAuw6u0jWL3tFO1Uqg
|
||||||
|
TMEy6v3MvGZA7xvdkSN4gOLRpDu33UHacS0dTZ52ygYMKRLuVC6UJCE+laPr
|
||||||
|
dmqy9KPao/1bsYfcVwAANcp/j/PHReFJwkjM7uuejcqXZHfRpCtb2y2rJwyh
|
||||||
|
O5Ih0HC0AJJtNoMOffc9HRfUG1ZI25NjpfG6ghzaJxFqsk/eEv9CY+YrHtkz
|
||||||
|
RELaEzpX1xgTFsD7BsaJggzSFO8oAl0Bwfk9eigBisnxJJqZyng6gJgJziU/
|
||||||
|
RWg47MH3rFx1XF/t9g7YsTK/7Tuzw+s8c2GAO9dXNaw9wXbcJjuJ0EOxdPSx
|
||||||
|
GhWkzFjHoXWBJt4foHkKF9ArTK+6ppCdCQ9ci+QKrHjEUMFgdgzlMqtZyMTA
|
||||||
|
FTgLEAdX4iMAKqAZUsFxO+FSNOnK3Ikzw+qxti6dsGAwfbMGKtFyImWCqZDY
|
||||||
|
Qb9oa4toxsH+tSfvAc/i+7picAVekuMpYEXm9tGSrRHc1jWzg7aAzIBkJPtn
|
||||||
|
oqrxGOnoRkqyGJ2moH9LorC5Cdl9sPUjScB2JeMctgHftCcpF+mgsTG2ikfW
|
||||||
|
HkKHM0vo/MHUgL06noDo7dguzJF2en2F55qux7agKbaoaHzXFGsAKdQWvxDI
|
||||||
|
kW7Ela7E3b9uPKZv44gCy2GPcfBjTXMJryB87qyY0459VdPv13iRFBpnabYD
|
||||||
|
K0rCaPumUTAmIemAolj0DuHppz+8XZn3HjpcqmLS4CWbXwlND6VtitZ5OjbS
|
||||||
|
dyysP+DMbLEfI4GDPtWejPL1piP1JlCtcWhy3nqQJ5MooWyqxTpIyRwclO+h
|
||||||
|
2ZvWY2QgADbwjFxxIHriSDq0O34RS+Q5XnwDLwN1uVlkOhtYL5MQxps/EsDw
|
||||||
|
tJHh8EG8NmzBa9tAXUeH0QhY0OnSihU3WVO9x2Z/ILGM1Af0s2AOUZAVwNed
|
||||||
|
ngbVo6lGPStLyP/GbC1ZY1ETKlUGr0JdcZ4Am/teyMCwAtY3k6lbZVnLoB7X
|
||||||
|
V2Le4s2YCebuJbkO6BBPHHQZC8ACj3V9NadGJLfal0CXPchvQcdUY8Hj8WSn
|
||||||
|
LMwf6NyhZvTtAysSrVagEhFNQRq2ZVyBRVKoxDgZ9YxQtSF9XFvS3aiVkIvK
|
||||||
|
niwJ3j551kS8icKIvTnQovIE8wiHorRqancTp07uPv2Mc87JY+JhtLmF+N+9
|
||||||
|
awhuQn846JrnXA6TSr/ZkGk2NoYJVpSXVPNYtBUOewsLYjPpO9/4/WnEvNhR
|
||||||
|
mQk8jjhDcUbpSRVJ7qVtO/yKswe08OSefhl25CO5hb6kCU/mmV1tV4KuF+En
|
||||||
|
GsZR0Z04MRC0IketVL1QVQFJhC/tKNBCWF0mSZDV3JDoE8MlBHcMAiI2nO/G
|
||||||
|
VSyEde9qCrey0IG1rfJQS2wPaAE0KxgXyBTooa1NFgrXCHNemU9jah1EqcBs
|
||||||
|
SQlwtOJDirbcwcOzsBf6rricpBlxExgcPOA0sMCM2jM3gKpii8Wjd5XoBumh
|
||||||
|
wXFuE4ZxCFHUwctjo62QZ+98CZIsOwpMvBF/YYa+LtphcMaMht0jThOyjY5l
|
||||||
|
FJrhQGqc0lNNpUhk9nQhAg88m/r7Ykt0rjOPZIs9gVIHt/WAiLLsfORz4tzB
|
||||||
|
yvAiu9UJlTxQnBzAK35HBhM1gIj28lDAkmRMmpmYFn6z+wPjMe8mHwkW5mEu
|
||||||
|
i+srwTSZOTpYKAlxHkIPwapFJqOaYMBIAIN9gP3W7u+kSzMh0T0ZMgHHLaII
|
||||||
|
qAbU4/qK6Mj97ZsbODSNSEnHiOuQ6YZEsJjuAhRE/yiA5e3B8/DmiwqowKpm
|
||||||
|
25ZEKNFQ6GsyDsCkusa/44D0tJV15V6FFKCsezaGt/egSoOM7qGntr2JslqZ
|
||||||
|
dxTKby0+LEDNjtFK2ScxgBZBmUQxRAcEXRjBQpGCRvoUTJEv40fJvWMJY8MR
|
||||||
|
z9rw7+y3M7oKcsEB48qudGC2k3xEcz7gUb859OvahR15w2bMAsW1Q3nIrulh
|
||||||
|
lovgwTCRrJy2WNcJ/zPlH8X+EvwnsFkDwR5YWhk8Es9CtA/lglgmyIwnY9Qa
|
||||||
|
4XxlRgZI0iN7UQ7TMiVkpcV8MA9gqtCGKEQmQObzZ02Sffmy4AwNYmD1YqTb
|
||||||
|
arOfP/MIX76scje3B4VgFxezFCxazeN0Lgs3TdwXEYCxlzHTvJEwcB8ViI/C
|
||||||
|
/B2ebkQHKJfLjzPdaqwVcyXPA2FxXOPNti8Qb3Q2JQD8EP/4Ju5l2CSeKu2h
|
||||||
|
+/JltCvWwMoWKTZoEYO4Vt0t0zByc9FRD7Hp/AsK8LQjaEXwpSsoYUR7W03W
|
||||||
|
MzhrWVKAjnYAgYOHgrE7Y2a/h6flLBoLbN+HjqiN6YoHq+mQ/dqpl1Wb4tNT
|
||||||
|
h4fgLJ/04GtXnnhCCNmFsgdtZYYs3yS+FHnyeZqpoAAVNqeuD0vDGXfCCzoh
|
||||||
|
mSFzdDHtRyPBQdbVEDQn9sQJP0CgbRlb7r/78Mc/vF2Yj7dvPrx7d/v+7e1b
|
||||||
|
fv3dH+8/KYu7vqJcGxuq3bhGKASrO2WYocpkP64FmTjqoHRKj1BzOiVoEnt/
|
||||||
|
cA4ii5phNjpkSvi5scWL/pjPX0VNGufOxv9oDF4P5ash76hwIbEYHZbym+bJ
|
||||||
|
B9Zbz+TbU4qs2FqB11z7EtJ2p4MYXDIOZj3bnlMKT4fhQQsw/lPlMDwXR5KU
|
||||||
|
c+FEIyeFSLh331PmtKVUQDy+WB2ISVN6OI+dh62Qvi+gR8L//KY7Mi5QkWBN
|
||||||
|
pKJri8MQ+AzZpNzTS2Lw4GypmQ8dZqEEj+oXpO34lqCWkLsbT7h6Mn9yaw/P
|
||||||
|
edQUqUIkQWBFVZ71KclO+OfTXHAaiE1hjM2buBvFh2Du9YbOYNiqTpIhWQV/
|
||||||
|
tpBAxm04eha7CBqwwEAeEU1SuAOTjUhPK3IdqQBjDOeYfcX5kBhOXs5bFdVO
|
||||||
|
6wjkLCA4oP/FBPf11ce5aOTzVxj/S0oLz/67+HJShBGMr63uQVHdFhTYGqpB
|
||||||
|
gKYRgo1OT+LrZnKkQsL51EQSck5zpsKnkFJd/1jp/7G+wx6mmgByNzmB6B6I
|
||||||
|
mq7tYJeVjDDeBq16DybnKCqSEYPGwJZxTtOEDYHrUlXpGf6/hq64oysfbkbH
|
||||||
|
/iyDnBuajPfLPqtLFqvDdDJF7iwEYf/84d3vXykI/+ZH1s215AYqBB04IATw
|
||||||
|
8mLm+tQVJr4DgUPXmCcwDBx8JylGDSwhGlAUZyn6Y7cStzpKs2Mm8kbCnmLe
|
||||||
|
f5PtQoEtX4gyM0t5olIcA2PZbLSdVFS5zd7zGJhjpF5Yf9FSNYfd6VBhYqgZ
|
||||||
|
DiOePVw5xRkbinnDjoa/+543MKS7RNHJF+l+q4KUnYFwiHgIavpWY+nrqxg/
|
||||||
|
E/wM+pBrnc68tlneyvKiMQ4GGBLG82PNDaNZ3nMOTBvj5ABUY9PXBGxTAq8h
|
||||||
|
bohphSzQPTcdnfzd6/+WYVPSTgWdzU3+PyrtPETPLcY1FSEn1W8kCUChzYrC
|
||||||
|
t0iEEQsV9Zm7zonIsTjxjJnwubLE1QpvZASpOCkhWhk1qY+3/3V3+4N58fzr
|
||||||
|
b83vpYsg/HguVjZCFgDkT1Y3S/OYHCC+hHek1oUlFAbQtZKAqZB+BrzKgVCp
|
||||||
|
z5oHe0rB04SeShKDtiOxRz6qLImAu3BMHggJ7jrFiPEX8PhSdRkOKAqTN8II
|
||||||
|
ReV+Immvh/QD5ZigHhzyQEPJdJh80jIgqW5HMdRmuaYPM8CCrqiUeNnRxfmW
|
||||||
|
4XxewYhEG3BBV6Wc+KAqWMJYMOfKl5Sas2NzLpXioGzPKaBSuFKISgAIiQHp
|
||||||
|
lljxmu087S8sKDjE13/tbXuKpexPf/qk0TpB51i6X5EL+5JcyAUJZO4z7rIY
|
||||||
|
u1h2D6IT0iQB/ACT+CjTkjtRHjkkVkevR42hk4E0hFypjzhjfz9wckaq5/E4
|
||||||
|
oA41bC1wnfcIn2zTakgF3gqP5EVp5iLmH6ohDBaOpQQn+lTe0EfagmKkHPzT
|
||||||
|
MNsjkJIqNOuuCBR9YZyoPtStwEkVMbCY/8qkKzZnk4wUv1hUYw4zmFN/qMb6
|
||||||
|
J4uYFLQMRQfYx4wTTMHxINCYaBn5T7PzNaI9Il6gaOtYmLZVCoLm3ab4h51v
|
||||||
|
lFN8+vSHIDWxLScYy52FO0TorClVnXS6fDmHlRnCH0GnBPyqUwjV2PBUQj3l
|
||||||
|
DzwC1ma7QOAaglvn7mJQydkuES5k1n7LJ6p4nWWSmHjEGl5ebXJqD4m4a2wc
|
||||||
|
9X58mBqb+LSzGFPNCXSh1YzpMjLOfLRU8uTiW8DeBe5OQ6FUbYvSgox8ayDS
|
||||||
|
khLh+HSZpUSf0TY0G1po7jXl66IlcSuGe2BQNqFfs7HMxoR8hoQHN1LFJY2t
|
||||||
|
2uJYDEQtq4wqFZP5GNuoik15Tf6ZE58rE1WPsd9MXBA7xEhl1Qo1ta6YOLQ4
|
||||||
|
iJWxxT0NqQ4+FJGHjTOc8Nuc2whU0+wKKuhR/BnzJz+nWTIHFmNA5gPYpqjJ
|
||||||
|
hmWGc3e0St4D53SIv9HYZhmnH23QcUgop3eGxVS00Ak0SBK2ijNQdZN87Ny8
|
||||||
|
uiWRoOY9DiCdXHyUZaiQ4pPKqHoEzhWRDpsKfQImLWeh8oOhdBRVyUG4KeJc
|
||||||
|
XYoJzwx8EoCogXNihpqyIOA11Q+y3q/MynksRq6snslnwoV8LuRyN0i007x7
|
||||||
|
TZCMT0IybVkPmXqJ6GHYaKPf46KvMro7w0VKzSdwuZdFSB4hg2OimXsrFXBb
|
||||||
|
s53r+fXsQ+nMoVRCBrW+8IEZa/LnlwJvRv6on2PWOstMpnRHmDGpBOO39sPl
|
||||||
|
eVZlKdMAL2skmnT0jSg3a0dkhxzwqKcco6U4UU3s/Z+88fJMojgdlXhCN4lt
|
||||||
|
JmWAnA7JyiRO1nYWDDI8AfTgKMulNHWRqitW85qZjaizz9VeEEvNWN6KfJMX
|
||||||
|
zpW8f3r12dDi/FOKSLxmyNw2zbzpW1bxAYtjfjwdM0HdxmV1mPlgXhMpGla7
|
||||||
|
PBBbnAdcyhN0bfMCoFIZVwBuznWK+0VYKiSM7MSGVrckIYbsS3NoylfG6vyg
|
||||||
|
kcUEzThNzRU26X6QxIT0EhRaoCPHxvBquetR6kyswbDe++REkyRHoRQlAiN8
|
||||||
|
uNi2WSp2lTj59jcRA6gJa72MapU2utDcEvfdkhnx1Iwdv5NzplLP4jLmDTwT
|
||||||
|
3IkzGWJi0GltBtbqDKUuwrhNh3MaAy3lPs9p2oITT5S3mEk3uC5LLsRGxGkb
|
||||||
|
W1rHuBhZS2BJDQLiaamIuv4frT4g1HHhAREURxwFd3xLb8ZaElZKadwO7InO
|
||||||
|
UNJQfLDUZEIVl7XoRDPK16REz7ko2YrkLHVXUV9MDd7bUxZfMlu8BgnyzocJ
|
||||||
|
v/lxFtJ0TO1fLDla9QxVQ0uj+FMpsFb2UHsOEyd4H5tOxplVKYAOo9NOEVBz
|
||||||
|
fYmXK/EoJWryDAgGWQ/Uedxeod9N4t9wlmDRkOxD5qLejCtPn7/K/NfFUgsN
|
||||||
|
sq4L+s99Ws7nr3Say27zjkEy35USqJH8n7Eb5R8hi59+KV/++qcbOHSeIcTz
|
||||||
|
oMap6aFIENvawbkNgppLEKiUVmbYCRfJGm5kPfRdJyCE8J/LbnnwKyYpS2VP
|
||||||
|
9dNf9KxXadUxYudRGmKjB0eVZLcnHNsfkpelixkgtxL5SDZo5llNpUlMVKlu
|
||||||
|
SmAxiM2Jqrquk0BG+YXYk1TA+bTJDw5awpznyxAIzMagKdGjVgKJb1xLfpN1
|
||||||
|
nQ9iYdbQY+a8tUccyo6jMS+fY8Gn2AXYxf1pp0TKDDGTb+xRd59YIHElTgIM
|
||||||
|
XQaa88q1h3kEpl6IIgjoctFV4GauwDgpaEzI1fXVTz/9xJdKzg4Xn1FWyPxy
|
||||||
|
elC/NvyWGYBqnHM7UvnecrYNfgoYD0tEQNedDrHhwwEobv/0PT6VHHzUoEwZ
|
||||||
|
OAu1ibkgaNA3z19+E/V5+XL19ernhhHuw4AqGXw4ab4goCh9Nq+kzLTRlVko
|
||||||
|
21Hbj8jJ0L4TZkgpV7BSoX0KCIlBc7fDQJ/jVZmc/46nZCMbclkIVbRjc65x
|
||||||
|
nwPyrP1qVLtwYUHqsynaBV2YIrDebFzprHQBxOmFI+Sr4ObW897/xNBmhCEt
|
||||||
|
fkA5i2Okli5tAVBvKqAPSzw/BlIUvoXDSZ69S80P3NetoX7qZ9OLDJ8uuM2Q
|
||||||
|
iGFPtdRxGU5axOR+GbUZAv/XkguHbkOlUkbkH/b5EyJrA1m6N7DQ2Fx7+Qmb
|
||||||
|
YkcO7RWqql30GSHpJUXCq7lIqMa74aXIQJHG6L2K5pQm11NSJquNdMPapMm6
|
||||||
|
iGUTLTOYGYasc+8pAA99m/LZ1GMz3IHpuEYteeeJYP//UsU++BKirnVUsYtg
|
||||||
|
TOHMWrhardu/Y2ZlNxsv3dOKO9LvmVtXY+MwZA54fGslByIrTw8Sc+YGyCyP
|
||||||
|
rm2kDVVimm1NzQHsJuXiRrxIYb6Tx2aVc6GpXmmuyq4RsWhoGFX3eWOPzaWc
|
||||||
|
z9bjbVhK4GZ6O3PU/kUZAc4NsJzuz7u6wGe4QeuczszX5P6JTjFtTpHesJWZ
|
||||||
|
mZTTKpJLyS5YMcrhCw7YKI9o9XbVhft1sblh0KrUUcSrkExUUN1LWVup3Qdp
|
||||||
|
Y6PyZb5Fua3I6Kc1v9hlESSdw+tPxyBT6AypyeLiHcJ4d8BrbmjIjz4Nuq1n
|
||||||
|
CFURYTp6elP0dXc6a+CfqZaqlwvQ9rgAbl7B9ociVMuwlF16GfdsUC1kR92r
|
||||||
|
tPu11yhs3DHJbCPGuYCkLEQ+axFROpblVhZZX9ucdBLrkqL9SfQkTte1HpTI
|
||||||
|
wnqJck2y2bNqNtxpS4IpuDxLBVCKA23FPTYTdpTh4Cw51E003D0DBagJm6Ly
|
||||||
|
5o0WiDrKuteW3bPQ4s+fPrz98KMwkNTkOw5ULjaBXewZjSXd+c6dmVov+3Tu
|
||||||
|
sMaz3F3Kl7nlCFnPWXM2Xo1tuNEhRZeo83luDYelg86CvNQr5quHLLd3VJ1L
|
||||||
|
bYnqJQEDdCdofmOTgmNqhUmtZE4iKG5doiyM9ntE0yaP4dqy3z9yRrUaVTXU
|
||||||
|
V2lpJrtwKo7wQpMU0SUtcwzX5SZ9JnvZKAgKSI+j9i6u5iQrceEBNkr3TgOl
|
||||||
|
yeDbxFSrYk/RPxsqHZmGgBcXw61+EpC4bggx8hTTNKpMnQFRZkOTTLB2z8m6
|
||||||
|
uKDOrjKyO4TrsM0qqDY8SrUo3SGhtSuDkYt61IeaX+btiLYF9Td/k5szWUtN
|
||||||
|
fvVBri/70lY0yEI0dn3KL0ozg2yLLd/BGbqgqGUwq/NQpQE7q+lCBPXuSQYq
|
||||||
|
8V/zdG1hbdXTcd/uNHU4UwA/78wquFI1Ju2CKpgD9IBzXlJFYwIwX0LkpHbW
|
||||||
|
/jz0/gl2xtsIpIHayqqjc+hN12zi9uk+k+5Xc3jMf87KpVnn3PXV99LYe5Ze
|
||||||
|
0VbgC/gl6MUNhJ3m3VI3+nxvw3CdtMjzHDNxUYYvUah+KPOLIdPiGLNbv8/L
|
||||||
|
rimUmTRKdbEWdwHNqBSkPMbqRdbcdw5FwXSNKUOXmLxP58hRNtmCeS0XORbT
|
||||||
|
QpauJt/53BKSBCZcgwFggDhbZYsVmaaLUefX2vjiIFUSKbcPui4QHyhi5XuS
|
||||||
|
krePupLd8pGulOlNhoGqT7ChuHilgbuDaLy87W/Nc9Xa95luN5JQKhLIYTm6
|
||||||
|
LfvszRu+3BhtZpxii7EsW1e8lLungWDd/KbelMSpQCxUGKGrtf6oJ5V2zVeI
|
||||||
|
qiqeTrw6Ng6ypMVOLvvwZY/jziuFoySI3KIdXSaM94AGHOOi7gARp1hsjThx
|
||||||
|
fnXF5RpBFYoqPcTgT0Qp/+M2A4EsxnfFsnZ8JXN8r5Hj82mDwgX3JAEZY/iy
|
||||||
|
KDV5RPGO1/vzwXV96nzItpmXZeL6KM8BCZW7hnVHWzUZwUYMpXDq9GQidfV9
|
||||||
|
yncPoSuL5WLDVyKtCfNDVmNPVs3tkqkIfznCU9+vjIsslW8ex8SW9jENd7bz
|
||||||
|
elbOIqj/LXBdapDP0MCWDiTaAyNTdnX8ZlTUGqXxR0xP8ylRzDwmYQ95d98s
|
||||||
|
++i+Ri3zpwveM61u+AMu6Wo2YYLkunnoTn8569yO5aNxs95FLr8Uk2P7B6Vq
|
||||||
|
pJNZ/gDBAAfmj4zzLAtIS0tGQqJSfSf3Ma4VexgHFlixikiSyRK2x6ZgNSIT
|
||||||
|
/66JTsrZKoHzy5QjBaR9OO8nvEA2xprGV4MP3VJrM6OCgjp7OO3X71//MyEK
|
||||||
|
PfveG358culHbqBK43350PhjbSsGk7mRzm/z8O2yQA6SMzJ6FRQnU1NDH01G
|
||||||
|
iBIvGHFh7Oz621i5YmvFns7Cpm6y9Nck7j24QndSaE8LkQ5fEnn8ezqOQWtT
|
||||||
|
x7An1j8vjahS/ezrYvNKU0m/ekK/PfkSBf6/yzw8h7xMAAA=
|
||||||
|
|
||||||
|
-->
|
||||||
|
|
||||||
|
</rfc>
|
||||||
|
|
||||||
457
draft-kolkman-dns-in-tree-hints.md
Normal file
457
draft-kolkman-dns-in-tree-hints.md
Normal file
@@ -0,0 +1,457 @@
|
|||||||
|
---
|
||||||
|
title: In-Tree Hints for DNS Resiliency
|
||||||
|
abbrev: in-tree-hints
|
||||||
|
docname: draft-kolkman-in-tree-hints
|
||||||
|
category: info
|
||||||
|
|
||||||
|
ipr: trust200902
|
||||||
|
area: ops
|
||||||
|
workgroup: dnsop
|
||||||
|
keyword: Internet-Draft
|
||||||
|
stand_alone: yes
|
||||||
|
pi:
|
||||||
|
RFCedstyle: yes
|
||||||
|
toc: yes
|
||||||
|
tocindent: yes
|
||||||
|
sortrefs: yes
|
||||||
|
symrefs: yes
|
||||||
|
strict: yes
|
||||||
|
comments: yes
|
||||||
|
inline: yes
|
||||||
|
text-list-symbols: -o*+
|
||||||
|
|
||||||
|
author:
|
||||||
|
ins: O. Kolkman
|
||||||
|
name: Olaf Kolkman
|
||||||
|
email: kolkman@isoc.org
|
||||||
|
|
||||||
|
normative:
|
||||||
|
RFC2119:
|
||||||
|
RFC3339:
|
||||||
|
RFC5011:
|
||||||
|
RFC7344:
|
||||||
|
|
||||||
|
|
||||||
|
informative:
|
||||||
|
RFC9499:
|
||||||
|
RFC8767:
|
||||||
|
E-Gov-Resilience:
|
||||||
|
title: "Assessing e-Government DNS Resilience"
|
||||||
|
date: 2022
|
||||||
|
author:
|
||||||
|
- ins: Sommese et al.
|
||||||
|
seriesinfo:
|
||||||
|
"IEEE": Proceedings of the 2022 International Conference on Network and Service Management (CNSM 2022)
|
||||||
|
|
||||||
|
|
||||||
|
--- abstract
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
--- middle
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
============
|
||||||
|
-------
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Consider the following failure case:
|
||||||
|
|
||||||
|
* A community of interest is highly dependent on services that are
|
||||||
|
discoverable with names within the example.net domain;
|
||||||
|
|
||||||
|
* A failure in DNS resolution occurs in the delegation between .net
|
||||||
|
and example.net;
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
This failure case may sound relatively limited. But here are a few
|
||||||
|
less abstract examples of such failure.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
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 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.
|
||||||
|
|
||||||
|
While unthinkable even a few years ago these sort of scenario are now
|
||||||
|
being considered in the context of international stability in
|
||||||
|
cyberspace.
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
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 {{RFC8767}}, more
|
||||||
|
on this in section {{stale}}.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In section {{concept}} we describe the idea and the requirements for a
|
||||||
|
recursive DNS server and the requirements of the zone associated with.
|
||||||
|
In section {{resilience}} we shortly point to other measures that must
|
||||||
|
be taken in combination with this mechanism. In section {{policy}} we
|
||||||
|
discuss some policy considerations and the dilemmas that exist with
|
||||||
|
respect to intentions of the DNS parent and child.
|
||||||
|
|
||||||
|
This document uses uppercase SHOULD, RECOMMENDED and MUST in the
|
||||||
|
meaning defined by {{RFC2119}}. Their lowercase equivalents do not
|
||||||
|
have normative meaning.
|
||||||
|
|
||||||
|
The in-tree hints concept {#concept}
|
||||||
|
==========================
|
||||||
|
|
||||||
|
{{RFC9499}} 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."
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
Recursive nameserver {#rec}
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
Recursive nameserver software will need to be modified to deal to work
|
||||||
|
with in-tree hints.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
When there are no in-domain (in bailiwick) nameservers ({{RFC9499}})
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 {{signal}} describes the RECOMMENDED way for domain name
|
||||||
|
owners to signal their intent. [OMK: REVIEW 2019 Keywords]
|
||||||
|
|
||||||
|
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 {{RFC5011}}. 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}
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 {{RFC5011}} 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.
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
|
Domain Owner {#auth}
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
This section describes the operational practices that the domain owner
|
||||||
|
has to follow in order to achieve the resiliency within the domain.
|
||||||
|
|
||||||
|
The domain owner MUST maintain its DNSSEC configuration using the
|
||||||
|
mechanism described in {{RFC5011}}.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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]
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
[OMK: should there be language here about out-of-domain nameservers?]
|
||||||
|
|
||||||
|
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 {{signal}}.
|
||||||
|
|
||||||
|
|
||||||
|
Operational Considerations {#operational}
|
||||||
|
======================
|
||||||
|
|
||||||
|
bla
|
||||||
|
|
||||||
|
Signaling {#signal}
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
It is RECOMMENDED that a domain owner (the owner of `<domain>`)
|
||||||
|
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 `_in-tree.<domain>` containing an
|
||||||
|
expiry timestamp in {{RFC3339}} format. The expiry timestamp indicates
|
||||||
|
the date to which the owner is committed to follow the instructions in
|
||||||
|
section {{auth}}.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
```
|
||||||
|
_in-tree.<domain> TXT <expiry timestamp>
|
||||||
|
```
|
||||||
|
|
||||||
|
[OMK: Alternatively we create a trivial RR type for this. EXP RR
|
||||||
|
containing a timestamp as defined in RFC4034 section-3.1.5 ]
|
||||||
|
|
||||||
|
Out of band signaling is not in scope for this memo.
|
||||||
|
|
||||||
|
|
||||||
|
Achieving true resiliency of services within the domain. {#resilience}
|
||||||
|
--------------
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
Serving stale data {#stale}
|
||||||
|
----------------
|
||||||
|
|
||||||
|
In-tree hints are complementary to serving stale data
|
||||||
|
{{RFC8767}}. 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.
|
||||||
|
|
||||||
|
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 {{RFC5011}}, 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.
|
||||||
|
|
||||||
|
Conclusions
|
||||||
|
=============
|
||||||
|
|
||||||
|
[TODO]
|
||||||
|
|
||||||
|
|
||||||
|
Security Considerations
|
||||||
|
=======================
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
This mechanism intends to provide resilience for network
|
||||||
|
failures. However, it adds complexity in software and operational
|
||||||
|
procedures, thereby increasing the fragility.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
Policy Considerations {#policy}
|
||||||
|
=====================
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
IANA Considerations
|
||||||
|
===================
|
||||||
|
|
||||||
|
No IANA considerations herein.
|
||||||
|
|
||||||
|
Acknowledgments
|
||||||
|
=================
|
||||||
|
|
||||||
|
This document is inspired by various hallway conversations about digital autonomy.
|
||||||
|
|
||||||
|
The author is an employee of the Internet Society, this document does
|
||||||
|
not necessarily reflect the position of the Internet Society.
|
||||||
|
|
||||||
|
|
||||||
|
{olaf: source="olaf"}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Reference in New Issue
Block a user