<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<?xml-model href="https://raw.githubusercontent.com/ietf-tools/xml2rfc/main/xml2rfc/data/v3.rng" schematypens="http://relaxng.org/ns/structure/1.0" type="application/xml"?>
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- 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 --> encoding='UTF-8'?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-add-split-horizon-authority-14" number="9704" updates="" obsoletes="" ipr="trust200902" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" consensus="true">
  <front>
    <title abbrev="Establishing Local DNS Authority">Establishing Local DNS
    Authority in Validated Split-Horizon Environments</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-add-split-horizon-authority-14"/> name="RFC" value="9704"/>
    <author fullname="Tirumaleswar Reddy" Reddy.K" initials="T." surname="Reddy"> surname="Reddy.K">
      <organization>Nokia</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Citrix">Citrix Systems, Inc.</organization>
      <address>
        <postal>
          <street>4988 Great America Pkwy</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95054</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>danwing@gmail.com</email>
      </address>
    </author>
    <author fullname="Kevin Smith" initials="K." surname="Smith">
      <organization abbrev="Vodafone">Vodafone Group</organization>
      <address>
        <postal>
          <street>One Kingdom Street</street>
          <city>London</city>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>kevin.smith@vodafone.com</email>
      </address>
    </author>
    <author fullname="Benjamin Schwartz" initials="B." surname="Schwartz">
      <organization abbrev="Meta">Meta Platforms, Inc.</organization>
      <address>
        <email>ietf@bemasc.net</email>
      </address>
    </author>
    <date/>
    <workgroup>ADD</workgroup>
    <date month="December" year="2024"/>
    <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>
      <t>When split-horizon DNS is deployed by a network, certain domain names can
      be resolved authoritatively by a network-provided DNS resolver. DNS clients
      that are not configured to use this resolver by default can use it for
      these specific domains only. This specification defines a mechanism for domain owners
      to inform DNS clients about local resolvers that are authorized to answer
      authoritatively for certain subdomains.</t>
    </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/browse/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-horizon-authority"/>.</t>
      </note>
    </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>To resolve a DNS query, there are three main behaviors that an
      implementation can apply: (1) answer from a local database, (2) query
      the relevant authorities and their parents, or (3) ask a server to query
      those authorities and return the final answer. Implementations that use
      these behaviors are called "authoritative nameservers", "full/recursive
      resolvers", and "forwarders" (or "stub resolvers") resolvers"), respectively. However, an
      implementation can also implement a mixture of these behaviors,
      depending on a local policy, for each query. Such an implementation
      is termed a "hybrid resolver".</t>
      <t>Most DNS resolvers are hybrids of some kind. For example, stub
      resolvers support a local "hosts file" that preempts query
      forwarding, and most DNS forwarders and full resolvers can also serve
      responses from a local zone file. Other standardized hybrid resolution
      behaviors include <xref target="RFC8806">Local Root</xref>, target="RFC8806">using a local root</xref>, <xref
      target="RFC6762">mDNS</xref>,
      target="RFC6762">Multicast DNS (mDNS)</xref>, and <xref target="RFC7686">NXDOMAIN
      synthesis for .onion</xref>.</t>
      <t>Networks usually offer clients a DNS resolver using means such as
      (e.g.,
      DHCP OFFER, offers or IPv6 Router Advertisement). Advertisements (RAs). Although this resolver is
      formally specified as a recursive resolver (e.g., <relref see <xref section="5.1"
      target="RFC8106"/>), some networks provide a hybrid resolver
      instead. If this resolver acts as an authoritative server for some names
      and provides different answers for those domains -- depending on the source of the query, it is described as query -- provides different answers for those domains, the network having is said to be using "split-horizon DNS", because those
      names resolve in this way only from inside the network.</t>
      <t>DNS clients that use pure stub resolution, sending all queries to
      the network-provided resolver, will always receive the split-horizon
      results. Conversely, clients that send all queries to a different
      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
      this specification. Instead, this specification enables hybrid clients
      to access split-horizon results from a network-provided hybrid resolver,
      while using a different resolution method for some or all other
      names.</t>
      <t>There are several existing mechanisms for a network to provide
      clients with "local domain hints", listing domain names that have are given
      special treatment in this network (e.g., <xref target="RFC6731">
      RDNSS Selection</xref>,
      "Recursive DNS Server (RDNSS) selection"</xref>, <xref target="RFC5986">
      "Access Network Domain Name"</xref>,
      "access network domain name"</xref>, and "Client FQDN" Fully Qualified Domain Name
 (FQDN)" <xref
      target="RFC4702"/> <xref
      target="RFC4702"/><xref target="RFC4704"/> in DHCP, DHCP; "dnsZones" in
      Provisioning Domains (PvDs) <xref target="RFC8801"/>, target="RFC8801"/>; and <xref
      target="RFC8598">INTERNAL_DNS_DOMAIN</xref>
      target="RFC8598">"INTERNAL_DNS_DOMAIN"</xref> in IKEv2). Internet Key Exchange Protocol Version 2 (IKEv2)).
      However, none of the local domain hint mechanisms enables enable clients to
      determine whether this special treatment is authorized by the domain
      owner. Instead, these specifications require clients to make their own
      determinations about whether to trust and rely on these hints.</t>
      <t>This document describes a mechanism between domain names, networks,
      and clients that allows the network to establish its authority over a
      domain to a client (<xref target="establishing"/>). Clients can
      use this protocol to confirm that a local domain hint was authorized by
      the domain owner (<xref target="validating"/>), which might influence
      its processing of that hint.  This process requires cooperation between
      the local DNS zone and the public zone.</t>
      <t>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.

