From 5bf029b162827f221a149830d6281f14f1dd9d69 Mon Sep 17 00:00:00 2001 From: Olaf Date: Tue, 12 May 2026 15:05:21 +0200 Subject: [PATCH] Initial version on public git --- .gitignore | 3 + Makefile | 22 + draft-in-tree-hints.html | 1607 ++++++++++++++++++++++++++++++++++++++ draft-in-tree-hints.md | 211 +++++ draft-in-tree-hints.txt | 560 +++++++++++++ 5 files changed, 2403 insertions(+) create mode 100644 .gitignore create mode 100644 Makefile create mode 100644 draft-in-tree-hints.html create mode 100644 draft-in-tree-hints.md create mode 100644 draft-in-tree-hints.txt diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..9b404b7 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +.refcache +*-pre-* +.vscode diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..5a736b4 --- /dev/null +++ b/Makefile @@ -0,0 +1,22 @@ + +DRAFTS = in-tree-hints +VERSION = pre-00-20260512 +OUTPUTS = $(foreach draft,$(DRAFTS),draft-${draft}-${VERSION}.html draft-${draft}-${VERSION}.xml draft-${draft}-${VERSION}.txt draft-${draft}.txt draft-${draft}.html ) +STAGING = staging.xml + +all: $(OUTPUTS) + +clean: + rm -f $(OUTPUTS) *.$(STAGING) + +draft-%.html: draft-%.xml + xml2rfc $< --html + +draft-%.xml: draft-${DRAFTS}.md + kramdown-rfc2629 $< > $*.$(STAGING) + mv $*.$(STAGING) $@ + +draft-%.txt: draft-%.xml + xml2rfc $< --text + +.PHONY: all clean diff --git a/draft-in-tree-hints.html b/draft-in-tree-hints.html new file mode 100644 index 0000000..d08e850 --- /dev/null +++ b/draft-in-tree-hints.html @@ -0,0 +1,1607 @@ + + + + + + +In-tree Hints for DNS Resiliency + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-Draftin-tree-hintsMay 2026
KolkmanExpires 13 November 2026[Page]
+
+
+
+
Workgroup:
+
dnsop
+
Internet-Draft:
+
draft-kolkman-in-tree-hints-pre-00
+
Published:
+
+ +
+
Intended Status:
+
Informational
+
Expires:
+
+
Author:
+
+
+
O. Kolkman
+
+
+
+
+

In-tree Hints for DNS Resiliency

+
+

Abstract

+

By configuring so called in-tree hints in recursive nameservers and by following operational practices, the resiliency against certain types of DNS failures increases. 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 13 November 2026.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+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 their own environments and reduce external dependencies.

+

This memo documents 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.

+

In an illustrative scenario, consider an enterprise 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. Specifically, if the domain data for example.net is not cached within the enterprise network, users will experience DNS resolution failures. This means they will be unable to access critical services because the necessary delegation from the .net top-level domain to example.net is unavailable.

+

Moreover, and perhaps more importantly, this approach offers protection against various attack vectors that could compromise the delegation process. For instance, man-in-the-middle (MITM) attacks may attempt to alter delegation records, which could lead to denial of service, particularly in systems utilizing DNSSEC (Domain Name System Security Extensions). Additionally, threats such as DNS supply chain attacks or inadvertent errors can result in unauthorized changes to the delegation, including DS (Delegation Signer) records. Finally, this method may offer some protection if, in an event that would be catastrophic for the Internet, geopolitical tensions lead to the de-delegation of a countries top-level domain.

+

Our approach is designed for proving resiliency for the Internet's naming function and does not bring full resiliency by itself. Instead, we this is as a building block for resiliency of critical infrastructure or digital autonomy. The approach is complementary to serving stale data from a resolvers cache [RFC8767] more on this in section Section 3.3.

+

An important requirement of this approach is consistent with the architecture, design, and operation of the DNS and the global Internet. By following practices herein we avoid namespace fragmentation. The approach avoids fundamental protocol changes, in particular it avoids alternative roots.

