rfc9704.original.xml   rfc9704.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --> <!DOCTYPE rfc [
<?xml-model href="https://raw.githubusercontent.com/ietf-tools/xml2rfc/main/xml2 <!ENTITY nbsp "&#160;">
rfc/data/v3.rng" schematypens="http://relaxng.org/ns/structure/1.0" type="applic <!ENTITY zwsp "&#8203;">
ation/xml"?> <!ENTITY nbhy "&#8209;">
<!-- For a complete list and description of processing instructions (PIs), <!ENTITY wj "&#8288;">
please see http://xml.resource.org/authoring/README.html. --> ]>
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
(Here they are set differently than their defaults in xml2rfc v1.32) --> tf-add-split-horizon-authority-14" number="9704" updates="" obsoletes="" ipr="tr
<?rfc strict="yes" ?> ust200902" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" sy
<!-- give errors regarding ID-nits and DTD validation --> mRefs="true" sortRefs="true" version="3" consensus="true">
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-add-split-horizon-authority-14" ipr="trust200902" submissionType="IETF" xml:l
ang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="
3" consensus="true">
<front> <front>
<title abbrev="Establishing Local DNS Authority">Establishing Local DNS <title abbrev="Establishing Local DNS Authority">Establishing Local DNS
Authority in Validated Split-Horizon Environments</title> Authority in Validated Split-Horizon Environments</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-add-split-horizon-author <seriesInfo name="RFC" value="9704"/>
ity-14"/> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Dan Wing" initials="D." surname="Wing"> <author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization> <organization abbrev="Citrix">Citrix Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>4988 Great America Pkwy</street> <street>4988 Great America Pkwy</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region> <region>CA</region>
<code>95054</code> <code>95054</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>danwing@gmail.com</email> <email>danwing@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Kevin Smith" initials="K." surname="Smith"> <author fullname="Kevin Smith" initials="K." surname="Smith">
<organization abbrev="Vodafone">Vodafone Group</organization> <organization abbrev="Vodafone">Vodafone Group</organization>
<address> <address>
<postal> <postal>
<street>One Kingdom Street</street> <street>One Kingdom Street</street>
<city>London</city> <city>London</city>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>kevin.smith@vodafone.com</email> <email>kevin.smith@vodafone.com</email>
</address> </address>
</author> </author>
<author fullname="Benjamin Schwartz" initials="B." surname="Schwartz"> <author fullname="Benjamin Schwartz" initials="B." surname="Schwartz">
<organization abbrev="Meta">Meta Platforms, Inc.</organization> <organization abbrev="Meta">Meta Platforms, Inc.</organization>
<address> <address>
<email>ietf@bemasc.net</email> <email>ietf@bemasc.net</email>
</address> </address>
</author> </author>
<date/> <date month="December" year="2024"/>
<workgroup>ADD</workgroup> <area>INT</area>
<workgroup>add</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<abstract> <abstract>
<t>When split-horizon DNS is deployed by a network, certain domain names c an <t>When split-horizon DNS is deployed by a network, certain domain names c an
be resolved authoritatively by a network-provided DNS resolver. DNS client s be resolved authoritatively by a network-provided DNS resolver. DNS client s
that are not configured to use this resolver by default can use it for that are not configured to use this resolver by default can use it for
these specific domains only. This specification defines a mechanism for do main owners these specific domains only. This specification defines a mechanism for do main owners
to inform DNS clients about local resolvers that are authorized to answer to inform DNS clients about local resolvers that are authorized to answer
authoritatively for certain subdomains.</t> authoritatively for certain subdomains.</t>
</abstract> </abstract>
<note title="Discussion Venues" removeInRFC="true">
<t>Discussion of this document takes place on the
Adaptive DNS Discovery Working Group mailing list (add@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/b
rowse/add/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/ietf-wg-add/draft-ietf-add-split-hori
zon-authority"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>To resolve a DNS query, there are three main behaviors that an <t>To resolve a DNS query, there are three main behaviors that an
implementation can apply: (1) answer from a local database, (2) query implementation can apply: (1) answer from a local database, (2) query
the relevant authorities and their parents, or (3) ask a server to query the relevant authorities and their parents, or (3) ask a server to query
those authorities and return the final answer. Implementations that use those authorities and return the final answer. Implementations that use
these behaviors are called "authoritative nameservers", "full/recursive these behaviors are called "authoritative nameservers", "full/recursive
resolvers", and "forwarders" (or "stub resolvers") respectively. However, an resolvers", and "forwarders" (or "stub resolvers"), respectively. However, an
implementation can also implement a mixture of these behaviors, implementation can also implement a mixture of these behaviors,
depending on a local policy, for each query. Such an implementation depending on local policy, for each query. Such an implementation
is termed a "hybrid resolver".</t> is termed a "hybrid resolver".</t>
<t>Most DNS resolvers are hybrids of some kind. For example, stub <t>Most DNS resolvers are hybrids of some kind. For example, stub
resolvers support a local "hosts file" that preempts query resolvers support a local "hosts file" that preempts query
forwarding, and most DNS forwarders and full resolvers can also serve forwarding, and most DNS forwarders and full resolvers can also serve
responses from a local zone file. Other standardized hybrid resolution responses from a local zone file. Other standardized hybrid resolution
behaviors include <xref target="RFC8806">Local Root</xref>, <xref behaviors include <xref target="RFC8806">using a local root</xref>, <xref
target="RFC6762">mDNS</xref>, and <xref target="RFC7686">NXDOMAIN target="RFC6762">Multicast DNS (mDNS)</xref>, and <xref target="RFC7686">N
XDOMAIN
synthesis for .onion</xref>.</t> synthesis for .onion</xref>.</t>
<t>Networks usually offer clients a DNS resolver using means such as <t>Networks usually offer clients a DNS resolver using means such as
(e.g., DHCP OFFER, IPv6 Router Advertisement). Although this resolver is DHCP offers or IPv6 Router Advertisements (RAs). Although this resolver is
formally specified as a recursive resolver (e.g., <relref section="5.1" formally specified as a recursive resolver (e.g., see <xref section="5.1"
target="RFC8106"/>), some networks provide a hybrid resolver target="RFC8106"/>), some networks provide a hybrid resolver
instead. If this resolver acts as an authoritative server for some names instead. If this resolver acts as an authoritative server for some names
and provides different answers for those domains depending on the source and -- depending on the source of the query -- provides different answers
of the query, it is described as the network having "split-horizon DNS", b for those domains, the network is said to be using "split-horizon DNS", because
ecause those those
names resolve in this way only from inside the network.</t> names resolve in this way only from inside the network.</t>
<t>DNS clients that use pure stub resolution, sending all queries to <t>DNS clients that use pure stub resolution, sending all queries to
the network-provided resolver, will always receive the split-horizon the network-provided resolver, will always receive the split-horizon
results. Conversely, clients that send all queries to a different results. Conversely, clients that send all queries to a different
resolver or implement pure full resolution locally will never receive resolver or implement pure full resolution locally will never receive
them. Clients that strictly implement either of these resolution behaviors are out of scope for them. Clients that strictly implement either of these resolution behaviors are out of scope for
this specification. Instead, this specification enables hybrid clients this specification. Instead, this specification enables hybrid clients
to access split-horizon results from a network-provided hybrid resolver, to access split-horizon results from a network-provided hybrid resolver,
while using a different resolution method for some or all other while using a different resolution method for some or all other
names.</t> names.</t>
<t>There are several existing mechanisms for a network to provide <t>There are several existing mechanisms for a network to provide
clients with "local domain hints", listing domain names that have clients with "local domain hints", listing domain names that are given
special treatment in this network (e.g., <xref target="RFC6731"> special treatment in this network (e.g., <xref target="RFC6731">
RDNSS Selection</xref>, <xref target="RFC5986"> "Recursive DNS Server (RDNSS) selection"</xref>, <xref target="RFC5986">
"Access Network Domain Name"</xref>, and "Client FQDN" <xref "access network domain name"</xref>, and "Client Fully Qualified Domain Na
target="RFC4702"/><xref target="RFC4704"/> in DHCP, "dnsZones" in me
Provisioning Domains <xref target="RFC8801"/>, and <xref (FQDN)" <xref
target="RFC8598">INTERNAL_DNS_DOMAIN</xref> in IKEv2). target="RFC4702"/> <xref target="RFC4704"/> in DHCP; "dnsZones" in
However, none of the local domain hint mechanisms enables clients to Provisioning Domains (PvDs) <xref target="RFC8801"/>; and <xref
target="RFC8598">"INTERNAL_DNS_DOMAIN"</xref> in Internet Key Exchange Pro
tocol Version 2 (IKEv2)).
However, none of the local domain hint mechanisms enable clients to
determine whether this special treatment is authorized by the domain determine whether this special treatment is authorized by the domain
owner. Instead, these specifications require clients to make their own owner. Instead, these specifications require clients to make their own
determinations about whether to trust and rely on these hints.</t> determinations about whether to trust and rely on these hints.</t>
<t>This document describes a mechanism between domain names, networks, <t>This document describes a mechanism between domain names, networks,
and clients that allows the network to establish its authority over a and clients that allows the network to establish its authority over a
domain to a client (<xref target="establishing"/>). Clients can domain to a client (<xref target="establishing"/>). Clients can
use this protocol to confirm that a local domain hint was authorized by use this protocol to confirm that a local domain hint was authorized by
the domain owner (<xref target="validating"/>), which might influence the domain owner (<xref target="validating"/>), which might influence
its processing of that hint. This process requires cooperation between its processing of that hint. This process requires cooperation between
the local DNS zone and the public zone.</t> the local DNS zone and the public zone.</t>
<t>This specification relies on securely identified local DNS servers, <t>This specification expects that local DNS servers will be securely
and checks each local domain hint against a globally valid parent zone.</t identified and that each local domain hint will be checked against a globa
> lly valid parent zone.
<!-- [rfced] Section 1: This sentence read oddly, as it indicated
that this document checks each local domain hint against a globally
valid parent zone. We updated it as follows. If this is incorrect,
please clarify the text.
Original:
This specification relies on securely identified local DNS servers,
and checks each local domain hint against a globally valid parent
zone.
Currently:
This specification expects that local DNS servers will be securely
identified and that each local domain hint will be checked against a
globally valid parent zone. -->
</t>
</section> </section>
<section anchor="notation"> <section anchor="notation">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED< "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
/bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
bed in BCP 14 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<xref target="RFC2119"/><xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they appear in all capitals, as shown here.</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref
target="RFC9499"/>, e.g., "Global DNS". The following additional terms ar target="RFC9499"/>, e.g., "global DNS". The following additional terms ar
e e
used throughout the document:</t> used throughout this document:</t>
<dl> <dl>
<dt>Encrypted DNS</dt><dd>A DNS protocol that provides an <dt>Encrypted DNS:</dt><dd>A DNS protocol that provides an
encrypted channel between a DNS client and server (e.g., DNS encrypted channel between a DNS client and server (e.g., DNS
over TLS (DoT) <xref over TLS (DoT) <xref
target="RFC7858"/>, HTTPS (DoH) <xref target="RFC7858"/>, DNS (queries) over HTTPS (DoH) <xref
target="RFC8484"/>, QUIC (DoQ) <xref target="RFC8484"/>, DNS over QUIC (DoQ) <xref
target="RFC9250"/>).</dd> target="RFC9250"/>).</dd>
<dt>Encrypted DNS resolver</dt><dd>Refers to a DNS resolver <dt>Encrypted DNS Resolver:</dt><dd>Refers to a DNS resolver
that supports any encrypted DNS scheme.</dd> that supports any encrypted DNS scheme.</dd>
<dt>Split-Horizon DNS</dt><dd>The DNS service provided by a resolver <dt>Split-Horizon DNS:</dt><dd>The DNS service provided by a resolver
that also acts as an authoritative server for some names, providing that also acts as an authoritative server for some names, providing
resolution results that are meaningfully different from those in the resolution results that are meaningfully different from those in the
Global DNS. (See "Split DNS" in <relref section="6" global DNS. (See the definition of "split DNS" in <xref section="6"
target="RFC9499"/>.)</dd> target="RFC9499"/>.)</dd>
<dt>Validated Split-Horizon</dt><dd>A split horizon configuration for <dt>Validated Split Horizon:</dt><dd>Indicates that a split-horizon conf iguration for
some name is considered "validated" if the client has confirmed that some name is considered "validated" if the client has confirmed that
a parent of that name has authorized this resolver to serve its own a parent of that name has authorized this resolver to serve its own
responses for that name. Such authorization generally extends to the responses for that name. Such authorization generally extends to the
entire subtree of names below the authorization point.</dd> entire subtree of names below the authorization point.</dd>
</dl> </dl>
<t>In this document, the terms 'owner' and 'operator' are used interchange ably <t>In this document, the terms "owner" and "operator" are used interchange ably
and refer to the individual or entity responsible for the management and and refer to the individual or entity responsible for the management and
maintenance of domains.</t> maintenance of domains.</t>
</section> </section>
<section> <section>
<name>Scope</name> <name>Scope</name>
<t>The protocol in this document is designed to support the ability of <t>The protocol described in this document is designed to support the abil ity of
a domain owner to create or authorize a split-horizon view of their a domain owner to create or authorize a split-horizon view of their
domain. The protocol does not support split-horizon views created by domain. The protocol does not support split-horizon views created by
any other entity. Thus, DNS filtering is not enabled by this protocol.</t> any other entity. Thus, DNS filtering is not enabled by this protocol.</t>
<t>The protocol is applicable to any type of network offering <t>The protocol is applicable to any type of network offering
split-horizon DNS configuration. The endpoint does not need any prior split-horizon DNS configuration. The endpoint does not need any prior
configuration to confirm that a local domain hint was indeed authorized configuration to confirm that a local domain hint was indeed authorized
by the domain.</t> by the domain.</t>
<t>All of the special-use domain names registered with IANA <xref target=" <t>All of the Special-Use Domain Names registered with IANA <xref target="
RFC6761"/>, RFC6761"/>,
most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and ".local" most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa.", and ".local
, are never ", are never
unique to a specific DNS server's authority. All special-use domain names unique to a specific DNS server's authority. All Special-Use Domain Names
are outside the are outside the
scope of this document and MUST NOT be validated using the mechanism descr scope of this document and <bcp14>MUST NOT</bcp14> be validated using the
ibed in this document. </t> mechanism described in this document. </t>
<t> Use of this specification is limited to DNS servers that support authe <t>The use of this specification is limited to DNS servers that support au
nticated encryption and thenticated encryption and
split-horizon DNS names that are rooted in the global DNS.</t> split-horizon DNS names that are rooted in the global DNS.
<!-- [rfced] Section 3: We see the following:
* RFC 6762 uses '".local."' and '".local"
* RFC 6763 uses '"local."'
* <https://www.iana.org/assignments/special-use-domain-names/> lists
'local.' (per RFC 6762)
* Quite a few subsequent RFCs use '".local"'
Are any clarifications required here, or will '".local"' be clear to
readers as is?
Original:
All of the special-use domain names registered with IANA [RFC6761],
most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and
".local", are never unique to a specific DNS server's authority. -->
</t>
</section> </section>
<section> <section>
<name>Requirements</name> <name>Requirements</name>
<t>This solution seeks to fulfill the following requirements:</t> <t>This solution seeks to fulfill the following requirements:</t>
<ul> <dl newline="false" spacing="normal">
<li>No loss of security: No unauthorized party can impersonate <dt>No loss of security:</dt><dd>No unauthorized party can impersonate
a zone unless they could already do so without use of this a zone unless they could already do so without the use of this
specification.</li> specification.</dd>
<li>Least privilege: Local resolvers do not hold any <dt>Least privilege:</dt><dd>Local resolvers do not hold any
secrets that could weaken the security of the public zone if secrets that could weaken the security of the public zone if
compromised.</li> compromised.</dd>
<li>Local zone confidentiality: The specification does not leak <dt>Local zone confidentiality:</dt><dd>The specification does not leak
local network subdomains to anyone outside of the network.</li> local network subdomains to anyone outside of the network.</dd>
<li>Flexibility: The specification can represent and authorize <dt>Flexibility:</dt><dd>The specification can represent and authorize
a Split DNS zone structure.</li> a split DNS zone structure.</dd>
<li>DNSSEC Compatibility: The specification supports DNSSEC-based <dt>DNSSEC compatibility:</dt><dd>The specification supports DNSSEC-base
<xref target="RFC9364"/> object security for local zone contents.</li> d
</ul> object security for local zone contents per <xref target="RFC9364"/>.<
/dd>
</dl>
</section> </section>
<section anchor="establishing"> <section anchor="establishing">
<name>Establishing Local DNS Authority</name> <name>Establishing Local DNS Authority</name>
<t>A participating network <bcp14>MUST</bcp14> offer one or more <t>A participating network <bcp14>MUST</bcp14> offer one or more
encrypted resolvers via DHCP and Router Advertisement Options for the encrypted resolvers via DHCP and Router Advertisement options for the
Discovery of Network-designated Resolvers (DNR) <xref target="RFC9463"/>, Discovery of Network-designated Resolvers (DNR) <xref target="RFC9463"/>,
Discovery of Designated Resolvers (DDR) <xref target="RFC9462"/>, or an Discovery of Designated Resolvers (DDR) <xref target="RFC9462"/>, or an
equivalent mechanism (see <xref target="vpn"/>).</t> equivalent mechanism (see <xref target="vpn"/>).</t>
<t>To establish local authority, the network MUST convey one or more <t>To establish local authority, the network <bcp14>MUST</bcp14> convey on
"Authorization Claims" to the client. An "Authorization Claim" is an e or more
"authorization claims" to the client. An authorization claim is an
abstract structure comprising:</t> abstract structure comprising:</t>
<ul> <ul>
<li>An Authentication Domain Name (ADN) of a local encrypted resolver.</ li> <li>An Authentication Domain Name (ADN) of a local encrypted resolver.</ li>
<li>The DNS name of the authorizing parent zone.</li> <li>The DNS name of the authorizing parent zone.</li>
<li>A set of subdomains of this parent zone that are claimed by <li>A set of subdomains of this parent zone that are claimed by
the named local resolver (potentially including the entire parent the named local resolver (potentially including the entire parent
zone). To claim the entire parent zone, the claimed subdomain zone). To claim the entire parent zone, the claimed subdomain
will be represented as an asterisk symbol "*".</li> will be represented as an asterisk symbol ("*").</li>
<li>A ZONEMD Hash Algorithm (<relref section="5.3" target="RFC8976"/>). <li>A ZONEMD Hash Algorithm (<xref section="5.3" target="RFC8976"/>).
For interoperability purposes implementations MUST support the For interoperability purposes, implementations <bcp14>MUST</bcp14> su
pport the
"mandatory to implement" hash algorithms defined in "mandatory to implement" hash algorithms defined in
<relref section="2.2.3" target="RFC8976"/>. </li> <xref section="2.2.3" target="RFC8976"/>. </li>
<li>A high-entropy salt, up to 255 octets.</li> <li>A high-entropy salt, up to 255 octets.</li>
</ul> </ul>
<t>If the local encrypted resolver is identified by name (e.g., DNR), that <t>If the local encrypted resolver is identified by name (e.g., DNR), that
identifying name MUST be the one used in any corresponding Authorization identifying name <bcp14>MUST</bcp14> be the name used in any corresponding
Claim. Otherwise (e.g., DDR using IP addresses), the resolver MUST authorization
claim. Otherwise (e.g., DDR using IP addresses), the resolver <bcp14>MUST
</bcp14>
present a validatable certificate containing a subjectAltName that present a validatable certificate containing a subjectAltName that
matches the Authorization Claim using the validation techniques for matches the authorization claim using the validation techniques for
matching as described in <xref target="RFC9525"/>.</t> matching as described in <xref target="RFC9525"/>.</t>
<t>The network then provides each Authorization Claim to the parent zone o perator. <t>The network then provides each authorization claim to the parent zone o perator.
If the contents are approved, the parent zone operator computes a "Verific ation Token" If the contents are approved, the parent zone operator computes a "Verific ation Token"
according to the following procedure:</t> according to the following procedure:</t>
<ol> <ol>
<li>Convert all subdomains into canonical form and sort them in canonica l <li>Convert all subdomains into canonical form and sort them in canonica l
order (<relref section="6" target="RFC4034"/>).</li> order (<xref section="6" target="RFC4034"/>).</li>
<li>Replace the suffix corresponding to the parent zone with a zero <li>Replace the suffix corresponding to the parent zone with a zero
octet.</li> octet.</li>
<li>Let $X be the concatenation of the resulting pseudo-FQDNs.</li> <li>Let $X be the concatenation of the resulting pseudo-FQDNs.</li>
<li>Let len($SALT) be the number of octets of salt, as a single octet.</ li> <li>Let len($SALT) be the number of octets of salt, as a single octet.</ li>
<li>Let $TOKEN = hash(len($SALT) || $SALT || $X). Where "||" denotes con catenation and hash is the ZONEMD Hash Algorithm.</li> <li>Let $TOKEN = hash(len($SALT) || $SALT || $X), where "||" denotes con catenation and hash is the ZONEMD Hash Algorithm.</li>
</ol> </ol>
<t>The zone operator then publishes a "Verification Record" with the <t>The zone operator then publishes a "Verification Record" with the
following structure, following the best practices outlined in Sections 5.1 following structure, following the best practices outlined in
and 5.2 of Sections&nbsp;<xref target="I-D.ietf-dnsop-domain-verification-techniques"
<xref target="I-D.ietf-dnsop-domain-verification-techniques"/>:</t> sectionFormat="bare" section="5.2"/> and <xref target="I-D.ietf-dnsop-domain-ve
<ul> rification-techniques"
<li>Type = TXT.</li> sectionFormat="bare" section="5.3"/> of <xref target="I-D.ietf-dnsop-domain-veri
fication-techniques"/>:
<!-- [rfced] Section 5: We see that
I-D.ietf-dnsop-domain-verification-techniques was restructured
(i.e., the section numbering changed) between versions -04 and -06.
As it appears that "5.1" should now be "5.2" and "5.2" should now be
"5.3", we updated this citation accordingly. Please review this
diff file and let us know if this update is accurate: https://author-tools.ietf.
org/iddiff?url1=draft-ietf-dnsop-domain-verification-techniques-04&url2=draft-ie
tf-dnsop-domain-verification-techniques-06
Original:
The zone operator then publishes a "Verification Record" with the
following structure, following the best practices outlined in
Sections 5.1 and 5.2 of
[I-D.ietf-dnsop-domain-verification-techniques]:
Currently:
The zone operator then publishes a "Verification Record" with the
following structure, following the best practices outlined in
Sections 5.2 and 5.3 of [DOMAIN-VERIFICATION-TECHNIQUES]: -->
</t>
<!-- [rfced] Sections 5 and 5.1: Are the lists with "=" correct as
they are (i.e., tagged as <ul>), or may we update them to use <dl>?
Original:
* Type = TXT.
* Owner Name = Concatenation of the ADN, "_splitdns-challenge", and
the parent zone name.
* Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)"
(without padding)
...
* ADN = "resolver17.parent.example"
* Parent = "parent.example"
* Subdomains = "payroll.parent.example",
"secret.project.parent.example"
* Hash Algorithm = SHA-384 [RFC6234]
* Salt = "example salt octets (should be random)"
Perhaps:
Type: TXT
Owner Name: Concatenation of the ADN, "_splitdns-challenge", and
the parent zone name
Contents: "key/value" pairs, e.g., "token=base64url($TOKEN)"
(without padding)
...
ADN: "resolver17.parent.example"
Parent: "parent.example"
Subdomains: "payroll.parent.example",
"secret.project.parent.example"
Hash Algorithm: SHA-384 [RFC6234]
Salt: "example salt octets (should be random)" -->
<ul>
<li>Type = TXT</li>
<li>Owner Name = Concatenation of the ADN, "_splitdns-challenge", and <li>Owner Name = Concatenation of the ADN, "_splitdns-challenge", and
the parent zone name.</li> the parent zone name</li>
<li>Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (witho ut padding)</li> <li>Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (witho ut padding)</li>
</ul> </ul>
<t>By publishing this record, the parent zone authorizes the local <t>By publishing this record, the parent zone authorizes the local
encrypted resolver to serve these subdomains authoritatively.</t> encrypted resolver to serve these subdomains authoritatively.</t>
<section> <section>
<name>Example</name> <name>Example</name>
<t>Consider the following authorization claim:</t> <t>Consider the following authorization claim:</t>
<ul> <ul>
<li>ADN = "resolver17.parent.example"</li> <li>ADN = "resolver17.parent.example"</li>
<li>Parent = "parent.example"</li> <li>Parent = "parent.example"</li>
<li>Subdomains = "payroll.parent.example", <li>Subdomains = "payroll.parent.example",
"secret.project.parent.example"</li> "secret.project.parent.example"</li>
<li>Hash Algorithm = SHA-384 <xref target="RFC6234"/></li> <li>Hash Algorithm = SHA-384 <xref target="RFC6234"/></li>
<li>Salt = "example salt octets (should be random)"</li> <li>Salt = "example salt octets (should be random)"</li>
<!-- [rfced] Section 5.1: Should the "(should be random)" portion of
this entry be placed outside of the quotes? Please compare with the
"Contents =" entry in Section 5, where "(without padding)" is outside
of the quotes.
Original:
* Salt = "example salt octets (should be random)"
Possibly:
* Salt = "example salt octets" (should be random) -->
</ul> </ul>
<t>To approve this claim, the zone operator would publish the following record:</t> <t>To approve this claim, the zone operator would publish the following record:</t>
<t>NOTE: '\' line wrapping per <xref target="RFC8792"/></t> <t>NOTE: '\' line wrapping per <xref target="RFC8792"/></t>
<!-- [rfced] Section 5.1: We see the following note just before the
sourcecode in this section:
NOTE: '\' line wrapping per [RFC8792]
We also see that the sourcecode in Section 7 also seems to implement
line wrapping but does not include the note. Should this note also
appear before the sourcecode in Section 7?
Two alternatives for you to consider:
1. Place the note inside of the sourcecode, per (for example)
rfc9645.xml (https://www.rfc-editor.org/info/rfc9645).
2. Remove the note and add text to the Terminology section explaining
the convention for line wrapping, as follows:
Lone lines in examples are wrapped using a single backslash ("\")
per [RFC8792]. -->
<sourcecode type="dns-rr"> <sourcecode type="dns-rr">
resolver17.parent.example._splitdns-challenge.parent.example. \ resolver17.parent.example._splitdns-challenge.parent.example. \
IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\ IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
-KJDv2eFwfJcWQM" -KJDv2eFwfJcWQM"
</sourcecode> </sourcecode>
</section> </section>
<section> <section>
<name>Conveying Authorization Claims</name> <name>Conveying Authorization Claims</name>
<t> <t>
The Authorization Claim is an abstract structure that must be encoded in The authorization claim is an abstract structure that must be encoded in
some concrete syntax in order to convey it from the network to the cli ent. some concrete syntax in order to convey it from the network to the cli ent.
This section defines some encodings of the Authorization Claims. This section defines some encodings of the authorization claims.
</t> </t>
<section> <section>
<name>Using DHCP</name> <name>Using DHCP</name>
<t> <t>
In DHCP, each Authorization Claim is encoded as a DHCP Authenticatio
n In DHCP, each authorization claim is encoded as a DHCP Authenticatio
Option (<xref target="RFC3118"/> and <relref section="21.11" target= n
"RFC8415"/>), option (<xref target="RFC3118"/> and <xref section="21.11" target="R
using the Protocol value $TBD1, "Split DNS Authentication". In DHCPv FC8415"/>),
4 <xref target="RFC2131"/>, the long-options using the Protocol value 4, "Split-horizon DNS". In DHCPv4 <xref tar
mechanism described in <relref section="8" target="RFC3396"/> MUST b get="RFC2131"/>, the mechanism for splitting long options as
e used if the described in <xref section="8" target="RFC3396"/> <bcp14>MUST</bcp14
authentication option exceeds the maximum DHCPv4 option size of 255 > be used if the
octets. The Algorithm field Authentication option exceeds the maximum DHCPv4 option size of 255
octets. The Algorithm field
provides the ZONEMD Hash Algorithm, represented by its registered Va lue. provides the ZONEMD Hash Algorithm, represented by its registered Va lue.
The Replay Detection Method value <bcp14>MUST</bcp14> be 0x00. The A uthentication Information The Replay Detection Method value <bcp14>MUST</bcp14> be 0x00. The A uthentication Information
<bcp14>MUST</bcp14> contain the following information, concatenated: </t> <bcp14>MUST</bcp14> contain the following information, concatenated: </t>
<ol> <ol>
<li>The ADN in canonical form.</li> <li>The ADN in canonical form.</li>
<li>The parent name in canonical form.</li> <li>The parent name in canonical form.</li>
<li>A one-octet "salt length" field.</li> <li>A one-octet "salt length" field.</li>
<li>The salt value.</li> <li>The salt value.</li>
<li>The $X value defined in <xref target="establishing"/>.</li> <li>The $X value as defined in <xref target="establishing"/>.</li>
</ol> </ol>
</section> </section>
<section anchor="splitclaims"> <section anchor="splitclaims">
<name>Using Provisioning Domains</name> <name>Using Provisioning Domains</name>
<t>When using <xref target="RFC8801">Provisioning Domains</xref>, the <t>When using <xref target="RFC8801">PvDs</xref>, the
Authorization Claims are represented by the PvD Additional authorization claims are represented by the PvD Additional
Information key "splitDnsClaims", whose value is a Information key "splitDnsClaims", whose value is a
JSON Array. Each entry in the array <bcp14>MUST</bcp14> be a JSON obj ect JSON array. Each entry in the array <bcp14>MUST</bcp14> be a JSON obj ect
with the following structure:</t> with the following structure:</t>
<ul> <dl newline="false" spacing="normal">
<li>"resolver": The ADN as a dot-separated name.</li> <dt>"resolver":</dt><dd>The ADN as a dot-separated name.</dd>
<li>"parent": The parent zone name as a dot-separated name.</li> <dt>"parent":</dt><dd>The parent zone name as a dot-separated name.<
<li>"subdomains": An array containing the claimed subdomains, as /dd>
<dt>"subdomains":</dt><dd>An array containing the claimed subdomains
, as
dot-separated names with the parent suffix already removed, in dot-separated names with the parent suffix already removed, in
canonical order. To claim the entire parent zone, the claimed su bdomain canonical order. To claim the entire parent zone, the claimed su bdomain
will be represented as an asterisk symbol "*".</li> will be represented as an asterisk symbol ("*").</dd>
<li>"algorithm": The hash algorithm is represented by its "Mnemonic" <dt>"algorithm":</dt><dd>The hash algorithm, represented by its "Mne
string from the ZONEMD Hash Algorithms registry (<relref target= monic"
"RFC8976" string from the "ZONEMD Hash Algorithms" registry (<xref target=
section="5.2" displayFormat="comma"/>).</li> "RFC8976"
<li>"salt": The salt, encoded in base64url <xref target="RFC4648"/>. section="5.3" sectionFormat="of"/>).
</li>
</ul> <!-- [rfced] Section 5.2.2: There appeared to be a conflict between
the following text in this section and some text in Section 12 (which
mentions "Section 5.2" in the context of the "ZONEMD Schemes"
registry). As it appears that in this section (5.2.2), "Section 5.2"
should be "Section 5.3" per the fourth bullet in Section 5, we
updated the citation in this section accordingly. If this is
incorrect, please provide text that resolves the conflicting
information.
(Section 5.2 of RFC 8976 has the title "ZONEMD Scheme" and defines
the "ZONEMD Schemes" registry; Section 5.3 of RFC 8976 has the title
"ZONEMD Hash Algorithms" and defines the "ZONEMD Hash Algorithms"
registry.)
Original:
* "algorithm": The hash algorithm is represented by its "Mnemonic"
string from the ZONEMD Hash Algorithms registry ([RFC8976],
Section 5.2).
...
Algorithm Agility (see [RFC7696]) is achieved by providing
implementations with flexibility to choose hashing algorithms from
the ZONEMD Schemes registry ([RFC8976], Section 5.2).
Currently:
"algorithm": The hash algorithm, represented by its "Mnemonic"
string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of
[RFC8976]). -->
</dd>
<dt>"salt":</dt><dd>The salt, encoded in base64url <xref target="RFC
4648"/>.</dd>
</dl>
<t>Future specifications aiming to define new keys will need to add them to the <t>Future specifications aiming to define new keys will need to add them to the
IANA registry defined in <xref target="IANA"/>. DNS client implementatio IANA registry defined in <xref target="new-split-claims-registry"/>. DNS
ns client implementations
will ignore any keys they don't recognize but may also report about will ignore any keys they don't recognize but may also report
unknown keys.</t> unknown keys.
<!-- [rfced] Section 5.2.2: Four registries are discussed in
Section 13, one of which is the new registry defined in Section 13.3.
Because Section 13.3 cites this section and this section defines the
parameters listed in Section 13.3, we clarified the citation in this
sentence accordingly. Please let us know any objections.
Original:
Future specifications aiming to define new keys will need to add them
to the IANA registry defined in Section 13.
Currently:
Future specifications aiming to define new keys will need to add them
to the IANA registry defined in Section 13.3. -->
</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="validating"> <section anchor="validating">
<name>Validating Authority over Local Domain Hints</name> <name>Validating Authority over Local Domain Hints</name>
<t>To validate an Authorization Claim provided by the network, DNS clients <t>To validate an authorization claim provided by the network, DNS clients
<bcp14>MUST</bcp14> resolve the Verification Record for that name. <bcp14>MUST</bcp14> resolve the Verification Record for that name.
If the resolution produces an RRSet containing the expected token for this If the resolution produces an RRset containing the expected token for this
Claim, the client <bcp14>SHALL</bcp14> regard the named resolver as claim, the client <bcp14>SHALL</bcp14> regard the named resolver as
authoritative for the claimed subdomains. Clients <bcp14>MUST</bcp14> igno re authoritative for the claimed subdomains. Clients <bcp14>MUST</bcp14> igno re
any unrecognized keys in the Verification Record.</t> any unrecognized keys in the Verification Record.</t>
<t>Each validation of authority applies only to a specific ADN. <t>Each validation of authority applies only to a specific ADN.
If a network offers multiple encrypted resolvers, each claimed If a network offers multiple encrypted resolvers, each claimed
subdomain may be authorized for a distinct subset of the network-provided subdomain may be authorized for a distinct subset of the network-provided
resolvers.</t> resolvers.</t>
<t>A zone is termed a "Validated Split-Horizon zone" after successful <t>A zone is termed a "Validated Split-Horizon zone" after successful
validation using a "tamperproof" DNS resolution method, i.e., a method validation using a "tamperproof" DNS resolution method, i.e., a method
that is not subject to interference by the local network operator. Two that is not subject to interference by the local network operator. Two
possible tamperproof resolution methods are presented below.</t> possible tamperproof resolution methods are presented below.</t>
<section anchor="validating-external"> <section anchor="validating-external">
<name>Using a Pre-configured External Resolver</name> <name>Using a Preconfigured External Resolver</name>
<t>This method applies only if the client is already configured with <t>This method applies only if the client is already configured with
a default resolution strategy that sends queries to a resolver outside a default resolution strategy that sends queries to a resolver outside
of the network over a encrypted transport. That resolution strategy is of the network over an encrypted transport. That resolution strategy is
considered "tamperproof" because any actor who could modify the considered tamperproof because any actor who could modify the
response could already modify all of the user's other DNS responses. response could already modify all of the user's other DNS responses.
If the client cannot obtain a response from the external resolver within a If the client cannot obtain a response from the external resolver within a
reasonable timeout period, it MUST consider the verification process reasonable timeout period, it <bcp14>MUST</bcp14> consider the verificat ion process
to have failed.</t> to have failed.</t>
<t>To ensure that this assumption holds, clients <bcp14>MUST NOT</bcp14> <t>To ensure that this assumption holds, clients <bcp14>MUST NOT</bcp14>
relax the acceptance rules they would otherwise apply when using this relax the acceptance rules they would otherwise apply when using this
resolver. For example, if the client would check the Authenticated Data (AD) resolver. For example, if the client would check the Authenticated Data (AD)
bit or validate RRSIGs locally when using this resolver, it must also do so bit or validate RRSIGs locally when using this resolver, it must also do so
when resolving TXT records for this purpose. Alternatively, a client mig ht when resolving TXT records for this purpose. Alternatively, a client mig ht
perform DNSSEC validation for the verification query perform DNSSEC validation for the verification query
even if it has disabled DNSSEC validation for other DNS queries.</t> even if it has disabled DNSSEC validation for other DNS queries.</t>
</section> </section>
<!-- validating-external -->
<section anchor="validating-dnssec"> <section anchor="validating-dnssec">
<name>Using DNSSEC</name> <name>Using DNSSEC</name>
<t>The client resolves the Verification Record using any resolution meth od of <t>The client resolves the Verification Record using any resolution meth od of
its choice (e.g., querying one of the network-provided resolvers, its choice (e.g., querying one of the network-provided resolvers,
performing iterative resolution locally), and performs full DNSSEC performing iterative resolution locally) and performs full DNSSEC
validation locally <xref target="RFC6698"/>. The result is validation locally <xref target="RFC6698"/>. The result is
processed based on its DNSSEC validation state (<relref section="4.3" processed based on its DNSSEC validation state (<xref section="4.3"
target="RFC4035" displayFormat="comma"/>): </t> target="RFC4035" sectionFormat="of"/>): </t>
<ul empty="true">
<li><strong>Secure</strong>: The response is used for validation.</li> <dl newline="false" spacing="normal">
<li><strong>Bogus</strong> or <strong>Indeterminate</strong>: The resp <dt><strong>Secure</strong>:</dt><dd>The response is used for validati
onse is rejected and on.</dd>
validation is considered to have failed.</li> <dt><strong>Bogus</strong> or <strong>Indeterminate</strong>:</dt><dd>
<li><strong>Insecure</strong>: The client <bcp14>SHOULD</bcp14> retry The response is rejected, and
the validation validation is considered to have failed.</dd>
process using a different method, such as the one in <xref <dt><strong>Insecure</strong>:</dt><dd>The client <bcp14>SHOULD</bcp14
> retry the validation
process using a different method, such as the method described in <x
ref
target="validating-external"/>, to ensure compatibility with target="validating-external"/>, to ensure compatibility with
unsigned names. If the client chooses not to retry (e.g., no configu red policy to validate unsigned names. If the client chooses not to retry (e.g., no configu red policy to validate
the authorization claim using an external resolver), it MUST conside the authorization claim using an external resolver), it <bcp14>MUST<
r /bcp14> consider
validation to have failed.</li> validation to have failed.</dd>
</ul> </dl>
</section> </section>
<!-- validating-DNSSEC -->
</section> </section>
<!-- Validating -->
<section> <section>
<name>Delegating DNSSEC across Split DNS Boundaries</name> <name>Delegating DNSSEC Across Split DNS Boundaries</name>
<t>When the local zone can be signed with globally trusted keys for the pa rent <t>When the local zone can be signed with globally trusted keys for the pa rent
zone, support for DNSSEC can be accomplished simply by placing a zone cut at zone, support for DNSSEC can be accomplished simply by placing a zone cut at
the parent zone and including a suitable DS record for the local resolver' s the parent zone and including a suitable DS record for the local resolver' s
DNSKEY. Zones in this configuration appear the same to validating stubs w hether DNSKEY. Zones in this configuration appear the same to validating stubs w hether
or not they implement this specification.</t> or not they implement this specification.
<!-- [rfced] Section 7: Does "can be accomplished simply by placing"
mean "can be accomplished easily by placing", "can be accomplished by
simply placing", or something else?
Original:
When the local zone can be signed with globally trusted keys for the
parent zone, support for DNSSEC can be accomplished simply by placing
a zone cut at the parent zone and including a suitable DS record for
the local resolver's DNSKEY. -->
</t>
<t>To enable DNSSEC validation of local DNS names without requiring <t>To enable DNSSEC validation of local DNS names without requiring
the local resolver to hold DNSSEC private keys that are valid for the pare nt the local resolver to hold DNSSEC private keys that are valid for the pare nt
zone, parent zones <bcp14>MAY</bcp14> add a "ds=..." key to the Verificati on zone, parent zones <bcp14>MAY</bcp14> add a "ds=..." key to the Verificati on
Record whose value is the RDATA of a single DS record, base64url-encoded. Record whose value is the RDATA of a single DS record, encoded in base64ur
This l. This
DS record authorizes a DNSKEY whose Owner Name is "resolver.arpa."</t> DS record authorizes a DNSKEY whose owner name is "resolver.arpa."</t>
<t>To validate DNSSEC, the client first fetches and validates the Verifica tion <t>To validate DNSSEC, the client first fetches and validates the Verifica tion
Record. If it is valid and contains a "ds" key, the client <bcp14>MAY</bc p14> Record. If it is valid and contains a "ds" key, the client <bcp14>MAY</bc p14>
send a DNSKEY query for "resolver.arpa." to the local encrypted resolver. send a DNSKEY query for "resolver.arpa." to the local encrypted resolver.
At least one resulting DNSKEY RR <bcp14>MUST</bcp14> match the DS RDATA fr om At least one resulting DNSKEY Resource Record (RR) <bcp14>MUST</bcp14> mat ch the DS RDATA from
the "ds" key in the Verification Record. All local resolution results for the "ds" key in the Verification Record. All local resolution results for
subdomains in this claim <bcp14>MUST</bcp14> offer RRSIGs that chain to a subdomains in this claim <bcp14>MUST</bcp14> offer RRSIGs that chain to a
DNSKEY whose RDATA is identical to one of these approved DNSKEYs.</t> DNSKEY whose RDATA is identical to one of these approved DNSKEYs.
<!-- [rfced] Section 7: As it appears that "RR" in this sentence
stands for "Resource Record" and "Resource Record" is not marked
well known on
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list>, we
expanded it here for ease of the reader. If this expansion is
incorrect, please provide the correct definition.
Original:
At least one resulting DNSKEY RR MUST match the
DS RDATA from the "ds" key in the Verification Record.
Currently:
At least one resulting DNSKEY Resource Record
(RR) MUST match the DS RDATA from the "ds" key in the Verification
Record. -->
</t>
<t>The "ds" key <bcp14>MAY</bcp14> appear multiple <t>The "ds" key <bcp14>MAY</bcp14> appear multiple
times in a single Verification Record, in order to authorize multiple DNSK EYs times in a single Verification Record, in order to authorize multiple DNSK EYs
for this local encrypted resolver. If the "ds" key is not present in a va lid for this local encrypted resolver. If the "ds" key is not present in a va lid
Verification Record, the client <bcp14>MUST</bcp14> disable DNSSEC validat ion Verification Record, the client <bcp14>MUST</bcp14> disable DNSSEC validat ion
when resolving the claimed subdomains via this local encrypted resolver.</ t> when resolving the claimed subdomains via this local encrypted resolver.</ t>
<t>Note that in this configuration, any claimed subdomains MUST be marked as <t>Note that in this configuration, any claimed subdomains <bcp14>MUST</bc p14> be marked as
unsigned in the public DNS. Otherwise, resolution results would be reject ed unsigned in the public DNS. Otherwise, resolution results would be reject ed
by validating stubs that do not implement this specification.</t> by validating stubs that do not implement this specification.</t>
<figure> <figure>
<name>Example use of "ds=..."</name> <name>Example Use of "ds=..."</name>
<!-- [rfced] Section 7: Please review whether the "type" attribute
should be set for the following sourcecode element in the XML file.
(Other sourcecode elements have the "type" attribute set.)
Original:
<sourcecode>
;; Parent zone.
...
If the current list of preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, please let us know. Also, it is
acceptable to leave the "type" attribute unset. -->
<sourcecode> <sourcecode>
;; Parent zone. ;; Parent zone.
$ORIGIN parent.example. $ORIGIN parent.example.
; Parent zone's public KSK and ZSK ; Parent zone's public Key Signing Key (KSK)
; and Zone Signing Key (ZSK).
@ IN DNSKEY 257 3 5 ABCD...= @ IN DNSKEY 257 3 5 ABCD...=
@ IN DNSKEY 256 3 5 DCBA...= @ IN DNSKEY 256 3 5 DCBA...=
; Verification Record containing DS RDATA for the local ; Verification Record containing DS RDATA for the local
; resolver's KSK. This is an ordinary public TXT record, ; resolver's KSK. This is an ordinary public TXT record,
; secured by RRSIGs from the public ZSK. ; secured by RRSIGs from the public ZSK.
resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..." resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..."
; NSEC record indicating that unsigned delegations are permitted at ; NSEC record indicating that unsigned delegations are permitted at
; this subdomain. This is required for compatibility with non-split-aware ; this subdomain. This is required for compatibility with
; validating stub resolvers. If the claimed label is confidential, the ; non-split-aware validating stub resolvers. If the claimed label is
; parent zone can conceal it using NSEC3 (with or without "opt-out"). ; confidential, the parent zone can conceal it using NSEC3 (with or
; without "opt-out").
@ IN NSEC subdomain.parent.example. NS @ IN NSEC subdomain.parent.example. NS
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Local zone, claiming "subdomain.parent.example". ;; Local zone, claiming "subdomain.parent.example".
; The local resolver's KSK, validated by the Verification Record. ; The local resolver's KSK, validated by the Verification Record.
; It may not have a corresponding RRSIG. ; It may not have a corresponding RRSIG.
resolver.arpa. IN DNSKEY 257 3 5 ASDF...= resolver.arpa. IN DNSKEY 257 3 5 ASDF...=
skipping to change at line 470 skipping to change at line 679
subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...= subdomain.parent.example. IN DNSKEY 256 3 5 FDSA...=
subdomain.parent.example IN RRSIG DNSKEY 5 3 ... \ subdomain.parent.example IN RRSIG DNSKEY 5 3 ... \
(KSK key tag) subdomain.parent.example. ... (KSK key tag) subdomain.parent.example. ...
subdomain.parent.example. IN AAAA 2001:db8::17 subdomain.parent.example. IN AAAA 2001:db8::17
subdomain.parent.example IN RRSIG AAAA 5 3 ... \ subdomain.parent.example IN RRSIG AAAA 5 3 ... \
(ZSK key tag) subdomain.parent.example. ... (ZSK key tag) subdomain.parent.example. ...
deeper.subdomain.parent.example. IN AAAA 2001:db8::18 deeper.subdomain.parent.example. IN AAAA 2001:db8::18
deeper.subdomain.parent.example IN RRSIG AAAA 5 3 ... \ deeper.subdomain.parent.example IN RRSIG AAAA 5 3 ... \
(ZSK key tag) subdomain.parent.example. ... (ZSK key tag) subdomain.parent.example. ...
</sourcecode></figure> </sourcecode></figure>
<!-- [rfced] Section 7: The second and third lines of this
sourcecode were too long for the text output. We adjusted as
follows. Please review, and let us know any concerns.
Original:
; NSEC record indicating that unsigned delegations are permitted at
; this subdomain. This is required for compatibility with non-split-aware
; validating stub resolvers. If the claimed label is confidential, the
; parent zone can conceal it using NSEC3 (with or without "opt-out").
Currently:
; NSEC record indicating that unsigned delegations are permitted at
; this subdomain. This is required for compatibility with
; non-split-aware validating stub resolvers. If the claimed label is
; confidential, the parent zone can conceal it using NSEC3 (with or
; without "opt-out"). -->
</section> </section>
<section> <section>
<name>Examples of Split-Horizon DNS Configuration</name> <name>Examples of Split-Horizon DNS Configuration</name>
<!-- [rfced] It appears that <tt>s might be inconsistently applied in
this document. Some of the example URLs are enclosed in <tt>, while
others are not or are enclosed in quotation marks instead. Please
review the lists below, and let us know if any updates are needed.
Terms enclosed with <tt>:
dns.example.net
*.example.com
example.com
*.internal.example.com
internal.example.com
pvd.example.com
www.example.com
Similar terms without <tt>:
"example.com"
pvd.example.com
internal.example.com
"internal.example.com"
"ns1.internal.example.com"
"private1.internal.example.com"
"private2.internal.example.com"
"*.internal.example.com" -->
<t>Two examples are shown below. The first example shows a company <t>Two examples are shown below. The first example shows a company
with an internal-only DNS server that claims the entire zone for that with an internal-only DNS server that claims the entire zone for that
company (e.g., <tt>*.example.com</tt>). In the second example, the company (e.g., <tt>*.example.com</tt>). In the second example, the
internal servers resolves only a internal server resolves only a
subdomain of the company's zone (e.g., <tt>*.internal.example.com</tt>).</ subdomain of the company's zone (e.g., <tt>*.internal.example.com</tt>).
t>
<!-- [rfced] Section 8: We could not determine which example is the
second of the two examples in this section. Do Sections 8.1, 8.1.1,
and 8.1.2 show three examples, rather than two? Section 8.1 seems
straightforward, but Sections 8.1.1 and 8.1.2 are confusing in that
they seem to show two additional examples. Please review and clarify.
Original:
Two examples are shown below. The first example shows a company with
an internal-only DNS server that claims the entire zone for that
company (e.g., *.example.com). In the second example, the internal
servers resolves only a subdomain of the company's zone (e.g.,
*.internal.example.com).
8.1. Split-Horizon Entire Zone
...
8.1.1. Verification Using an External Resolver
...
Figure 3: Verifying claims using an external resolver
...
8.1.2. Verification using DNSSEC
...
Figure 4: An Example of Verifying Claims using DNSSEC -->
</t>
<section anchor="internal-only"> <section anchor="internal-only">
<name>Split-Horizon Entire Zone</name> <name>Split-Horizon Entire Zone</name>
<t>Consider an organization that operates "example.com", and runs a <t>Consider an organization that operates "example.com" and runs a
different version of its global domain on its internal network.</t> different version of its global domain on its internal network.</t>
<t>First, the host and network both need to support one of the discovery <t>First, the host and network both need to support one of the discovery
mechanisms described in <xref target="establishing"/>. <xref target="fig -learn"/> mechanisms described in <xref target="establishing"/>. <xref target="fig -learn"/>
shows discovery using DNR and PvD.</t> shows discovery using DNR and PvD information.</t>
<t>Validation is then perfomed using either <xref <t>Validation is then performed using either <xref
target="example-verify-external">an external resolver</xref> or <xref target="example-verify-external">an external resolver</xref> or <xref
target="example-verify-dnssec">DNSSEC</xref>.</t> target="example-verify-dnssec">DNSSEC</xref>.</t>
<ul empty="true">
<li><strong>Steps 1-2</strong>: The client determines the network's DN <dl newline="false" spacing="normal">
S <dt><strong>Steps 1-2</strong>:</dt><dd>The client determines the netw
server (dns.example.net) and Provisioning Domain (pvd.example.com) ork's DNS
server (dns.example.net) and PvD information (pvd.example.com)
using <xref target="RFC9463">DNR</xref> and <xref using <xref target="RFC9463">DNR</xref> and <xref
target="RFC8801">PvD</xref>, using one of DNR Router Solicitation, target="RFC8801">PvDs</xref>, using one of the following: DNR Router
DHCPv4, or DHCPv6.</li> Solicitation,
<li><strong>Step 3-5</strong>: The client connects to dns.example.net DHCPv4, or DHCPv6.</dd>
<dt><strong>Steps 3-5</strong>:</dt><dd>The client connects to dns.exa
mple.net
using an encrypted transport as indicated in <xref using an encrypted transport as indicated in <xref
target="RFC9463">DNR</xref>, authenticating the server to target="RFC9463">DNR</xref>, authenticating the server to
its name using TLS (<relref target="RFC8310" section="8" its name using TLS (<xref target="RFC8310" section="8"
displayFormat="comma"/>), and sectionFormat="of"/>), and
sends it a query for the address of <tt>pvd.example.com</tt>.</li> sends it a query for the address of <tt>pvd.example.com</tt>.</dd>
<li><t><strong>Steps 6-7</strong>: The client connects to the PvD serv <dt><strong>Steps 6-7</strong>:</dt><dd><t>The client connects to the
er, PvD server,
validates its certificate, and retrieves the provisioning domain validates its certificate, and retrieves the PvD
JSON information indicated by the associated PvD. The PvD JSON information indicated by the associated PvD. The PvD
contains:</t> contains:</t>
<sourcecode type="json">{ <sourcecode type="json">{
"identifier": "pvd.example.com", "identifier": "pvd.example.com",
"expires": "2025-05-23T06:00:00Z", "expires": "2025-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"splitDnsClaims": [{ "splitDnsClaims": [{
"resolver": "dns.example.net", "resolver": "dns.example.net",
"parent": "example.com", "parent": "example.com",
"subdomains": ["*"], "subdomains": ["*"],
"algorithm": "SHA384", "algorithm": "SHA384",
"salt": "abc...123" "salt": "abc...123"
}] }]
}</sourcecode> }</sourcecode>
<t>The JSON keys "identifier", "expires", and "prefixes" <t>The JSON keys "identifier", "expires", and "prefixes"
are defined in <xref target="RFC8801"/>.</t></li> are defined in <xref target="RFC8801"/>.</t></dd>
</ul> </dl>
<figure anchor="fig-learn"> <figure anchor="fig-learn">
<name>An Example of Learning Local Claims of DNS Authority</name> <name>An Example of Learning Local Claims of DNS Authority</name>
<artwork><![CDATA[ <artwork><![CDATA[
+---------+ +--------------------+ +------------+ +--------+ +---------+ +--------------------+ +------------+ +--------+
| Client | | Network's | | Network | | Router | | Client | | Network's | | Network | | Router |
| | | Encrypted Resolver | | PvD Server | | | | | | Encrypted Resolver | | PvD Server | | |
+---------+ +--------------------+ +------------+ +--------+ +---------+ +--------------------+ +------------+ +--------+
| | | | | | | |
| Router Solicitation or | | | | Router Solicitation or | | |
| DHCPv4/DHCPv6 (1) | | | | DHCPv4/DHCPv6 (1) | | |
skipping to change at line 562 skipping to change at line 840
| https://pvd.example.com/.well-known/pvd (6) | | | https://pvd.example.com/.well-known/pvd (6) | |
|---------------------------------------------->| | |---------------------------------------------->| |
| | | | | | | |
| 200 OK (JSON Additional Information) (7) | | | 200 OK (JSON Additional Information) (7) | |
|<----------------------------------------------| | |<----------------------------------------------| |
| ----------------------------------\ | | | | ----------------------------------\ | | |
|-| {..., "splitDnsClaims": [...] } | | | | |-| {..., "splitDnsClaims": [...] } | | | |
| |---------------------------------/ | | | | |---------------------------------/ | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- [rfced] Figures 2 and 3: Would you like spacing between the
step descriptions and the step numbers to be consistent? For
example:
Original:
...
resolve pvd.example.com (4)
A or AAAA records (5)
...
_splitdns-challenge.example.com (1)
TXT "token=ABC..." (2)
resolving example.com (3)
...
Possibly:
...
resolve pvd.example.com (4)
A or AAAA records (5)
...
_splitdns-challenge.example.com (1)
TXT "token=ABC..." (2)
resolving example.com (3)
... -->
<section anchor="example-verify-external"> <section anchor="example-verify-external">
<name>Verification Using an External Resolver</name> <name>Verification Using an External Resolver</name>
<t><xref target="fig-learn2"/> shows the steps performed to verify the local <t><xref target="fig-learn2"/> shows the steps performed to verify the local
claims of DNS authority using an external resolver.</t> claims of DNS authority using an external resolver.</t>
<ul empty="true">
<li><strong>Steps 1-2</strong>: The client uses an encrypted DNS <dl newline="false" spacing="normal">
<dt><strong>Steps 1-2</strong>:</dt><dd>The client uses an encrypted
DNS
connection to an external resolver to issue TXT connection to an external resolver to issue TXT
queries for the Verification Records. The TXT lookup returns queries for the Verification Records. The TXT lookup returns
a token that matches the claim.</li> a token that matches the claim.</dd>
<li><strong>Step 3</strong>: The client has validated that <dt><strong>Step 3</strong>:</dt><dd>The client has validated that
<tt>example.com</tt> has authorized <tt>dns.example.net</tt> <tt>example.com</tt> has authorized <tt>dns.example.net</tt>
to serve <tt>example.com</tt>. When the client connects using an to serve <tt>example.com</tt>. When the client connects using an
encrypted transport as indicated in <xref encrypted transport as indicated in <xref
target="RFC9463">DNR</xref>, it will authenticate target="RFC9463">DNR</xref>, it will authenticate
the server to its name using TLS (<relref target="RFC8310" the server to its name using TLS (<xref target="RFC8310"
section="8" displayFormat="comma"/>), and send queries to resolve section="8" sectionFormat="of"/>) and send queries to resolve
any names that fall within the claimed zones.</li> any names that fall within the claimed zones.</dd>
</ul> </dl>
<figure anchor="fig-learn2"> <figure anchor="fig-learn2">
<name>Verifying claims using an external resolver</name> <name>Verifying Claims Using an External Resolver</name>
<artwork><![CDATA[ <artwork><![CDATA[
+---------+ +--------------------+ +----------+ +---------+ +--------------------+ +----------+
| Client | | Network's | | External | | Client | | Network's | | External |
| | | Encrypted Resolver | | Resolver | | | | Encrypted Resolver | | Resolver |
+---------+ +--------------------+ +----------+ +---------+ +--------------------+ +----------+
| | | | | |
| TLS connection | | | TLS connection | |
|--------------------------------------------------->| |--------------------------------------------------->|
| ---------------------------\ | | | ---------------------------\ | |
|-| validate TLS certificate | | | |-| validate TLS certificate | | |
skipping to change at line 613 skipping to change at line 917
|-| finished validation | | | |-| finished validation | | |
| |---------------------| | | | |---------------------| | |
| | | | | |
| use dns.example.net when | | | use dns.example.net when | |
| resolving example.com (3) | | | resolving example.com (3) | |
|----------------------------------------->| | |----------------------------------------->| |
| | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<!-- external -->
<section anchor="example-verify-dnssec"> <section anchor="example-verify-dnssec">
<name>Verification using DNSSEC</name> <name>Verification Using DNSSEC</name>
<t><xref target="fig-learn3"/> shows the steps performed to verify the local <t><xref target="fig-learn3"/> shows the steps performed to verify the local
claims of DNS authority using DNSSEC.</t> claims of DNS authority using DNSSEC.</t>
<ul empty="true">
<li><strong>Steps 1-2</strong>: The DNSSEC-validating client queries <dl newline="false" spacing="normal">
the network encrypted resolver to issue TXT queries for the <dt><strong>Steps 1-2</strong>:</dt><dd>The DNSSEC-validating client
queries
the network's encrypted resolver to issue TXT queries for the
Verification Records. The TXT lookup will return Verification Records. The TXT lookup will return
a signed response containing the expected token. The client then a signed response containing the expected token. The client then
performs full DNSSEC validation locally.</li> performs full DNSSEC validation locally.</dd>
<li><strong>Step 3</strong>: If the DNSSEC validation is successful <dt><strong>Step 3</strong>:</dt><dd>If the DNSSEC validation is suc
and cessful and
the token matches, then this Authorization Claim is validated. the token matches, then this authorization claim is validated.
Once the client connects using an encrypted transport as indicated Once the client connects using an encrypted transport as indicated
in <xref target="RFC9463">DNR</xref>, it will authenticate in <xref target="RFC9463">DNR</xref>, it will authenticate
the server to its name using TLS (<relref target="RFC8310" the server to its name using TLS (<xref target="RFC8310"
section="8" displayFormat="comma"/>), and send queries to resolve section="8" sectionFormat="of"/>) and send queries to resolve
any names that fall within the claimed zones.</li> any names that fall within the claimed zones.</dd>
</ul> </dl>
<figure anchor="fig-learn3"> <figure anchor="fig-learn3">
<name>An Example of Verifying Claims using DNSSEC</name> <name>An Example of Verifying Claims Using DNSSEC</name>
<artwork><![CDATA[ <artwork><![CDATA[
+---------+ +--------------------+ +---------+ +--------------------+
| Client | | Network's | | Client | | Network's |
| | | Encrypted Resolver | | | | Encrypted Resolver |
+---------+ +--------------------+ +---------+ +--------------------+
| | | |
| DNSSEC OK (DO), TXT? dns.example.net.\ | | DNSSEC OK (DO), TXT? dns.example.net.\ |
| _splitdns-challenge.example.com (1) | | _splitdns-challenge.example.com (1) |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| | | |
skipping to change at line 669 skipping to change at line 972
| | | |
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="operatonal"> <section anchor="operatonal">
<name>Operational Efficiency in Split-Horizon Deployments</name> <name>Operational Efficiency in Split-Horizon Deployments</name>
<t>In many split-horizon deployments, all non-public domain names are <t>In many split-horizon deployments, all non-public domain names are
placed in a separate child zone (e.g., <tt>internal.example.com</tt>). placed in a separate child zone (e.g., <tt>internal.example.com</tt>).
In this configuration, the message flow is similar to <xref In this configuration, the message flow is similar to the flow described in <xref
target="internal-only"/>, except that queries for hosts not within the target="internal-only"/>, except that queries for hosts not within the
subdomain (e.g., <tt>www.example.com</tt>) are sent to the subdomain (e.g., <tt>www.example.com</tt>) are sent to the
external resolver rather than the resolver for internal.example.com.</t> external resolver rather than the resolver for internal.example.com.</t>
<t>As in <xref target="internal-only"/>, the internal DNS <t>As specified in <xref target="internal-only"/>, the internal DNS
server will need a certificate signed by a Certification Authority (CA) trusted by the server will need a certificate signed by a Certification Authority (CA) trusted by the
client.</t> client.</t>
<t>Although placing internal domains inside a child domain is unnecessar y to prevent leakage, <t>Although placing internal domains inside a child domain is unnecessar y to prevent leakage,
such placement reduces the frequency of changes to the Verification Reco such placement reduces the frequency of changes to the Verification Reco
rd, this document rd. This document
recommends the internal domains be kept in a child zone of the local dom recommends that the internal domains be kept in a child zone of the loca
ain hints l domain hints
advertised by the network. For example, if the PvD "dnsZones" entry is advertised by the network. For example, if the PvD "dnsZones" entry is
"internal.example.com" and the network-provided DNS resolver is "ns1.int ernal.example.com", "internal.example.com" and the network-provided DNS resolver is "ns1.int ernal.example.com",
the network operator can structure the internal domain names as the network operator can structure the internal domain names as
"private1.internal.example.com", "private2.internal.example.com", "private1.internal.example.com", "private2.internal.example.com",
etc. The network-designated resolver will be used to resolve the subdoma ins of etc. The network-designated resolver will be used to resolve the subdoma ins of
the local domain hint "*.internal.example.com".</t> the local domain hint "*.internal.example.com".</t>
</section> </section>
<section anchor="vpn"> <section anchor="vpn">
<name>Validation with IKEv2</name> <name>Validation with IKEv2</name>
<t>When the endpoint is using a VPN tunnel and the tunnel is IPsec, the en crypted DNS resolver hosted by <t>When the endpoint is using a VPN tunnel and the tunnel is IPsec, the en crypted DNS resolver hosted by
the VPN service provider can be securely discovered by the endpoint the VPN service provider can be securely discovered by the endpoint
using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types
defined in <xref target="RFC9464"/>. The VPN client defined in <xref target="RFC9464"/>. The VPN client
can use the mechanism defined in Section 6 to validate that the discovered can use the mechanism defined in <xref target="validating"/> to validate t
encrypted DNS resolver is authorized to answer for the claimed subdomains. hat the discovered
</t> encrypted DNS resolver is authorized to answer for the claimed subdomains.
<t>Other VPN tunnel types have similar configuration capabilities, not
detailed here.</t> <!-- [rfced] Section 10: We do not see "ENCDNS_IP*_*" or
"ENCDNS_IP*_" in RFC 9464. Will the use of the additional underscore
be clear to readers, or should "ENCDNS_IP*_*" be changed to
"ENCDNS_IP*" per RFC 9464?
Original:
When the endpoint is using a VPN tunnel and the tunnel is IPsec, the
encrypted DNS resolver hosted by the VPN service provider can be
securely discovered by the endpoint using the ENCDNS_IP*_* IKEv2
Configuration Payload Attribute Types defined in [RFC9464]. -->
</t>
<t>Other VPN tunnel types have similar configuration capabilities. Note th
at those
capabilities are not discussed in this document.</t>
</section> </section>
<section anchor="aclaim"> <section anchor="aclaim">
<name>Authorization Claim Update</name> <name>Authorization Claim Update</name>
<t>A verification record is only valid until it expires. Expiry occurs whe n the Time To Live (TTL) <t>A verification record is only valid until it expires. Expiry occurs whe n the Time To Live (TTL)
or DNSSEC signature validity period ends. Shortly before verification reco rd expiry, clients MUST or DNSSEC signature validity period ends. Shortly before verification reco rd expiry, clients <bcp14>MUST</bcp14>
fetch the verification records again and repeat the verification procedure . This ensures the fetch the verification records again and repeat the verification procedure . This ensures the
availability of updated and valid verification records.</t> availability of updated and valid verification records.</t>
<t>A new verification record must be added to the RRset before the corresp <t>A new verification record must be added to the RRset before the corresp
onding Authorization onding authorization
Claim is updated. After the claim is updated, the following procedures ca claim is updated. After the claim is updated, the following procedures ca
n be used:</t> n be used:</t>
<ol> <ol>
<li>DHCP reconfiguration can be initiated by a DHCP server that has prev iously communicated with a DHCP client and <li>DHCP reconfiguration can be initiated by a DHCP server that has prev iously communicated with a DHCP client and
negotiated for the DHCP client to listen for Reconfigure messages, to prompt negotiated for the DHCP client to listen for Reconfigure messages, to prompt
the DHCP clients for the DHCP client to
dynamically requesting the updated Authorization Claim. This process avo dynamically request the updated authorization claim. This process avoids
ids the need for the need for
the client to wait for its current lease to complete and request a new o ne, enabling the lease the client to wait for its current lease to complete and request a new o ne, enabling the lease
renewal to be driven by the DHCP server.</li> renewal to be driven by the DHCP server.
<!-- [rfced] Section 11: As it appears that "to prompt the DHCP
clients for dynamically requesting" means "to prompt the DHCP client
to dynamically request", we updated this sentence accordingly. If
this update is incorrect, please clarify "to prompt ... for ...
requesting".
Original:
1. DHCP reconfiguration can be initiated by a DHCP server that has
previously communicated with a DHCP client and negotiated for the
DHCP client to listen for Reconfigure messages, to prompt the
DHCP clients for dynamically requesting the updated Authorization
Claim.
Currently:
1. DHCP reconfiguration can be initiated by a DHCP server that has
previously communicated with a DHCP client and negotiated for the
DHCP client to listen for Reconfigure messages, to prompt the
DHCP client to dynamically request the updated authorization
claim. -->
</li>
<li>The sequence number in the RA PvD option <li>The sequence number in the RA PvD option
will be incremented, requiring clients to fetch PvD additional informati will be incremented, requiring clients to fetch PvD Additional Informati
on from the HTTPS on from the HTTPS
server due to the updated sequence number in the new RA (<relref target= server due to the updated sequence number in the new RA (<xref target="R
"RFC8801" section="4.1" FC8801" section="4.1"
displayFormat="comma"/>).</li> sectionFormat="of"/>).</li>
<li>The old verification record needs to be maintained until the DHCP le ase time or PvD <li>The old verification record needs to be maintained until the DHCP le ase time or PvD
Additional Information expiry.</li> Additional Information expiry.
<!-- [rfced] Section 11: We had trouble following the meaning of
"until the DHCP lease time or PvD Additional Information expiry".
If the suggested text is not correct, please clarify.
Original:
3. The old verification record needs to be maintained until the DHCP
lease time or PvD Additional Information expiry.
Suggested:
3. The old verification record needs to be maintained until the DHCP
lease time or PvD Additional Information period expires. -->
</li>
</ol> </ol>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Authentication Domain Names of authorized local encrypted resolvers <t>The ADNs of authorized local encrypted resolvers are
are revealed in the owner names of Verification Records. This makes it easier
revealed in the Owner Names of Verification Records. This makes it easier for
for
domain owners to understand which resolvers they are currently authorizing to domain owners to understand which resolvers they are currently authorizing to
implement Split DNS. However, this could create a confidentiality issue if the implement split DNS. However, this could create a confidentiality issue if the
local encrypted resolver's name contains sensitive information or is part of a local encrypted resolver's name contains sensitive information or is part of a
secret subdomain. To mitigate the impact of such leakage, local resolvers should secret subdomain. To mitigate the impact of such leakage, local resolvers should
be given names that do not reveal any sensitive information.</t> be given names that do not reveal any sensitive information.</t>
<t> The security properties of hashing algorithms are not fixed. Algorithm Agility <t> The security properties of hashing algorithms are not fixed. Algorithm agility
(see <xref target="RFC7696"/>) is achieved by providing implementations wi th (see <xref target="RFC7696"/>) is achieved by providing implementations wi th
flexibility to choose hashing algorithms from the ZONEMD Schemes registry the flexibility to choose hashing algorithms from the "ZONEMD Schemes" reg
(<relref target="RFC8976" section="5.2" displayFormat="comma"/>).</t> istry
<t>The entropy of salt depends on a high-quality pseudo-random number gene (<xref target="RFC8976" section="5.2" sectionFormat="of"/>).</t>
rator. <t>The entropy of a salt depends on a high-quality pseudorandom number gen
erator.
For further discussion on random number generation, see <xref target="RFC4 086"/>. For further discussion on random number generation, see <xref target="RFC4 086"/>.
The salt MUST be regenerated whenever the authorization claim is updated.< /t> The salt <bcp14>MUST</bcp14> be regenerated whenever the authorization cla im is updated.</t>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section> <section>
<name>DHCP Split DNS Authentication Algorithm</name> <name>DHCP Split DNS Authentication Algorithm</name>
<t>IANA is requested to add the following entry to the "Protocol Name Sp <t>IANA has added the following entry to the "Protocol Name Space
ace Values" registry in the "Dynamic Host Configuration Protocol (DHCP)
Values" registry on the "Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces" registry group:</t>
Authentication Option Name Spaces" page:</t>
<ul> <dl newline="false" spacing="normal">
<li>Value: $TBD1</li> <dt>Value:</dt><dd>4</dd>
<li>Description: Split-horizon DNS</li> <dt>Description:</dt><dd>Split-horizon DNS</dd>
<li>Reference: (This Document)</li> <dt>Reference:</dt><dd>RFC 9704</dd>
</ul> </dl>
</section> </section>
<section> <section>
<name>Provisioning Domains Split DNS Additional Information</name> <name>Provisioning Domains Split DNS Additional Information</name>
<t>IANA is requested to add the following entry to the "Additional
Information PvD Keys" registry under the "Provisioning Domains (PvDs)" r <!-- [rfced] Section 13.2: This title is difficult to interpret.
egistry group:</t> Does it mean "Provisioning Domains Using Split DNS Additional
<ul> Information", "Provisioning Domains: Split DNS Additional
<li>JSON key: "splitDnsClaims"</li> Information", or something else? Please clarify.
<li>Description: "Verifiable locally served domains"</li>
<li>Type: Array of Objects</li> Original:
<li><t>Example: </t><sourcecode type="json">[{ 13.2. Provisioning Domains Split DNS Additional Information -->
<t>IANA has added the following entry to the "Additional
Information PvD Keys" registry in the "Provisioning Domains (PvDs)" regi
stry group:</t>
<dl newline="false" spacing="normal">
<dt>JSON key:</dt><dd>splitDnsClaims</dd>
<dt>Description:</dt><dd>Verifiable locally served domains</dd>
<dt>Type:</dt><dd>Array of Objects</dd>
<dt>Example:</dt><dd><sourcecode type="json">[{
"resolver": "dns.example.net", "resolver": "dns.example.net",
"parent": "example.com", "parent": "example.com",
"subdomains": ["sub"], "subdomains": ["sub"],
"algorithm": "SHA384", "algorithm": "SHA384",
"salt": "abc...123" "salt": "abc...123"
}]</sourcecode></li> }]</sourcecode></dd>
<li>Reference: (This document)</li> <dt>Reference:</dt><dd>RFC 9704</dd>
</ul> </dl>
</section> </section>
<section> <section anchor="new-split-claims-registry">
<name>New PvD Split DNS Claims Registry</name> <name>New PvD Split DNS Claims Registry</name>
<t>IANA is requested to create a new registry "PvD Split DNS Claims" Reg <t>IANA has created a new registry called "PvD Split DNS Claims"
istry, within the "Provisioning Domains (PvDs)" registry group. This new regis
within the "Provisioning Domains (PvDs)" registry page. This new regist try
ry
reserves JSON keys for use in sub-dictionaries under the splitDnsClaims JSON key. reserves JSON keys for use in sub-dictionaries under the splitDnsClaims JSON key.
The initial contents of this registry, as discussed in <xref target="spl itclaims"/>, The initial contents of this registry, as discussed in <xref target="spl itclaims"/>,
are listed below and will be added to the IANA registry:</t> are listed below and have been added to the registry:</t>
<figure anchor="fig-split-claims">
<name>Split DNS Claims</name> <table anchor="split-claims">
<artwork><![CDATA[ <name>Split DNS Claims</name>
+------------+-----------------------+---------+-----------------+-----------+ <thead>
| JSON key | Description | Type | Example | Reference | <tr>
+------------+-----------------------+---------+-----------------+-----------+ <th>JSON key</th>
| resolver | The Authentication | String |"dns.example.net"| [RFCXXXX] | <th>Description</th>
| | Domain Name | | | | <th>Type</th>
| | | | | | <th>Example</th>
| parent | The parent zone name | String | "example.com" | [RFCXXXX] | <th>Reference</th>
| | | | | | </tr>
| subdomains | An array containing | Array of| ["sub"] | | </thead>
| | the claimed subdomains| Strings | | [RFCXXXX] | <tbody>
| | | | | | <tr>
| algorithm | The hash algorithm | String | "SHA384" | [RFCXXXX] | <td>resolver</td>
| | | | | | <td>The Authentication Domain Name</td>
| salt | The salt (base64url) | String | "abc...123" | [RFCXXXX] | <td>String</td>
| | | | | | <td>"dns.example.net"</td>
+------------+-----------------------+---------+-----------------+-----------+ <td>RFC 9704</td>
]]></artwork> </tr>
</figure> <tr>
<td>parent</td>
<td>The parent zone name</td>
<td>String</td>
<td>"example.com"</td>
<td>RFC 9704</td>
</tr>
<tr>
<td>subdomains</td>
<td>An array containing the claimed subdomains</td>
<td>Array of Strings</td>
<td>["sub"]</td>
<td>RFC 9704</td>
</tr>
<tr>
<td>algorithm</td>
<td>The hash algorithm</td>
<td>String</td>
<td>"SHA384"</td>
<td>RFC 9704</td>
</tr>
<tr>
<td>salt</td>
<td>The salt (base64url)</td>
<td>String</td>
<td>"abc...123"</td>
<td>RFC 9704</td>
</tr>
</tbody>
</table>
<t>The keys defined in this document are mandatory. Any new assignments of keys will be considered <t>The keys defined in this document are mandatory. Any new assignments of keys will be considered
as optional for the purpose of the mechanism described in this document. </t> as optional for the purpose of the mechanism described in this document. </t>
<t>New assignments in the "PvD Split DNS Claims Registry" registry will be <t>New assignments in the "PvD Split DNS Claims" registry will be
administered by IANA through Expert Review <xref target="RFC8126"/>. Exp erts are administered by IANA through Expert Review <xref target="RFC8126"/>. Exp erts are
requested to ensure that defined keys do not overlap in names or semanti cs.</t> requested to ensure that defined keys do not overlap in names or semanti cs.</t>
<section> <section>
<name>Guidelines for the Designated Experts</name> <name>Guidelines for the Designated Experts</name>
<t>It is suggested that multiple designated experts be appointed for <t>It is suggested that multiple designated experts be appointed for
registry change requests.</t> registry change requests.</t>
<t>Criteria that should be applied by the designated experts include <t>Criteria that should be applied by the designated experts include
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
entries and whether the registration description is clear and fits entries and whether the registration description is clear and fits
skipping to change at line 821 skipping to change at line 1214
on the advice of one or more designated experts. Within the review on the advice of one or more designated experts. Within the review
period, the designated experts will either approve or deny the period, the designated experts will either approve or deny the
registration request, communicating this decision to IANA. Denials registration request, communicating this decision to IANA. Denials
should include an explanation and, if applicable, suggestions as to should include an explanation and, if applicable, suggestions as to
how to make the request successful.</t> how to make the request successful.</t>
</section> </section>
</section> </section>
<section> <section>
<name>DNS Underscore Name</name> <name>DNS Underscore Name</name>
<t>IANA is requested to add the following entry to the "Underscored and <t>IANA has added the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry under the "Domain Name System ( Globally Scoped DNS Node Names" registry in the "Domain Name System (DNS
DNS) )
Parameters" registry group:</t> Parameters" registry group:</t>
<ul> <dl newline="false" spacing="normal">
<li>RR Type: TXT</li> <dt>RR Type:</dt><dd>TXT</dd>
<li>_NODE NAME: _splitdns-challenge</li> <dt>_NODE NAME:</dt><dd>_splitdns-challenge</dd>
<li>Reference: (This document)</li> <dt>Reference:</dt><dd>RFC 9704</dd>
</ul> </dl>
</section> </section>
</section> </section>
<section>
<name>Acknowledgements</name>
<t>Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Michael
Richardson,
Bernie Volz, Éric Vyncke and Vinny Parla for the discussion and comments.<
/t>
<t>Thanks to Tianran Zhou for the opsdir review, Anthony Somerset for the
dnsdir review,
Watson Ladd for the secdir review, Bob Halley for the intdir review and Ma
llory Knodel
for the genart review.</t>
<t>Thanks to Mohamed Boucadair for the Shepherd review.</t>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.ietf-dnsop-domain-verification-techniques" to= "DOMAIN-VERIFICATION-TECHNIQUES"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/> 119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
118.xml"/> 118.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
131.xml"/> 131.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
034.xml"/> 034.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/> 174.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
801.xml"/> 801.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
698.xml"/> 698.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
035.xml"/> 035.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
976.xml"/> 976.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/> 415.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
396.xml"/> 396.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
761.xml"/> 761.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/> 126.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
525.xml"/> 525.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/> 086.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/> 648.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
499.xml"/> 499.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
598.xml"/> 598.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
686.xml"/> 686.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
806.xml"/> 806.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
106.xml"/> 106.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
702.xml"/> 702.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
704.xml"/> 704.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
731.xml"/> 731.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
986.xml"/> 986.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
310.xml"/> 310.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
696.xml"/> 696.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
858.xml"/> 858.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
484.xml"/> 484.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
250.xml"/> 250.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
364.xml"/> 364.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/> 234.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
762.xml"/> 762.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.87 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
92.xml"/> 92.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
463.xml"/> 463.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
464.xml"/> 464.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.94 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
62.xml"/> 62.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/referen
ce.I-D.ietf-dnsop-domain-verification-techniques.xml"/> <!-- draft-ietf-dnsop-domain-verification-techniques (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dn
sop-domain-verification-techniques.xml"/>
</references> </references>
</references> </references>
<section numbered="false">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Mohamed Boucadair"/>, <contact
fullname="Jim Reid"/>, <contact fullname="Tommy Pauly"/>, <contact
fullname="Paul Vixie"/>, <contact fullname="Michael Richardson"/>,
<contact fullname="Bernie Volz"/>, <contact fullname="Éric Vyncke"/>, and
<contact fullname="Vinny Parla"/> for the discussion and comments.</t>
<t>Thanks to <contact fullname="Tianran Zhou"/> for the opsdir review,
<contact fullname="Anthony Somerset"/> for the dnsdir review, <contact
fullname="Watson Ladd"/> for the secdir review, <contact fullname="Bob
Halley"/> for the intdir review, and <contact fullname="Mallory Knodel"/>
for the genart review.</t>
<t>Thanks to <contact fullname="Mohamed Boucadair"/> for the Shepherd revi
ew.</t>
</section>
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
<!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following terms were used inconsistently in this document.
We chose to use the latter forms. Please let us know any objections.
Authorization Claim (13 instances in text) /
authorization claim (3 instances in text) (per post-6000
published RFCs)
Global DNS / global DNS (per RFC 9499 and other post-6000
published RFCs, except for RFC 9526)
PvD additional information (1 instance /
PvD Additional Information (2 instances) (per post-6000
published RFCs)
RRSet / RRset (per much more common usage in post-6000
published RFCs)
b) The following terms appear to be used inconsistently in this
document. Please let us know which form is preferred.
"ds=..." (2 instances) / "ds" (4 instances) *
* It is not clear whether these variations refer to the same
parameter or two distinct parameters. Please advise.
Verification Record (15 instances in text) /
verification record (6 instances in text in Section 11) **
** We could not find a precedent in published RFCs to date.
If this is not considered a proper term, we suggest the
lowercase form. -->
</back> </back>
</rfc> </rfc>
 End of changes. 120 change blocks. 
434 lines changed or deleted 890 lines changed or added

This html diff was produced by rfcdiff 1.48.