<!-- [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.</t>
 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 anchor="notation">
      <name>Terminology</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <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
      target="RFC9499"/>, e.g., "Global "global DNS".  The following additional terms are
      used throughout the this document:</t>
      <dl>
        <dt>Encrypted DNS</dt><dd>A DNS:</dt><dd>A DNS protocol that provides an
        encrypted channel between a DNS client and server (e.g., DNS
        over TLS (DoT) <xref
      target="RFC7858"/>, DNS (queries) over HTTPS (DoH) <xref
      target="RFC8484"/>, DNS over QUIC (DoQ) <xref
      target="RFC9250"/>).</dd>
        <dt>Encrypted DNS resolver</dt><dd>Refers Resolver:</dt><dd>Refers to a DNS resolver
        that supports any encrypted DNS scheme.</dd>
          <dt>Split-Horizon DNS</dt><dd>The DNS:</dt><dd>The DNS service provided by a resolver
          that also acts as an authoritative server for some names, providing
          resolution results that are meaningfully different from those in the
          Global
          global DNS. (See "Split the definition of "split DNS" in <relref <xref section="6"
          target="RFC9499"/>.)</dd>
        <dt>Validated Split-Horizon</dt><dd>A split horizon Split Horizon:</dt><dd>Indicates that a split-horizon configuration for
          some name is considered "validated" if the client has confirmed that
          a parent of that name has authorized this resolver  to serve its own
          responses for that name. Such authorization generally extends to the
          entire subtree of names below the authorization point.</dd>
      </dl>
      <t>In this document, the terms 'owner' "owner" and 'operator' "operator" are used interchangeably
      and refer to the individual or entity responsible for the management and
      maintenance of domains.</t>
    </section>
    <section>
      <name>Scope</name>
      <t>The protocol described in this document is designed to support the ability of
      a domain owner to create or authorize a split-horizon view of their
      domain. The protocol does not support split-horizon views created by
      any other entity. Thus, DNS filtering is not enabled by this protocol.</t>
      <t>The protocol is applicable to any type of network offering
      split-horizon DNS configuration. The endpoint does not need any prior
      configuration to confirm that a local domain hint was indeed authorized
      by the domain.</t>
      <t>All of the special-use domain names Special-Use Domain Names registered with IANA <xref target="RFC6761"/>,
      most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." "ipv4only.arpa.", and ".local", are never
      unique to a specific DNS server's authority. All special-use domain names Special-Use Domain Names are outside the
      scope of this document and MUST NOT <bcp14>MUST NOT</bcp14> be validated using the mechanism described in this document. </t>
      <t> Use
      <t>The use of this specification is limited to DNS servers that support authenticated encryption and
      split-horizon DNS names that are rooted in the global DNS.</t> 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>
      <name>Requirements</name>
      <t>This solution seeks to fulfill the following requirements:</t>
      <ul>
        <li>No
<dl newline="false" spacing="normal">
        <dt>No loss of security: No security:</dt><dd>No unauthorized party can impersonate
          a zone unless they could already do so without the use of this
          specification.</li>
        <li>Least privilege: Local
          specification.</dd>
        <dt>Least privilege:</dt><dd>Local resolvers do not hold any
          secrets that could weaken the security of the public zone if
          compromised.</li>
        <li>Local
          compromised.</dd>
        <dt>Local zone confidentiality: The confidentiality:</dt><dd>The specification does not leak
          local network subdomains to anyone outside of the network.</li>
        <li>Flexibility: The network.</dd>
        <dt>Flexibility:</dt><dd>The specification can represent and authorize
          a Split split DNS zone structure.</li>
        <li>DNSSEC Compatibility: The structure.</dd>
        <dt>DNSSEC compatibility:</dt><dd>The specification supports DNSSEC-based
          <xref target="RFC9364"/>
          object security for local zone contents.</li>
      </ul> contents per <xref target="RFC9364"/>.</dd>
      </dl>
    </section>
    <section anchor="establishing">
      <name>Establishing Local DNS Authority</name>
      <t>A participating network <bcp14>MUST</bcp14> offer one or more
      encrypted resolvers via DHCP and Router Advertisement Options options for the
      Discovery of Network-designated Resolvers (DNR) <xref target="RFC9463"/>,
      Discovery of Designated Resolvers (DDR) <xref target="RFC9462"/>, or an
      equivalent mechanism (see <xref target="vpn"/>).</t>
      <t>To establish local authority, the network MUST <bcp14>MUST</bcp14> convey one or more
      "Authorization Claims"
      "authorization claims" to the client.  An "Authorization Claim" authorization claim is an
      abstract structure comprising:</t>
      <ul>
        <li>An Authentication Domain Name (ADN) of a local encrypted resolver.</li>
        <li>The DNS name of the authorizing parent zone.</li>
        <li>A set of subdomains of this parent zone that are claimed by
            the named local resolver (potentially including the entire parent
            zone). To claim the entire parent zone, the claimed subdomain
            will be represented as an asterisk symbol "*".</li> ("*").</li>
        <li>A ZONEMD Hash Algorithm (<relref (<xref section="5.3" target="RFC8976"/>).
           For interoperability purposes purposes, implementations MUST <bcp14>MUST</bcp14> support the
           "mandatory to implement" hash algorithms defined in
           <relref
           <xref section="2.2.3" target="RFC8976"/>. </li>
        <li>A high-entropy salt, up to 255 octets.</li>
      </ul>
      <t>If the local encrypted resolver is identified by name (e.g., DNR), that
      identifying name MUST <bcp14>MUST</bcp14> be the one name used in any corresponding Authorization
      Claim. authorization
      claim.  Otherwise (e.g., DDR using IP addresses), the resolver MUST <bcp14>MUST</bcp14>
      present a validatable certificate containing a subjectAltName that
      matches the Authorization Claim authorization claim using the validation techniques for
      matching as described in <xref target="RFC9525"/>.</t>
      <t>The network then provides each Authorization Claim authorization claim to the parent zone operator.
      If the contents are approved, the parent zone operator computes a "Verification Token"
      according to the following procedure:</t>
      <ol>
        <li>Convert all subdomains into canonical form and sort them in canonical
            order (<relref (<xref section="6" target="RFC4034"/>).</li>
        <li>Replace the suffix corresponding to the parent zone with a zero
            octet.</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 $TOKEN = hash(len($SALT) || $SALT || $X). Where $X), where "||" denotes concatenation and hash is the ZONEMD Hash Algorithm.</li>
      </ol>
      <t>The zone operator then publishes a "Verification Record" with the
      following structure, following the best practices outlined in
      Sections&nbsp;<xref target="I-D.ietf-dnsop-domain-verification-techniques" sectionFormat="bare" section="5.2"/> and <xref target="I-D.ietf-dnsop-domain-verification-techniques"
sectionFormat="bare" section="5.3"/> of <xref target="I-D.ietf-dnsop-domain-verification-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-ietf-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
      <xref target="I-D.ietf-dnsop-domain-verification-techniques"/>:</t>
 [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> TXT</li>
        <li>Owner Name = Concatenation of the ADN, "_splitdns-challenge", and
            the parent zone name.</li> name</li>
        <li>Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding)</li>
      </ul>
      <t>By publishing this record, the parent zone authorizes the local
      encrypted resolver to serve these subdomains authoritatively.</t>
      <section>
        <name>Example</name>
        <t>Consider the following authorization claim:</t>
        <ul>
          <li>ADN = "resolver17.parent.example"</li>
          <li>Parent = "parent.example"</li>
          <li>Subdomains = "payroll.parent.example",
              "secret.project.parent.example"</li>
          <li>Hash Algorithm = SHA-384 <xref target="RFC6234"/></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>
        <t>To approve this claim, the zone operator would publish the following record:</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">
  resolver17.parent.example._splitdns-challenge.parent.example. \
  IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
  -KJDv2eFwfJcWQM"
</sourcecode>
      </section>
      <section>
        <name>Conveying Authorization Claims</name>
        <t>
          The Authorization Claim authorization claim is an abstract structure that must be encoded in
          some concrete syntax in order to convey it from the network to the client.
          This section defines some encodings of the Authorization Claims. authorization claims.
        </t>
        <section>
          <name>Using DHCP</name>
          <t>

            In DHCP, each Authorization Claim authorization claim is encoded as a DHCP Authentication
            Option
            option (<xref target="RFC3118"/> and <relref <xref section="21.11" target="RFC8415"/>),
            using the Protocol value $TBD1, "Split DNS Authentication". 4, "Split-horizon DNS". In DHCPv4 <xref target="RFC2131"/>, the long-options mechanism for splitting long options as
            described in <relref <xref section="8" target="RFC3396"/> MUST <bcp14>MUST</bcp14> be used if the
            authentication
            Authentication option exceeds the maximum DHCPv4 option size of 255 octets. The Algorithm field
            provides the ZONEMD Hash Algorithm, represented by its registered Value.
            The Replay Detection Method value <bcp14>MUST</bcp14> be 0x00. The Authentication Information
            <bcp14>MUST</bcp14> contain the following information, concatenated:</t>
          <ol>
            <li>The ADN in canonical form.</li>
            <li>The parent name in canonical form.</li>
            <li>A one-octet "salt length" field.</li>
            <li>The salt value.</li>
            <li>The $X value as defined in <xref target="establishing"/>.</li>
          </ol>
        </section>
        <section anchor="splitclaims">
          <name>Using Provisioning Domains</name>
          <t>When using <xref target="RFC8801">Provisioning Domains</xref>, target="RFC8801">PvDs</xref>, the
          Authorization Claims
          authorization claims are represented by the PvD Additional
          Information key "splitDnsClaims", whose value is a
          JSON Array. array.  Each entry in the array <bcp14>MUST</bcp14> be a JSON object
          with the following structure:</t>
          <ul>
            <li>"resolver": The
<dl newline="false" spacing="normal">
            <dt>"resolver":</dt><dd>The ADN as a dot-separated name.</li>
            <li>"parent": The name.</dd>
            <dt>"parent":</dt><dd>The parent zone name as a dot-separated name.</li>
            <li>"subdomains": An name.</dd>
            <dt>"subdomains":</dt><dd>An array containing the claimed subdomains, as
                dot-separated names with the parent suffix already removed, in
                canonical order. To claim the entire parent zone, the claimed subdomain
                will be represented as an asterisk symbol "*".</li>
            <li>"algorithm": ("*").</dd>
            <dt>"algorithm":</dt><dd>The hash algorithm, represented by its "Mnemonic"
                string from the "ZONEMD Hash Algorithms" registry (<xref target="RFC8976"
                section="5.3" sectionFormat="of"/>).

<!-- [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 (<relref target="RFC8976"
                section="5.2" displayFormat="comma"/>).</li>
            <li>"salt": ([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="RFC4648"/>.</li>
          </ul> target="RFC4648"/>.</dd>
          </dl>

        <t>Future specifications aiming to define new keys will need to add them to the
        IANA registry defined in <xref target="IANA"/>. target="new-split-claims-registry"/>. DNS client implementations
        will ignore any keys they don't recognize but may also report about
        unknown keys.</t> 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 anchor="validating">
      <name>Validating Authority over Local Domain Hints</name>
      <t>To validate an Authorization Claim authorization claim provided by the network, DNS clients
      <bcp14>MUST</bcp14> resolve the Verification Record for that name.
      If the resolution produces an RRSet RRset containing the expected token for this
      Claim,
      claim, the client <bcp14>SHALL</bcp14> regard the named resolver as
      authoritative for the claimed subdomains. Clients <bcp14>MUST</bcp14> ignore
      any unrecognized keys in the Verification Record.</t>
      <t>Each validation of authority applies only to a specific ADN.
      If a network offers multiple encrypted resolvers, each claimed
      subdomain may be authorized for a distinct subset of the network-provided
      resolvers.</t>
      <t>A zone is termed a "Validated Split-Horizon zone" after successful
      validation using a "tamperproof" DNS resolution method, i.e., a method
      that is not subject to interference by the local network operator. Two
      possible tamperproof resolution methods are presented below.</t>
      <section anchor="validating-external">
        <name>Using a Pre-configured Preconfigured External Resolver</name>
        <t>This method applies only if the client is already configured with
        a default resolution strategy that sends queries to a resolver outside
        of the network over a an encrypted transport.  That resolution strategy is
        considered "tamperproof" tamperproof because any actor who could modify the
        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
        reasonable timeout period, it MUST <bcp14>MUST</bcp14> consider the verification process
        to have failed.</t>
        <t>To ensure that this assumption holds, clients <bcp14>MUST NOT</bcp14>
        relax the acceptance rules they would otherwise apply when using this
        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
        when resolving TXT records for this purpose. Alternatively, a client might
        perform DNSSEC validation for the verification query
        even if it has disabled DNSSEC validation for other DNS queries.</t>
      </section>
      <!-- validating-external -->

      <section anchor="validating-dnssec">
        <name>Using DNSSEC</name>
        <t>The client resolves the Verification Record using any resolution method of
        its choice (e.g., querying one of the network-provided resolvers,
        performing iterative resolution locally), locally) and performs full DNSSEC
        validation locally <xref target="RFC6698"/>. The result is
        processed based on its DNSSEC validation state (<relref (<xref section="4.3"
        target="RFC4035" displayFormat="comma"/>): sectionFormat="of"/>): </t>
        <ul empty="true">
          <li><strong>Secure</strong>: The

<dl newline="false" spacing="normal">
          <dt><strong>Secure</strong>:</dt><dd>The response is used for validation.</li>
          <li><strong>Bogus</strong> validation.</dd>
          <dt><strong>Bogus</strong> or <strong>Indeterminate</strong>: The <strong>Indeterminate</strong>:</dt><dd>The response is rejected rejected, and
            validation is considered to have failed.</li>
          <li><strong>Insecure</strong>: The failed.</dd>
          <dt><strong>Insecure</strong>:</dt><dd>The client <bcp14>SHOULD</bcp14> retry the validation
            process using a different method, such as the one method described in <xref
            target="validating-external"/>, to ensure compatibility with
            unsigned names. If the client chooses not to retry (e.g., no configured policy to validate
            the authorization claim using an external resolver), it MUST <bcp14>MUST</bcp14> consider
            validation to have failed.</li>
        </ul> failed.</dd>
        </dl>
      </section>
      <!-- validating-DNSSEC -->
    </section>
    <!-- Validating -->

    <section>
      <name>Delegating DNSSEC across Across Split DNS Boundaries</name>
      <t>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.  Zones in this configuration appear the same to validating stubs whether
      or not they implement this specification.</t> 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
      the local resolver to hold DNSSEC private keys that are valid for the parent
      zone, parent zones <bcp14>MAY</bcp14> add a "ds=..." key to the Verification
      Record whose value is the RDATA of a single DS record, base64url-encoded. encoded in base64url. This
      DS record authorizes a DNSKEY whose Owner Name owner name is "resolver.arpa."</t>
      <t>To validate DNSSEC, the client first fetches and validates the Verification
      Record.  If it is valid and contains a "ds" key, the client <bcp14>MAY</bcp14>
      send a DNSKEY query for "resolver.arpa." to the local encrypted resolver.
      At least one resulting DNSKEY RR Resource Record (RR) <bcp14>MUST</bcp14> match the DS RDATA from
      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
      DNSKEY whose RDATA is identical to one of these approved DNSKEYs.</t> 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
      times in a single Verification Record, in order to authorize multiple DNSKEYs
      for this local encrypted resolver.  If the "ds" key is not present in a valid
      Verification Record, the client <bcp14>MUST</bcp14> disable DNSSEC validation
      when resolving the claimed subdomains via this local encrypted resolver.</t>
      <t>Note that in this configuration, any claimed subdomains MUST <bcp14>MUST</bcp14> be marked as
      unsigned in the public DNS.  Otherwise, resolution results would be rejected
      by validating stubs that do not implement this specification.</t>
      <figure>
        <name>Example use 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>
;; Parent zone.
$ORIGIN parent.example.

; Parent zone's public KSK Key Signing Key (KSK)
; and ZSK Zone Signing Key (ZSK).
@ IN DNSKEY 257 3 5 ABCD...=
@ IN DNSKEY 256 3 5 DCBA...=

; Verification Record containing DS RDATA for the local
; resolver's KSK.  This is an ordinary public TXT record,
; secured by RRSIGs from the public ZSK.
resolver.example._splitdns-challenge IN TXT "token=abc...,ds=QWE..."

; NSEC record indicating that unsigned delegations are permitted at
; this subdomain.  This is required for compatibility with non-split-aware
; 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").
@ IN NSEC subdomain.parent.example. NS

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;; Local zone, claiming "subdomain.parent.example".

; The local resolver's KSK, validated by the Verification Record.
; It may not have a corresponding RRSIG.
resolver.arpa. IN DNSKEY 257 3 5 ASDF...=

; Each claimed subdomain duplicates the local resolver's KSK at its
; zone apex and uses it to sign the ZSK.
subdomain.parent.example.        IN DNSKEY 257 3 5 ASDF...=
subdomain.parent.example.        IN DNSKEY 256 3 5 FDSA...=
subdomain.parent.example         IN RRSIG DNSKEY 5 3 ...  \
        (KSK key tag) subdomain.parent.example. ...
subdomain.parent.example.        IN AAAA 2001:db8::17
subdomain.parent.example         IN RRSIG AAAA 5 3 ...    \
        (ZSK key tag) subdomain.parent.example. ...
deeper.subdomain.parent.example. IN AAAA 2001:db8::18
deeper.subdomain.parent.example  IN RRSIG AAAA 5 3 ...    \
        (ZSK key tag) subdomain.parent.example. ...
</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>
      <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
      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
      internal server resolves only a
      subdomain of the company's zone (e.g., <tt>*.internal.example.com</tt>).

<!-- [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., <tt>*.internal.example.com</tt>).</t>
 *.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">
        <name>Split-Horizon Entire Zone</name>
        <t>Consider an organization that operates "example.com", "example.com" and runs a
        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
        mechanisms described in <xref target="establishing"/>. <xref target="fig-learn"/>
        shows discovery using DNR and PvD.</t> PvD information.</t>
        <t>Validation is then perfomed performed using either <xref
        target="example-verify-external">an external resolver</xref> or <xref
        target="example-verify-dnssec">DNSSEC</xref>.</t>
        <ul empty="true">
          <li><strong>Steps 1-2</strong>: The

<dl newline="false" spacing="normal">
          <dt><strong>Steps 1-2</strong>:</dt><dd>The client determines the network's DNS
            server (dns.example.net) and Provisioning Domain PvD information (pvd.example.com)
            using <xref target="RFC9463">DNR</xref> and <xref
            target="RFC8801">PvD</xref>,
            target="RFC8801">PvDs</xref>, using one of the following: DNR Router Solicitation,
            DHCPv4, or DHCPv6.</li>
          <li><strong>Step 3-5</strong>: The DHCPv6.</dd>
          <dt><strong>Steps 3-5</strong>:</dt><dd>The client connects to dns.example.net
            using an encrypted transport as indicated in <xref
            target="RFC9463">DNR</xref>, authenticating the server to
            its name using TLS (<relref (<xref target="RFC8310" section="8"
            displayFormat="comma"/>),
            sectionFormat="of"/>), and
            sends it a query for the address of <tt>pvd.example.com</tt>.</li>
          <li><t><strong>Steps 6-7</strong>: The <tt>pvd.example.com</tt>.</dd>
          <dt><strong>Steps 6-7</strong>:</dt><dd><t>The client connects to the PvD server,
            validates its certificate, and retrieves the provisioning domain PvD
            JSON information indicated by the associated PvD. The PvD
            contains:</t>
            <sourcecode type="json">{
  "identifier": "pvd.example.com",
  "expires": "2025-05-23T06:00:00Z",
  "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
  "splitDnsClaims": [{
    "resolver": "dns.example.net",
    "parent": "example.com",
    "subdomains": ["*"],
    "algorithm": "SHA384",
    "salt": "abc...123"
  }]
}</sourcecode>
            <t>The JSON keys "identifier", "expires", and "prefixes"
            are defined in <xref target="RFC8801"/>.</t></li>
        </ul> target="RFC8801"/>.</t></dd>
        </dl>
        <figure anchor="fig-learn">
          <name>An Example of Learning Local Claims of DNS Authority</name>
          <artwork><![CDATA[
+---------+         +--------------------+  +------------+ +--------+
| Client  |         | Network's          |  | Network    | | Router |
|         |         | Encrypted Resolver |  | PvD Server | |        |
+---------+         +--------------------+  +------------+ +--------+
   |                                     |         |            |
   | Router Solicitation or              |         |            |
   | DHCPv4/DHCPv6 (1)                   |         |            |
   |----------------------------------------------------------->|
   |                                     |         |            |
   |  Response with DNR ADN &            |         |            |
   |  PvD FQDN (2)                       |         |            |
   |<-----------------------------------------------------------|
   | ----------------------------\       |         |            |
   |-| now knows DNR ADN &       |       |         |            |
   | | PvD FQDN                  |       |         |            |
   | |---------------------------/       |         |            |
   |                                     |         |            |
   | TLS connection to dns.example.net (3)         |            |
   |------------------------------------>|         |            |
   | ---------------------------\        |         |            |
   |-| validate TLS certificate |        |         |            |
   | |--------------------------/        |         |            |
   |                                     |         |            |
   | resolve pvd.example.com  (4)        |         |            |
   |------------------------------------>|         |            |
   |                                     |         |            |
   |            A or AAAA records (5)    |         |            |
   |<------------------------------------|         |            |
   |                                     |         |            |
   | https://pvd.example.com/.well-known/pvd (6)   |            |
   |---------------------------------------------->|            |
   |                                     |         |            |
   |  200 OK (JSON Additional Information) (7)     |            |
   |<----------------------------------------------|            |
   | ----------------------------------\ |         |            |
   |-| {..., "splitDnsClaims": [...] } | |         |            |
   | |---------------------------------/ |         |            |
]]></artwork>
        </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">
          <name>Verification Using an External Resolver</name>
          <t><xref target="fig-learn2"/> shows the steps performed to verify the local
          claims of DNS authority using an external resolver.</t>
          <ul empty="true">
            <li><strong>Steps 1-2</strong>: The

<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
              queries for the Verification Records. The TXT lookup returns
              a token that matches the claim.</li>
            <li><strong>Step 3</strong>: The claim.</dd>
            <dt><strong>Step 3</strong>:</dt><dd>The client has validated that
              <tt>example.com</tt> has authorized <tt>dns.example.net</tt>
              to serve <tt>example.com</tt>. When the client connects using an
              encrypted transport as indicated in <xref
              target="RFC9463">DNR</xref>, it will authenticate
              the server to its name using TLS (<relref (<xref target="RFC8310"
              section="8" displayFormat="comma"/>), sectionFormat="of"/>) and send queries to resolve
              any names that fall within the claimed zones.</li>
          </ul> zones.</dd>
          </dl>
          <figure anchor="fig-learn2">
            <name>Verifying claims using Claims Using an external resolver</name> External Resolver</name>
            <artwork><![CDATA[
+---------+                  +--------------------+  +----------+
| Client  |                  | Network's          |  | External |
|         |                  | Encrypted Resolver |  | Resolver |
+---------+                  +--------------------+  +----------+
     |                                          |         |
     | TLS connection                           |         |
     |--------------------------------------------------->|
     | ---------------------------\             |         |
     |-| validate TLS certificate |             |         |
     | |--------------------------|             |         |
     |                                          |         |
     | TXT? dns.example.net.\                   |         |
     |   _splitdns-challenge.example.com  (1)   |         |
     |--------------------------------------------------->|
     |                                          |         |
     |  TXT "token=ABC..."                  (2) |         |
     |<---------------------------------------------------|
     | --------------------------------\        |         |
     |-| dns.example.net is authorized |        |         |
     | ----------------------\---------|        |         |
     |-| finished validation |                  |         |
     | |---------------------|                  |         |
     |                                          |         |
     |  use dns.example.net when                |         |
     |  resolving example.com (3)               |         |
     |----------------------------------------->|         |
     |                                          |         |
]]></artwork>
          </figure>
        </section>
        <!-- external -->
        <section anchor="example-verify-dnssec">
          <name>Verification using Using DNSSEC</name>
          <t><xref target="fig-learn3"/> shows the steps performed to verify the local
          claims of DNS authority using DNSSEC.</t>
          <ul empty="true">
            <li><strong>Steps 1-2</strong>: The

<dl newline="false" spacing="normal">
            <dt><strong>Steps 1-2</strong>:</dt><dd>The DNSSEC-validating client queries
              the network network's encrypted resolver to issue TXT queries for the
              Verification Records. The TXT lookup will return
              a signed response containing the expected token. The client then
              performs full DNSSEC validation locally.</li>
            <li><strong>Step 3</strong>: If locally.</dd>
            <dt><strong>Step 3</strong>:</dt><dd>If the DNSSEC validation is successful and
              the token matches, then this Authorization Claim authorization claim is validated.
              Once the client connects using an encrypted transport as indicated
              in <xref target="RFC9463">DNR</xref>, it will authenticate
              the server to its name using TLS (<relref (<xref target="RFC8310"
              section="8" displayFormat="comma"/>), sectionFormat="of"/>) and send queries to resolve
              any names that fall within the claimed zones.</li>
          </ul> zones.</dd>
          </dl>
          <figure anchor="fig-learn3">
            <name>An Example of Verifying Claims using Using DNSSEC</name>
            <artwork><![CDATA[
+---------+                                    +--------------------+
| Client  |                                    | Network's          |
|         |                                    | Encrypted Resolver |
+---------+                                    +--------------------+
  |                                                               |
  | DNSSEC OK (DO), TXT? dns.example.net.\                        |
  |   _splitdns-challenge.example.com  (1)                        |
  |-------------------------------------------------------------->|
  |                                                               |
  | TXT token=DEF..., Signed Answer (RRSIG) (2)                   |
  |<--------------------------------------------------------------|
  | -------------------------------------\                        |
  |-| DNSKEY+TXT matches RRSIG, use TXT  |                        |
  | |------------------------------------|                        |
  | --------------------------------\                             |
  |-| dns.example.net is authorized |                             |
  | |-------------------------------|                             |
  | ----------------------\                                       |
  |-| finished validation |                                       |
  | |---------------------|                                       |
  |                                                               |
  | use encrypted network-designated resolver for example.com (3) |
  |-------------------------------------------------------------->|
  |                                                               |
]]></artwork>
          </figure>
        </section>
      </section>
    </section>
    <section anchor="operatonal">
      <name>Operational Efficiency in Split-Horizon Deployments</name>
        <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>).
        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
        subdomain (e.g., <tt>www.example.com</tt>) are sent to the
        external resolver rather than the resolver for internal.example.com.</t>
        <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
        client.</t>
        <t>Although placing internal domains inside a child domain is unnecessary to prevent leakage,
        such placement reduces the frequency of changes to the Verification Record, this Record. This document
        recommends that the internal domains be kept in a child zone of the local domain hints
        advertised by the network. For example, if the PvD "dnsZones" entry is
        "internal.example.com" and the network-provided DNS resolver is "ns1.internal.example.com",
        the network operator can structure the internal domain names as
        "private1.internal.example.com", "private2.internal.example.com",
        etc. The network-designated resolver will be used to resolve the subdomains of
        the local domain hint "*.internal.example.com".</t>
    </section>
    <section anchor="vpn">
      <name>Validation with IKEv2</name>
      <t>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 <xref target="RFC9464"/>. The VPN client
      can use the mechanism defined in Section 6 <xref target="validating"/> to validate that the discovered
      encrypted DNS resolver is authorized to answer for the claimed subdomains.</t> subdomains.

<!-- [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, capabilities. Note that those
      capabilities are not
      detailed here.</t> discussed in this document.</t>
    </section>
    <section anchor="aclaim">
      <name>Authorization Claim Update</name>
      <t>A verification record is only valid until it expires. Expiry occurs when the Time To Live (TTL)
      or DNSSEC signature validity period ends. Shortly before verification record expiry, clients MUST <bcp14>MUST</bcp14>
      fetch the verification records again and repeat the verification procedure. This ensures the
      availability of updated and valid verification records.</t>
      <t>A new verification record must be added to the RRset before the corresponding Authorization
      Claim authorization
      claim is updated.  After the claim is updated, the following procedures can be used:</t>
      <ol>
        <li>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 client to
        dynamically requesting request the updated Authorization Claim. authorization claim. This process avoids the need for
        the client to wait for its current lease to complete and request a new one, enabling the lease
        renewal to be driven by the DHCP server.</li> 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
        will be incremented, requiring clients to fetch PvD additional information Additional Information from the HTTPS
        server due to the updated sequence number in the new RA (<relref (<xref target="RFC8801" section="4.1"
        displayFormat="comma"/>).</li>
        sectionFormat="of"/>).</li>
        <li>The old verification record needs to be maintained until the DHCP lease time or PvD
        Additional Information expiry.</li> 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>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>The Authentication Domain Names ADNs of authorized local encrypted resolvers are
      revealed in the Owner Names owner names of Verification Records.  This makes it easier for
      domain owners to understand which resolvers they are currently authorizing to
      implement Split split DNS. However, this could create a confidentiality issue if the
      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
      be given names that do not reveal any sensitive information.</t>
      <t> The security properties of hashing algorithms are not fixed. Algorithm Agility agility
      (see <xref target="RFC7696"/>) is achieved by providing implementations with
      the flexibility to choose hashing algorithms from the ZONEMD Schemes "ZONEMD Schemes" registry
      (<relref
      (<xref target="RFC8976" section="5.2" displayFormat="comma"/>).</t> sectionFormat="of"/>).</t>
      <t>The entropy of a salt depends on a high-quality pseudo-random pseudorandom number generator.
      For further discussion on random number generation, see <xref target="RFC4086"/>.
      The salt MUST <bcp14>MUST</bcp14> be regenerated whenever the authorization claim is updated.</t>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <section>
        <name>DHCP Split DNS Authentication Algorithm</name>
        <t>IANA is requested to add has added the following entry to the "Protocol Name Space
        Values" registry on in the "Dynamic Host Configuration Protocol (DHCP)
        Authentication Option Name Spaces" page:</t>
        <ul>
          <li>Value: $TBD1</li>
          <li>Description: Split-horizon DNS</li>
          <li>Reference: (This Document)</li>
        </ul> registry group:</t>

	<dl newline="false" spacing="normal">
	  <dt>Value:</dt><dd>4</dd>
	  <dt>Description:</dt><dd>Split-horizon DNS</dd>
	  <dt>Reference:</dt><dd>RFC 9704</dd>
	</dl>
      </section>
      <section>
        <name>Provisioning Domains Split DNS Additional Information</name>
        <t>IANA

<!-- [rfced] Section 13.2:  This title is requested difficult to add interpret.
Does it mean "Provisioning Domains Using Split DNS Additional
Information", "Provisioning Domains: Split DNS Additional
Information", or something else?  Please clarify.

Original:
 13.2.  Provisioning Domains Split DNS Additional Information -->

        <t>IANA has added the following entry to the "Additional
        Information PvD Keys" registry under in the "Provisioning Domains (PvDs)" registry group:</t>
        <ul>
          <li>JSON key: "splitDnsClaims"</li>
          <li>Description: "Verifiable

<dl newline="false" spacing="normal">
          <dt>JSON key:</dt><dd>splitDnsClaims</dd>
          <dt>Description:</dt><dd>Verifiable locally served domains"</li>
          <li>Type: Array of Objects</li>
          <li><t>Example: </t><sourcecode domains</dd>
          <dt>Type:</dt><dd>Array of Objects</dd>
          <dt>Example:</dt><dd><sourcecode type="json">[{
  "resolver": "dns.example.net",
  "parent": "example.com",
  "subdomains": ["sub"],
  "algorithm": "SHA384",
  "salt": "abc...123"
}]</sourcecode></li>
          <li>Reference: (This document)</li>
        </ul>
}]</sourcecode></dd>
          <dt>Reference:</dt><dd>RFC 9704</dd>
        </dl>
      </section>
      <section>
      <section anchor="new-split-claims-registry">
        <name>New PvD Split DNS Claims Registry</name>
        <t>IANA is requested to create has created a new registry called "PvD Split DNS Claims" Registry,
        within the "Provisioning Domains (PvDs)" registry page. group.  This new registry
        reserves JSON keys for use in sub-dictionaries under the splitDnsClaims JSON key.
        The initial contents of this registry, as discussed in <xref target="splitclaims"/>,
        are listed below and will be have been added to the IANA registry:</t>
        <figure anchor="fig-split-claims">

<table anchor="split-claims">
  <name>Split DNS Claims</name>
          <artwork><![CDATA[
+------------+-----------------------+---------+-----------------+-----------+
| JSON key   | Description           | Type    | Example         | Reference |
+------------+-----------------------+---------+-----------------+-----------+
| resolver   | The
  <thead>
    <tr>
      <th>JSON key</th>
      <th>Description</th>
      <th>Type</th>
      <th>Example</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>resolver</td>
      <td>The Authentication    | String  |"dns.example.net"| [RFCXXXX] |
|            | Domain Name           |         |                 |           |
|            |                       |         |                 |           |
| parent     | The Name</td>
      <td>String</td>
      <td>"dns.example.net"</td>
      <td>RFC 9704</td>
    </tr>
    <tr>
      <td>parent</td>
      <td>The parent zone name  | String  | "example.com"   | [RFCXXXX] |
|            |                       |         |                 |           |
| subdomains | An name</td>
      <td>String</td>
      <td>"example.com"</td>
      <td>RFC 9704</td>
    </tr>
    <tr>
      <td>subdomains</td>
      <td>An array containing   | Array of| ["sub"]         |           |
|            | the claimed subdomains| Strings |                 | [RFCXXXX] |
|            |                       |         |                 |           |
| algorithm  | The subdomains</td>
      <td>Array of Strings</td>
      <td>["sub"]</td>
      <td>RFC 9704</td>
    </tr>
    <tr>
      <td>algorithm</td>
      <td>The hash algorithm    | String  | "SHA384"        | [RFCXXXX] |
|            |                       |         |                 |           |
| salt       | The algorithm</td>
      <td>String</td>
      <td>"SHA384"</td>
      <td>RFC 9704</td>
    </tr>
    <tr>
      <td>salt</td>
      <td>The salt (base64url)  | String  | "abc...123"     | [RFCXXXX] |
|            |                       |         |                 |           |
+------------+-----------------------+---------+-----------------+-----------+
]]></artwork>
        </figure> (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
        as optional for the purpose of the mechanism described in this document.</t>
        <t>New assignments in the "PvD Split DNS Claims Registry" Claims" registry will be
        administered by IANA through Expert Review <xref target="RFC8126"/>. Experts are
        requested to ensure that defined keys do not overlap in names or semantics.</t>
        <section>
          <name>Guidelines for the Designated Experts</name>
          <t>It is suggested that multiple designated experts be appointed for
          registry change requests.</t>

          <t>Criteria that should be applied by the designated experts include
          determining whether the proposed registration duplicates existing
          entries and whether the registration description is clear and fits
          the purpose of this registry.</t>

          <t>Registration requests are evaluated within a three-week review period
          on the advice of one or more designated experts. Within the review
          period, the designated experts will either approve or deny the
          registration request, communicating this decision to IANA. Denials
          should include an explanation and, if applicable, suggestions as to
          how to make the request successful.</t>

        </section>
      </section>
      <section>
        <name>DNS Underscore Name</name>
        <t>IANA is requested to add has added the following entry to the "Underscored and
        Globally Scoped DNS Node Names" registry under in the "Domain Name System (DNS)
        Parameters" registry group:</t>
        <ul>
          <li>RR Type: TXT</li>
          <li>_NODE NAME: _splitdns-challenge</li>
          <li>Reference: (This document)</li>
        </ul>
      </section>
<dl newline="false" spacing="normal">
          <dt>RR Type:</dt><dd>TXT</dd>
          <dt>_NODE NAME:</dt><dd>_splitdns-challenge</dd>
          <dt>Reference:</dt><dd>RFC 9704</dd>
        </dl>
      </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 Mallory Knodel
      for the genart review.</t>

      <t>Thanks to Mohamed Boucadair for the Shepherd review.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <displayreference target="I-D.ietf-dnsop-domain-verification-techniques" to="DOMAIN-VERIFICATION-TECHNIQUES"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3118.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3118.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2131.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4034.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8801.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8801.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6698.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4035.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8976.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8976.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8415.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3396.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3396.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6761.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8126.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9525.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4086.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4648.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9499.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8598.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8598.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7686.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7686.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8806.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8106.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4702.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4702.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4704.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4704.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6731.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6731.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5986.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5986.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8310.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7696.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7858.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8484.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9250.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9364.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6234.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6762.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8792.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9463.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9464.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9464.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9462.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml"/>

<!-- draft-ietf-dnsop-domain-verification-techniques (I-D Exists) -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dnsop-domain-verification-techniques.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dnsop-domain-verification-techniques.xml"/>
    </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 review.</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>
</rfc>