+

We describe what 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. For instance, when their parent nameservers are not reachable or there is a broken delegation from the ancestor domain. Here, 'broken' means that DNS resolver receives parental data that is inconsistent with the intent from the (child) domain owner, i.e. receiving data that is inconsistent with what is published on authoritative servers. Which includes not receiving data at all.

+

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 5 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. 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.

+

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.

+

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. This requirement can be enforced by the recursive nameserver software at the moment of configuration parsing.

+

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 Section 3.1 describes the RECOMMENDED way for domain name owners to signaling their intent. This is also something that the recursive nameserver can check and log.

+

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 MUST be used during the resolution process. 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. The recursive nameserver should honor the TTLs to regular check a change of the authoritative DNS RR set. 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 bonafide redelegation (in which case the parental records are likely a sub-set 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.

+
+
+
+
+

+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 (e.g. ns.example.com for the example.com domain). 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.

+

Furthermore, the in-domain nameserver SHOULD be positioned in a network that shares connectivity fate with the clients that rely on the domain. 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 a network connection to the in-domain nameserver.

+

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 Section 3.1.

+
+
+
+
+
+
+

+3. Operational Considerations +

+
+
+

+3.1. Signalling +

+

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 memo. 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 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 signalling 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 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.

    +
    • +
  • +

    Running a local root [RFC8806] may be an additional method to create resiliency against certain failure cases, mainly failure to connect to DNS root-servers. When resolvers implement the local root approach they MUST give prefer the information in the in-tree hints file to the delegation information from the root. In other words they should treat the local root as any other root server.

    +
    • +
+
+
+
+
+

+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 the domain owner, they have to run in-domain nameservers and follow [RFC5011]. Similarly scalability concerns exist for recursive nameserver operators 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. Security Considerations +

+

In-tree hints can be used in recursive nameservers in combination with protective block-lists and does therefore not debilitate the available blocking mechanism available to protect the community of users of a recursive nameserver.

+

Mallwares can 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.

+

This mechanism intends to provide resilience for network failures. However, it adds complexity in software and operational procedures, thereby increasing the fragility.

+
+
+
+
+

+5. 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 or it has been de-delegated after 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 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 they are part of the community of interest and therefore have out of band means to contact the domain administrator. Also note that the operators of the domains usually 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 historically been able to overwrite their DNS configuration. They can use a recursive nameserver that does not use in-tree hints for a particular domain and therefore have the ability opt-out of the mechanism.

+
+
+
+
+

+6. IANA Considerations +

+

No IANA considerations herein.

+
+
+
+
+

+7. Acknowledgements +

+

This document is inspired by a conversation about digital autonomy.

+
+
+
+
+

+8. Disclaimer +

+

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. Appendix: Example configuration in Unbound +

+

[OMK: this example might be too vendor specific to maintain in an RFC]

+

It is relatively trivial to configure this methodology in Unbound. [OMK TODO: follow up with Willem for the example config]

+
+
+
+
+

+10. References +

+
+
+

+10.1. Normative References +

+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc7344>.
+
+
+
+
+
+
+

+10.2. Informative References +

+
+
[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), .
+
+
[RFC8767]
+
+Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, , <https://www.rfc-editor.org/rfc/rfc8767>.
+
+
[RFC8806]
+
+Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, , <https://www.rfc-editor.org/rfc/rfc8806>.
+
+
[RFC9499]
+
+Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.
+
+
+
+
+
+
+
+
+

+Author's Address +

+
+
Olaf Kolkman
+ +
+
+
+ + + diff --git a/draft-in-tree-hints.md b/draft-in-tree-hints.md new file mode 100644 index 0000000..9ba20c0 --- /dev/null +++ b/draft-in-tree-hints.md @@ -0,0 +1,211 @@ +--- +title: In-tree Hints for DNS Resiliency +abbrev: in-tree-hints +docname: draft-kolkman-in-tree-hints-pre-00 +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: olaf@xolx.nl + +normative: + RFC2119: + RFC3339: + RFC5011: + RFC7344: + + +informative: + RFC9499: + RFC8767: + RFC8806: + 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 + +By configuring so called in-tree hints in recursive nameservers and by following operational practices, the resiliency against certain types of DNS failures increases. 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 their own environments and reduce external dependencies. + +This memo documents 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. + +In an illustrative scenario, consider an enterprise 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. Specifically, if the domain data for example.net is not cached within the enterprise network, users will experience DNS resolution failures. This means they will be unable to access critical services because the necessary delegation from the .net top-level domain to example.net is unavailable. + +Moreover, and perhaps more importantly, this approach offers protection against various attack vectors that could compromise the delegation process. For instance, man-in-the-middle (MITM) attacks may attempt to alter delegation records, which could lead to denial of service, particularly in systems utilizing DNSSEC (Domain Name System Security Extensions). Additionally, threats such as DNS supply chain attacks or inadvertent errors can result in unauthorized changes to the delegation, including DS (Delegation Signer) records. Finally, this method may offer some protection if, in an event that would be catastrophic for the Internet, geopolitical tensions lead to the de-delegation of a countries top-level domain. + +Our approach is designed for proving resiliency for the Internet's naming function and does not bring full resiliency by itself. Instead, we this is as a building block for resiliency of critical infrastructure or digital autonomy. The approach is complementary to serving stale data from a resolvers cache {{RFC8767}} more on this in section {{stale}}. + +An important requirement of this approach is consistent with the architecture, design, and operation of the DNS and the global Internet. By following practices herein we avoid namespace fragmentation. The approach avoids fundamental protocol changes, in particular it avoids alternative roots. + +We describe what 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. For instance, when their parent nameservers are not reachable or there is a broken delegation from the ancestor domain. Here, 'broken' means that DNS resolver receives parental data that is inconsistent with the intent from the (child) domain owner, i.e. receiving data that is inconsistent with what is published on authoritative servers. Which includes 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 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. 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. + +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. This requirement can be enforced by the recursive nameserver software at the moment of configuration parsing. + +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 domain name owners to signaling their intent. This is also something that the recursive nameserver can check and log. + +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 MUST be used during the resolution process. 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. The recursive nameserver should honor the TTLs to regular check a change of the authoritative DNS RR set. 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 bonafide redelegation (in which case the parental records are likely a sub-set 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. + +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 (e.g. ns.example.com for the example.com domain). 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. + +Furthermore, the in-domain nameserver SHOULD be positioned in a network that shares connectivity fate with the clients that rely on the domain. 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 a network connection to the in-domain nameserver. + + +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} +====================== + + + +Signalling {#signal} +-------------------- + +It is RECOMMENDED that a domain owner (the owner of ``) signals to its user community that they are using the mechanism described in this memo. Signalling is done by putting a TXT resource record with owner name `_in-tree.` 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. TXT +``` +[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. + +* Running a local root {{RFC8806}} may be an additional method to create resiliency against certain failure cases, mainly failure to connect to DNS root-servers. When resolvers implement the local root approach they MUST give prefer the information in the in-tree hints file to the delegation information from the root. In other words they should treat the local root as any other root server. + +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 the domain owner, they have to run in-domain nameservers and follow {{RFC5011}}. Similarly scalability concerns exist for recursive nameserver operators 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. + + + + +Security Considerations +======================= + +In-tree hints can be used in recursive nameservers in combination with protective block-lists and does therefore not debilitate the available blocking mechanism available to protect the community of users of a recursive nameserver. + +Mallwares can 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. + +This mechanism intends to provide resilience for network failures. However, it adds complexity in software and operational procedures, thereby increasing the fragility. + + +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 or it has been de-delegated after 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 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 they are part of the community of interest and therefore have out of band means to contact the domain administrator. Also note that the operators of the domains usually 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 historically been able to overwrite their DNS configuration. They can use a recursive nameserver that does not use in-tree hints for a particular domain and therefore have the ability opt-out of the mechanism. + + + +IANA Considerations +=================== + +No IANA considerations herein. + +Acknowledgements +================= + +This document is inspired by a conversation about digital autonomy. + + +Disclaimer +========== + +The author is an employee of the Internet Society, this document does not necessarily reflect the position of the Internet Society. + + +{olaf: source="olaf"} + + +Appendix: Example configuration in Unbound +========================================== + + [OMK: this example might be too vendor specific to maintain in an RFC] + +It is relatively trivial to configure this methodology in Unbound. [OMK TODO: follow up with Willem for the example config] + + diff --git a/draft-in-tree-hints.txt b/draft-in-tree-hints.txt new file mode 100644 index 0000000..c140b30 --- /dev/null +++ b/draft-in-tree-hints.txt @@ -0,0 +1,560 @@ + + + + +dnsop O. Kolkman +Internet-Draft 12 May 2026 +Intended status: Informational +Expires: 13 November 2026 + + + In-tree Hints for DNS Resiliency + draft-kolkman-in-tree-hints-pre-00 + +Abstract + + By configuring so called in-tree hints in recursive nameservers and + by following operational practices, the resiliency against certain + types of DNS failures increases. 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 13 November 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. + 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. + + + + +Kolkman Expires 13 November 2026 [Page 1] + +Internet-Draft in-tree-hints May 2026 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The in-tree hints concept . . . . . . . . . . . . . . . . . . 4 + 2.1. Recursive nameserver . . . . . . . . . . . . . . . . . . 4 + 2.2. Domain Owner . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Operational Considerations . . . . . . . . . . . . . . . . . 6 + 3.1. Signalling . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Achieving true resiliency of services within the + domain. . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Serving stale data . . . . . . . . . . . . . . . . . . . 7 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. Policy Considerations . . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 8. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. Appendix: Example configuration in Unbound . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 10.2. Informative References . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 + +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 their own environments and reduce external + dependencies. + + This memo documents 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. + + In an illustrative scenario, consider an enterprise 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. + Specifically, if the domain data for example.net is not cached within + the enterprise network, users will experience DNS resolution + failures. This means they will be unable to access critical services + because the necessary delegation from the .net top-level domain to + example.net is unavailable. + + Moreover, and perhaps more importantly, this approach offers + protection against various attack vectors that could compromise the + delegation process. For instance, man-in-the-middle (MITM) attacks + + + +Kolkman Expires 13 November 2026 [Page 2] + +Internet-Draft in-tree-hints May 2026 + + + may attempt to alter delegation records, which could lead to denial + of service, particularly in systems utilizing DNSSEC (Domain Name + System Security Extensions). Additionally, threats such as DNS + supply chain attacks or inadvertent errors can result in unauthorized + changes to the delegation, including DS (Delegation Signer) records. + Finally, this method may offer some protection if, in an event that + would be catastrophic for the Internet, geopolitical tensions lead to + the de-delegation of a countries top-level domain. + + Our approach is designed for proving resiliency for the Internet's + naming function and does not bring full resiliency by itself. + Instead, we this is as a building block for resiliency of critical + infrastructure or digital autonomy. The approach is complementary to + serving stale data from a resolvers cache [RFC8767] more on this in + section Section 3.3. + + An important requirement of this approach is consistent with the + architecture, design, and operation of the DNS and the global + Internet. By following practices herein we avoid namespace + fragmentation. The approach avoids fundamental protocol changes, in + particular it avoids alternative roots. + + We describe what 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. For instance, when their + parent nameservers are not reachable or there is a broken delegation + from the ancestor domain. Here, 'broken' means that DNS resolver + receives parental data that is inconsistent with the intent from the + (child) domain owner, i.e. receiving data that is inconsistent with + what is published on authoritative servers. Which includes not + receiving data at all. + + 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 5 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. + + + + + + + + + +Kolkman Expires 13 November 2026 [Page 3] + +Internet-Draft in-tree-hints May 2026 + + +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. 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. + + 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. + + 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. This requirement can be enforced by the recursive + nameserver software at the moment of configuration parsing. + + 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 Section 3.1 describes the RECOMMENDED way for + domain name owners to signaling their intent. This is also something + that the recursive nameserver can check and log. + + 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} + + + + +Kolkman Expires 13 November 2026 [Page 4] + +Internet-Draft in-tree-hints May 2026 + + + 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. 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. The recursive + nameserver should honor the TTLs to regular check a change of the + authoritative DNS RR set. 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 bonafide redelegation (in which case the + parental records are likely a sub-set 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. + +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 (e.g. ns.example.com for the example.com + domain). 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. + + + + + + +Kolkman Expires 13 November 2026 [Page 5] + +Internet-Draft in-tree-hints May 2026 + + + 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. + + Furthermore, the in-domain nameserver SHOULD be positioned in a + network that shares connectivity fate with the clients that rely on + the domain. 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 a network connection to the in-domain nameserver. + + 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 + Section 3.1. + +3. Operational Considerations + +3.1. Signalling + + It is RECOMMENDED that a domain owner (the owner of ) signals + to its user community that they are using the mechanism described in + this memo. Signalling is done by putting a TXT resource record with + owner name _in-tree. 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. TXT [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. + + + + + + + + + + +Kolkman Expires 13 November 2026 [Page 6] + +Internet-Draft in-tree-hints May 2026 + + +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 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. + + * Running a local root [RFC8806] may be an additional method to + create resiliency against certain failure cases, mainly failure to + connect to DNS root-servers. When resolvers implement the local + root approach they MUST give prefer the information in the in-tree + hints file to the delegation information from the root. In other + words they should treat the local root as any other root server. + +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 the domain owner, they have to run in-domain + nameservers and follow [RFC5011]. Similarly scalability concerns + exist for recursive nameserver operators 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. + + + + +Kolkman Expires 13 November 2026 [Page 7] + +Internet-Draft in-tree-hints May 2026 + + +4. Security Considerations + + In-tree hints can be used in recursive nameservers in combination + with protective block-lists and does therefore not debilitate the + available blocking mechanism available to protect the community of + users of a recursive nameserver. + + Mallwares can 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. + + This mechanism intends to provide resilience for network failures. + However, it adds complexity in software and operational procedures, + thereby increasing the fragility. + +5. 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 or it has been de-delegated after 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 + 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 they are part of the community of interest and therefore + have out of band means to contact the domain administrator. Also + note that the operators of the domains usually 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 historically been able to overwrite their DNS + + + +Kolkman Expires 13 November 2026 [Page 8] + +Internet-Draft in-tree-hints May 2026 + + + configuration. They can use a recursive nameserver that does not use + in-tree hints for a particular domain and therefore have the ability + opt-out of the mechanism. + +6. IANA Considerations + + No IANA considerations herein. + +7. Acknowledgements + + This document is inspired by a conversation about digital autonomy. + +8. Disclaimer + + 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. Appendix: Example configuration in Unbound + + [OMK: this example might be too vendor specific to maintain in an + RFC] + + It is relatively trivial to configure this methodology in Unbound. + [OMK TODO: follow up with Willem for the example config] + +10. References + +10.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, + . + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + . + + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) + Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, + September 2007, . + + [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating + DNSSEC Delegation Trust Maintenance", RFC 7344, + DOI 10.17487/RFC7344, September 2014, + . + + + +Kolkman Expires 13 November 2026 [Page 9] + +Internet-Draft in-tree-hints May 2026 + + +10.2. Informative References + + [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, + . + + [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to + a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, + . + + [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, + RFC 9499, DOI 10.17487/RFC9499, March 2024, + . + +Author's Address + + Olaf Kolkman + Email: olaf@xolx.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman Expires 13 November 2026 [Page 10]