Internet Engineering Task Force (IETF) T. Reddy.K
Request for Comments: 9704 Nokia
Category: Standards Track D. Wing
ISSN: 2070-1721 Citrix
K. Smith
Vodafone
B. Schwartz
Meta
January 2025
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.
スプリットホリゾンDNSがネットワークによって展開されると、特定のドメイン名は、ネットワークが提供するDNSリゾルバーによって信頼できるように解決できます。このリゾルバーをデフォルトで使用するように構成されていないDNSクライアントは、これらの特定のドメインにのみ使用できます。この仕様では、特定のサブドメインについて権限に回答することが許可されているローカルリゾルバーについてDNSクライアントに通知するメカニズムを定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9704.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9704で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Scope
4. Requirements
5. Establishing Local DNS Authority
5.1. Example
5.2. Conveying Authorization Claims
5.2.1. Using DHCP
5.2.2. Using Provisioning Domains
6. Validating Authority over Local Domain Hints
6.1. Using a Preconfigured External Resolver
6.2. Using DNSSEC
7. Delegating DNSSEC Across Split DNS Boundaries
8. Example Split-Horizon DNS Configuration
8.1. Verification Using an External Resolver
8.2. Verification Using DNSSEC
9. Operational Efficiency in Split-Horizon Deployments
10. Validation with IKEv2
11. Authorization Claim Update
12. Security Considerations
13. IANA Considerations
13.1. New DHCP Authentication Algorithm for Split DNS
13.2. New PvD Additional Information Type for Split DNS
13.3. New PvD Split DNS Claims Registry
13.3.1. Guidelines for the Designated Experts
13.4. DNS Underscore Name
14. References
14.1. Normative References
14.2. Informative References
Acknowledgements
Authors' Addresses
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"), respectively. However, an implementation can also implement a mixture of these behaviors, depending on local policy, for each query. Such an implementation is termed a "hybrid resolver".
DNSクエリを解決するには、実装が適用できる3つの主な動作があります。（1）ローカルデータベースからの回答、（2）関連当局とその両親をクエリするか、（3）サーバーにそれらの当局を照会して返送するように依頼する最後の答え。これらの動作を使用する実装は、それぞれ「権威ある名前アーバー」、「フル/再帰リゾルバー」、および「フォワーダー」（または「スタブリゾルバー」）と呼ばれます。ただし、実装は、各クエリに対してローカルポリシーに応じて、これらの動作の混合を実装することもできます。このような実装は、「ハイブリッドリゾルバー」と呼ばれます。
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 using a local root [RFC8806], Multicast DNS (mDNS) [RFC6762], and NXDOMAIN synthesis for .onion [RFC7686].
ほとんどのDNSリゾルバーは、ある種のハイブリッドです。たとえば、スタブリゾルバーは、クエリ転送を先取りするローカル「ホストファイル」をサポートし、ほとんどのDNSフォワーダーとフルリゾルバーもローカルゾーンファイルからの応答を提供できます。その他の標準化されたハイブリッド解像度の動作には、ローカルルート[RFC8806]、マルチキャストDNS（MDNS）[RFC6762]、および.Onion [RFC7686]のNxDomain合成の使用が含まれます。
Networks usually offer clients a DNS resolver using means such as DHCP offers or IPv6 Router Advertisements (RAs). Although this resolver is formally specified as a recursive resolver (e.g., see Section 5.1 of [RFC8106]), some networks provide a hybrid resolver instead. If this resolver acts as an authoritative server for some names and -- depending on the source of the query -- provides different answers for those domains, the network is said to be using "split-horizon DNS", because those names resolve in this way only from inside the network.
ネットワークは通常、DHCPオファーやIPv6ルーター広告（RAS）などの手段を使用して、クライアントにDNSリゾルバーを提供します。このリゾルバーは、再帰リゾルバーとして正式に指定されていますが（たとえば、[RFC8106] 5.1セクションを参照）、一部のネットワークは代わりにハイブリッドリゾルバーを提供します。このリゾルバーは、一部の名前の権威あるサーバーとして機能し、クエリのソースに応じて、それらのドメインに異なる回答を提供する場合、ネットワークは「スプリットホリゾンDNS」を使用していると言われています。ネットワーク内からのみ。
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.
純粋なスタブ解像度を使用して、すべてのクエリをネットワークが提供するリゾルバーに送信するDNSクライアントは、常にスプリットホリゾンの結果を受け取ります。逆に、すべてのクエリを別のリゾルバーに送信したり、純粋なフル解像度をローカルに実装したりするクライアントは、それらを受け取ることはありません。これらの解像度の動作のいずれかを厳密に実装するクライアントは、この仕様の範囲外です。代わりに、この仕様により、ハイブリッドクライアントは、他の一部またはすべての名前に異なる解像度方法を使用しながら、ネットワークが提供するハイブリッドリゾルバーからスプリットホリゾンの結果にアクセスできます。
There are several existing mechanisms for a network to provide clients with "local domain hints", listing domain names that are given special treatment in this network (e.g., "Recursive DNS Server (RDNSS) selection" [RFC6731], "access network domain name" [RFC5986], and "Client Fully Qualified Domain Name (FQDN)" [RFC4702] [RFC4704] in DHCP; "dnsZones" in Provisioning Domains (PvDs) [RFC8801]; and "INTERNAL_DNS_DOMAIN" [RFC8598] in Internet Key Exchange Protocol Version 2 (IKEv2)). However, none of the local domain hint mechanisms 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.
ネットワークには、クライアントに「ローカルドメインヒント」を提供するためのいくつかの既存のメカニズムがあり、このネットワークで特別な処理が与えられたドメイン名をリストします（例：「再帰DNSサーバー（RDNS）選択」[RFC6731]、「アクセスネットワークドメイン名」「[RFC5986]、および「クライアント完全資格ドメイン名（FQDN）」[RFC4702] [RFC4704] in DHCP;「DNSZONES」のプロビジョニングドメイン（PVD）[RFC8801];バージョン2（IKEV2））。ただし、ローカルドメインのヒントメカニズムはどれも、クライアントがこの特別な治療がドメイン所有者によって承認されているかどうかを判断することはできません。代わりに、これらの仕様では、クライアントがこれらのヒントを信頼し、依存するかどうかについて独自の決定を行う必要があります。
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 (Section 5). Clients can use this protocol to confirm that a local domain hint was authorized by the domain owner (Section 6), which might influence its processing of that hint. This process requires cooperation between the local DNS zone and the public zone.
このドキュメントでは、ドメイン名、ネットワーク、およびクライアントの間のメカニズムについて説明します。これにより、ネットワークはクライアントに対するドメインに対する権限を確立できます（セクション5）。クライアントはこのプロトコルを使用して、ローカルドメインのヒントがドメインの所有者（セクション6）によって承認されたことを確認できます。これは、そのヒントの処理に影響を与える可能性があります。このプロセスには、ローカルDNSゾーンとパブリックゾーンとの間の協力が必要です。
In this specification, network operators securely identify the local DNS servers, and clients check each local domain hint against a globally valid parent zone.
この仕様では、ネットワークオペレーターはローカルDNSサーバーを安全に識別し、クライアントはグローバルに有効な親ゾーンに対して各ローカルドメインのヒントを確認します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document makes use of the terms defined in [RFC9499], e.g., "global DNS". The following additional terms are used throughout this document:
このドキュメントでは、[RFC9499]で定義されている用語、たとえば「グローバルDNS」を使用しています。このドキュメント全体で、次の追加項が使用されます。
Encrypted DNS:
暗号化されたDNS：
A DNS protocol that provides an encrypted channel between a DNS client and server (e.g., DNS over TLS (DoT) [RFC7858], DNS (queries) over HTTPS (DoH) [RFC8484], DNS over QUIC (DoQ) [RFC9250]).
DNSクライアントとサーバーの間に暗号化されたチャネルを提供するDNSプロトコル（例：TLS（DOT）[RFC7858]、DNS（Queries）を超えるDNS（DOH）[RFC8484]、DNS over QUIC（DOQ）[RFC9250]）。
Encrypted DNS Resolver:
暗号化されたDNSリゾルバー：
Refers to a DNS resolver that supports any encrypted DNS scheme.
暗号化されたDNSスキームをサポートするDNSリゾルバーを指します。
Split-Horizon DNS:
スプリットホリゾンDNS：
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 DNS. (See the definition of "split DNS" in Section 6 of [RFC9499].)
いくつかの名前の権威あるサーバーとしても機能するリゾルバーが提供するDNSサービスは、グローバルDNSの結果と有意に異なる解像度の結果を提供します。（[RFC9499]のセクション6の「分割DNS」の定義を参照してください。）
Validated Split Horizon:
検証済みのスプリットホライズン：
A split-horizon configuration that is authorized by the parents of the affected names and confirmed by the client. Such authorization generally extends to the entire subtree of names below the authorization point.
影響を受けた名前の親によって承認され、クライアントによって確認されたスプリットホリゾン構成。このような承認は、一般に、承認ポイント以下の名前のサブツリー全体にまで及びます。
In this document, the terms "owner" and "operator" are used interchangeably and refer to the individual or entity responsible for the management and maintenance of domains.
このドキュメントでは、「所有者」と「オペレーター」という用語が同じ意味で使用され、ドメインの管理とメンテナンスを担当する個人またはエンティティを参照します。
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.
このドキュメントで説明されているプロトコルは、ドメインの所有者がドメインの分割ホリゾンビューを作成または承認する能力をサポートするように設計されています。このプロトコルは、他のエンティティによって作成されたスプリットホリゾンビューをサポートしていません。したがって、DNSフィルタリングはこのプロトコルによって有効になりません。
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.
このプロトコルは、あらゆるタイプのネットワークに適用できます。エンドポイントでは、ローカルドメインのヒントが実際にドメインによって承認されたことを確認するために、事前の構成は必要ありません。
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. All Special-Use Domain Names are outside the scope of this document and MUST NOT be validated using the mechanism described in this document.
IANA [RFC6761]、特に「home.arpa」、「resolver.arpa。」、「ipv4only.arpa。」、および「local」に登録されているすべての特別使用ドメイン名は、特定のものに固有のものではありません。DNSサーバーの権限。すべての特別なドメイン名は、このドキュメントの範囲外であり、このドキュメントで説明されているメカニズムを使用して検証しないでください。
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.
この仕様の使用は、グローバルDNSにルート化された認証された暗号化とスプリットホリゾンDNS名をサポートするDNSサーバーに限定されています。
This solution seeks to fulfill the following requirements:
このソリューションは、次の要件を満たすことを目指しています。
No loss of security:
セキュリティの損失はありません：
No unauthorized party can impersonate a zone unless they could already do so without the use of this specification.
不正な当事者は、この仕様を使用せずに既にできる場合を除き、ゾーンになりすましません。
Least privilege:
最小特権：
Local resolvers do not hold any secrets that could weaken the security of the public zone if compromised.
ローカルリゾルバーは、侵害された場合、パブリックゾーンのセキュリティを弱める可能性のある秘密を保持しません。
Local zone confidentiality:
ローカルゾーンの機密性：
The specification does not leak local network subdomains to anyone outside of the network.
仕様では、ネットワーク外の誰にでもローカルネットワークサブドメインを漏らしません。
Flexibility:
柔軟性：
The specification can represent and authorize a split DNS zone structure.
仕様は、分割DNSゾーン構造を表現および承認できます。
DNSSEC compatibility:
DNSSEC互換性：
The specification supports DNSSEC-based object security for local zone contents per [RFC9364].
この仕様は、[RFC9364]あたりのローカルゾーンコンテンツのDNSSECベースのオブジェクトセキュリティをサポートします。
A participating network MUST offer one or more encrypted resolvers via DHCP and Router Advertisement options for the Discovery of Network-designated Resolvers (DNR) [RFC9463], Discovery of Designated Resolvers (DDR) [RFC9462], or an equivalent mechanism (see Section 10).
参加ネットワークは、ネットワーク指定リゾルバー（DNR）[RFC9463]の発見のために、DHCPおよびルーター広告オプションを介して1つ以上の暗号化されたリゾルバーを提供する必要があります。）。
To establish local authority, the network MUST convey one or more "authorization claims" to the client. An authorization claim is an abstract structure comprising:
地方自治体を確立するには、ネットワークはクライアントに1つ以上の「承認請求」を伝える必要があります。承認請求は、次のことを含む抽象構造です。
* An Authentication Domain Name (ADN) of a local encrypted resolver.
* ローカル暗号化されたリゾルバーの認証ドメイン名（および）。
* The DNS name of the authorizing parent zone.
* 承認された親ゾーンのDNS名。
* 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 ("*").
* 指定されたローカルリゾルバー（潜在的に親ゾーン全体を含む可能性がある）が主張するこの親ゾーンのサブドメインのセット。親ゾーン全体を請求するために、主張されたサブドメインはアスタリスク記号（ "*"）として表されます。
* A ZONEMD Hash Algorithm (Section 5.3 of [RFC8976]). For interoperability purposes, implementations MUST support the "mandatory to implement" hash algorithms defined in Section 2.2.3 of [RFC8976].
* Zonemdハッシュアルゴリズム（[RFC8976]のセクション5.3）。相互運用性のために、実装は[RFC8976]のセクション2.2.3で定義されているハッシュアルゴリズムを「実装するための必須」をサポートする必要があります。
* A high-entropy salt, up to 255 octets.
* 最大255オクテットの高エントロピー塩。
If the local encrypted resolver is identified by name (e.g., using DNR), that identifying name MUST be the name used in any corresponding authorization claim. Otherwise (e.g., DDR using IP addresses), the resolver MUST present a validatable certificate containing a subjectAltName that matches the authorization claim using the validation techniques for matching as described in [RFC9525].
ローカル暗号化されたリゾルバーが名前（例：DNRを使用）で識別されている場合、その識別名は、対応する承認請求で使用される名前でなければなりません。それ以外の場合（例えば、IPアドレスを使用したDDR）、リゾルバーは、[RFC9525]に記載されているように一致する検証手法を使用して承認請求に一致する主題請求を含む有効な証明書を提示する必要があります。
The network then provides each 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:
ネットワークは、親ゾーンオペレーターに各認証請求を提供します。内容が承認されている場合、親ゾーンオペレーターは次の手順に従って「検証トークン」を計算します。
1. Convert all subdomains into canonical form and sort them in canonical order (Section 6 of [RFC4034]).
1. すべてのサブドメインを標準形式に変換し、標準的な順序で並べ替えます（[RFC4034]のセクション6）。
2. Replace the suffix corresponding to the parent zone with a zero octet.
2. 親ゾーンに対応する接尾辞をゼロオクテットに置き換えます。
3. Let $X be the concatenation of the resulting pseudo-FQDNs.
3. $ xを、結果の擬似fqdnsの連結とします。
4. Let len($SALT) be the number of octets of salt, as a single octet.
4. レン（$塩）を単一のオクテットとして、塩のオクテットの数とします。
5. Let $TOKEN = hash(len($SALT) || $SALT || $X), where "||" denotes concatenation and hash is the ZONEMD Hash Algorithm.
5. $ token = hash（len（$ SALT）|| $ SALT || $ x）、ここで "||"連結を示し、ハッシュはZonemd Hashアルゴリズムです。
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]:
次に、ゾーンオペレーターは、[ドメイン検証テクニック]のセクション5.2および5.3で概説されているベストプラクティスに従って、次の構造で「検証レコード」を公開します。
* Type = TXT
* type = txt
* Owner Name = Concatenation of the ADN, "_splitdns-challenge", and the parent zone name
* 所有者名= ADNの連結、「_splitdns-challenge」、および親ゾーン名
* Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding)
* contents = "key/value"ペア、例えば、 "token = base64url（$ token）"（パディングなし）
By publishing this record, the parent zone authorizes the local encrypted resolver to serve these subdomains authoritatively.
このレコードを公開することにより、親ゾーンは、地元の暗号化されたリゾルバーがこれらのサブドメインを権威あるものに提供することを許可します。
Consider the following authorization claim:
次の承認請求を検討してください。
* ADN = "resolver17.parent.example"
* ADN = "Resolver17.Parent.example"
* Parent = "parent.example"
* parent = "parent.example"
* Subdomains = "payroll.parent.example", "secret.project.parent.example"
* subdomains = "payroll.parent.example"、 "secret.project.parent.example"
* Hash Algorithm = SHA-384 [RFC6234]
* ハッシュアルゴリズム= SHA-384 [RFC6234]
* Salt = "example salt octets (should be random)"
* SALT = "サンプルソルトオクテット（ランダムである必要があります）" "
To approve this claim, the zone operator would publish the following record:
この主張を承認するために、ゾーンオペレーターは次の記録を公開します。
NOTE: '\' line wrapping per RFC 8792
resolver17.parent.example._splitdns-challenge.parent.example. \
IN TXT "token=z1qyK7QWwQPkT-ZmVW-tAQbsNyYenTNBPp5ogYB8S1wesVCR\
-KJDv2eFwfJcWQM"
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 client. This section defines some encodings of the authorization claims.
認証請求は、ネットワークからクライアントに伝えるために、コンクリートの構文にエンコードする必要がある抽象構造です。このセクションでは、承認請求のいくつかのエンコーディングを定義します。
In DHCP, each authorization claim is encoded as a DHCP Authentication option ([RFC3118] and Section 21.11 of [RFC8415]), using the Protocol value 4, "Split-horizon DNS". In DHCPv4 [RFC2131], the mechanism for splitting long options as described in Section 8 of [RFC3396] MUST be used if the 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 MUST be 0x00. The Authentication Information MUST contain the following information, concatenated:
DHCPでは、各承認請求は、プロトコル値4「スプリットホリゾンDNS」を使用して、DHCP認証オプション（[RFC3118]および[RFC8415]のセクション21.11）としてエンコードされます。DHCPV4 [RFC2131]では、認証オプションが255オクテットの最大DHCPV4オプションサイズを超える場合、[RFC3396]のセクション8で説明されている長いオプションを分割するメカニズムを使用する必要があります。アルゴリズムフィールドは、登録値で表されるZonemdハッシュアルゴリズムを提供します。リプレイ検出方法値は0x00でなければなりません。認証情報には、次の情報が含まれている必要があります。
1. The ADN in canonical form.
1. 標準形式のADN。
2. The parent name in canonical form.
2. 標準形式の親名。
3. A one-octet "salt length" field.
3. 1オクテットの「塩の長さ」フィールド。
4. The salt value.
4. 塩値。
5. The $X value as defined in Section 5.
5. セクション5で定義されている$ x値。
When using PvDs [RFC8801], the authorization claims are represented by the PvD Additional Information key "splitDnsClaims", whose value is a JSON array. Each entry in the array MUST be a JSON object with the following structure:
PVD [RFC8801]を使用する場合、承認請求は、PVDの追加情報キー「SplitdnsClaims」によって表されます。配列内の各エントリは、次の構造を持つJSONオブジェクトでなければなりません。
"resolver":
"リゾルバ"：
The ADN as a dot-separated name.
ドット分離名としてのADN。
"parent":
"親"：
The parent zone name as a dot-separated name.
ドット分離名としての親ゾーン名。
"subdomains":
「サブドメイン」：
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 ("*").
標準的な順序で、ペアレントサフィックスが既に削除されているドット分離された名前として、請求されたサブドメインを含むアレイ。親ゾーン全体を請求するために、主張されたサブドメインはアスタリスク記号（ "*"）として表されます。
"algorithm":
"アルゴリズム"：
The hash algorithm, represented by its "Mnemonic" string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of [RFC8976]).
「Zonemd Hashアルゴリズム」レジストリ（[RFC8976]のセクション5.3）の「ニーモニック」文字列で表されるハッシュアルゴリズム。
"salt":
"塩"：
The salt, encoded in base64url [RFC4648].
Base64url [RFC4648]にエンコードされた塩。
Future specifications aiming to define new keys will need to add them to the IANA registry defined in Section 13.3. DNS client implementations will ignore any keys they don't recognize but may also report unknown keys.
新しいキーを定義することを目的とした将来の仕様では、セクション13.3で定義されているIANAレジストリにそれらを追加する必要があります。DNSクライアントの実装は、認識されていないが未知のキーを報告するキーを無視します。
To validate an authorization claim provided by the network, DNS clients MUST resolve the Verification Record for that name. If the resolution produces an RRset containing the expected token for this claim, the client SHALL regard the named resolver as authoritative for the claimed subdomains. Clients MUST ignore any unrecognized keys in the Verification Record.
ネットワークが提供する承認請求を検証するには、DNSクライアントはその名前の検証記録を解決する必要があります。解像度がこのクレームの予想されるトークンを含むRRSETを生成する場合、クライアントは、指定されたリゾルバーを請求されたサブドメインの権威あるものと見なすものとします。クライアントは、検証レコードの認識されていないキーを無視する必要があります。
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.
権限の各検証は、特定のADNにのみ適用されます。ネットワークが複数の暗号化されたリゾルバーを提供する場合、ネットワークが提供するリゾルバーの明確なサブセットに対して、それぞれの主張サブドメインが許可される場合があります。
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.
ゾーンは、「改ざん防止」DNS解像度方法を使用した検証に成功した後、「検証されたスプリットホリゾンゾーン」と呼ばれます。つまり、ローカルネットワークオペレーターによる干渉の対象ではないメソッドです。2つの可能な改ざん防止解像度方法を以下に示します。
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 an encrypted transport. That resolution strategy is considered 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 timeframe, it MUST consider the verification process to have failed.
このメソッドは、暗号化されたトランスポートを介してネットワークの外側のリゾルバーにクエリを送信するデフォルトの解決戦略でクライアントが既に構成されている場合にのみ適用されます。この解決戦略は、応答を変更できるアクターがすでにすべてのユーザーの他のDNS応答を変更できるため、改ざん防止戦略と見なされます。クライアントが合理的な時間枠内で外部リゾルバーから応答を取得できない場合、検証プロセスが失敗したと考える必要があります。
To ensure that this assumption holds, clients MUST NOT 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. The client MAY perform DNSSEC validation for the verification query even if it has disabled DNSSEC validation for other DNS queries.
この仮定が保持されることを確認するために、クライアントは、このリゾルバーを使用するときに適用される受け入れルールを緩和してはなりません。たとえば、クライアントがこのリゾルバーを使用するときに認証されたデータ（AD）ビットをチェックしたり、RRSIGをローカルに検証したりする場合、この目的のためにTXTレコードを解決するときにもそうする必要があります。クライアントは、他のDNSクエリに対してDNSSEC検証を無効にした場合でも、検証クエリに対してDNSSEC検証を実行できます。
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) and performs full DNSSEC validation locally [RFC6698]. The result is processed based on its DNSSEC validation state (Section 4.3 of [RFC4035]):
クライアントは、選択の解決方法を使用して検証レコードを解決し（たとえば、ネットワークが提供するリゾルバーの1つをクエリし、局所的に反復解像度を実行）、局所的に完全なDNSSEC検証を実行します[RFC6698]。結果は、DNSSEC検証状態（[RFC4035]のセクション4.3）に基づいて処理されます。
*Secure*:
*安全な*：
The response is used for validation.
応答は検証に使用されます。
*Bogus* or *Indeterminate*:
*偽*または*不確定*：
The response is rejected, and validation is considered to have failed.
応答は拒否され、検証は失敗したと見なされます。
*Insecure*:
*不安*：
The client SHOULD retry the validation process using a different method, such as the method described in Section 6.1, 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 consider validation to have failed.
クライアントは、セクション6.1で説明した方法など、異なる方法を使用して検証プロセスを再試行して、署名していない名前との互換性を確保する必要があります。クライアントが再試行しないことを選択した場合（たとえば、外部リゾルバーを使用して承認請求を検証するための構成されたポリシーがない）、検証が失敗したと考える必要があります。
When the local zone can be signed with globally trusted keys for the parent zone, support for DNSSEC can be accomplished by simply 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.
親ゾーンのグローバルに信頼できるキーでローカルゾーンに署名できる場合、DNSSECのサポートは、親ゾーンにゾーンカットを配置し、ローカルリゾルバーのDNSKEYに適したDSレコードを含めるだけで達成できます。この構成のゾーンは、この仕様を実装するかどうかにかかわらず、検証スタブと同じように見えます。
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 MAY add a "ds=..." key to the Verification Record whose value is the RDATA of a single DS record, encoded in base64url. This DS record authorizes a DNSKEY whose owner name is "resolver.arpa."
ローカルリゾルバーが親ゾーンに有効なDNSSECプライベートキーを保持することを要求することなくローカルDNS名のDNSSEC検証を有効にするために、親ゾーンは「DS = ...」を追加する場合があります。base64urlでエンコードされたシングルDSレコード。このDSレコードは、所有者の名前が「sloltver.arpa」であるDNSKEYを承認します。
To validate DNSSEC, the client first fetches and validates the Verification Record. If it is valid and contains a "ds" key, the client MAY send a DNSKEY query for "resolver.arpa." to the local encrypted resolver. At least one resulting DNSKEY Resource Record (RR) MUST match the DS RDATA from the "ds" key in the Verification Record. All local resolution results for subdomains in this claim MUST offer RRSIGs that chain to a DNSKEY whose RDATA is identical to one of these approved DNSKEYs.
DNSSECを検証するには、クライアントが最初に確認レコードを取得して検証します。有効であり、「DS」キーが含まれている場合、クライアントは「Resolver.Arpa」のDNSKEYクエリを送信できます。地元の暗号化されたリゾルバーに。少なくとも1つの結果のDNSKEYリソースレコード（RR）は、検証レコードの「DS」キーのDS RDATAを一致させる必要があります。このクレームのサブドメインのすべてのローカル解像度の結果は、RDATAがこれらの承認されたDNSKEYの1つと同じであるDNSKEYにその連鎖を提供する必要があります。
The "ds" key MAY appear multiple times in a single Verification Record, in order to authorize multiple DNSKEYs for this local encrypted resolver.
このローカル暗号化されたリゾルバーの複数のDNSKEYを承認するために、「DS」キーは、単一の検証レコードで複数回表示される場合があります。
Note that when the local resolver does not have a globally trusted DNSKEY, any claimed subdomains MUST be marked as unsigned in the public DNS. Otherwise, local resolution results would be rejected by validating stubs that do not implement this specification.
ローカルリゾルバーがグローバルに信頼できるDNSKEYを持っていない場合、主張されたサブドメインは公開DNSで符号なしでマークされなければならないことに注意してください。それ以外の場合、この仕様を実装しないスタブを検証することにより、ローカル解像度の結果が拒否されます。
NOTE: '\' line wrapping per RFC 8792
;; Parent zone.
$ORIGIN parent.example.
; Parent zone's public Key Signing Key (KSK)
; and 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 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. ...
Figure 1: Example Use of "ds=..."
図1：「ds = ...」の使用例
Consider an organization that operates "example.com" and runs a different version of its global domain on its internal network.
「Example.com」を運営し、内部ネットワーク上でグローバルドメインの異なるバージョンを実行する組織を検討してください。
First, the host and network both need to support one of the discovery mechanisms described in Section 5. Figure 2 shows discovery using information from the DNR and the PvD.
まず、ホストとネットワークはどちらもセクション5で説明した発見メカニズムの1つをサポートする必要があります。図2は、DNRとPVDからの情報を使用した発見を示しています。
Validation is then performed using either an external resolver (Section 8.1) or DNSSEC (Section 8.2).
次に、外部リゾルバー（セクション8.1）またはDNSSEC（セクション8.2）のいずれかを使用して、検証が実行されます。
*Steps 1-2*:
*ステップ1-2*：
The client determines the network's DNS server (dns.example.net) and PvD ID (pvd.example.com) using DNR and a PvD, along with one of the following: DNR Router Solicitation, DHCPv4, or DHCPv6.
クライアントは、DNRとPVDを使用して、ネットワークのDNSサーバー（DNS.Example.net）およびPVD ID（PVD.Example.com）を決定し、次のいずれかとともに、DNRルーター勧誘、DHCPV4、またはDHCPV6を決定します。
*Steps 3-5*:
*ステップ3-5*：
The client connects to dns.example.net using an encrypted transport as indicated in DNR [RFC9463], authenticating the server to its name using TLS (Section 8 of [RFC8310]), and sends it a query for the address of pvd.example.com.
クライアントは、DNR [RFC9463]に示されているように暗号化されたトランスポートを使用してDNS.Example.NETに接続し、TLS（[RFC8310]のセクション8）を使用してサーバーをその名前に認証し、PVD.exampleのアドレスのクエリを送信します。.com。
*Steps 6-7*:
*手順6-7*：
The client connects to the PvD server, validates its certificate, and retrieves the PvD Additional Information indicated by the associated PvD. The JSON object contains:
クライアントはPVDサーバーに接続し、証明書を検証し、関連するPVDで示されたPVDの追加情報を取得します。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"
}]
}
The JSON keys "identifier", "expires", and "prefixes" are defined in [RFC8801].
JSONキー「識別子」、「有効期限」、および「プレフィックス」は[RFC8801]で定義されています。
+---------+ +--------------------+ +------------+ +--------+
| 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": [...] } | | | |
| |---------------------------------/ | | |
Figure 2: An Example of Learning Local Claims of DNS Authority
図2：DNS当局の地元の主張を学ぶ例
Figure 3 shows the steps performed to verify the local claims of DNS authority using an external resolver.
図3は、外部解像度を使用してDNS当局のローカルクレームを検証するために実行された手順を示しています。
*Steps 1-2*:
*ステップ1-2*：
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.
クライアントは、暗号化されたDNS接続を外部リゾルバーに使用して、検証レコードのTXTクエリを発行します。TXTルックアップは、クレームに一致するトークンを返します。
*Step 3*:
*ステップ3*：
The client has validated that example.com has authorized dns.example.net to serve example.com. When the client connects using an encrypted transport as indicated in DNR [RFC9463], it will authenticate the server to its name using TLS (Section 8 of [RFC8310]) and send queries to resolve any names that fall within the claimed zones.
クライアントは、example.comがdns.example.netにexample.comを提供することを許可したことを検証しました。クライアントがDNR [RFC9463]に示されているように暗号化されたトランスポートを使用して接続すると、TLS（[RFC8310]のセクション8）を使用してサーバーを認証し、クエリを送信して、主張されたゾーン内に該当する名前を解決します。
+---------+ +--------------------+ +----------+
| 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) | |
|----------------------------------------->| |
| | |
Figure 3: Verifying Claims Using an External Resolver
図3：外部リゾルバを使用したクレームの検証
Figure 4 shows the steps performed to verify the local claims of DNS authority using DNSSEC.
図4は、DNSSECを使用してDNS当局のローカルクレームを検証するために実行された手順を示しています。
*Steps 1-2*:
*ステップ1-2*：
The DNSSEC-validating client queries the 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.
DNSSECの検証クライアントは、ネットワークの暗号化されたリゾルバーをクエリして、検証レコードのTXTクエリを発行します。TXTルックアップは、予想されるトークンを含む署名された応答を返します。クライアントは、ローカルで完全なDNSSEC検証を実行します。
*Step 3*:
*ステップ3*：
If the DNSSEC validation is successful and the token matches, then this authorization claim is validated. Once the client connects using an encrypted transport as indicated in DNR [RFC9463], it will authenticate the server to its name using TLS (Section 8 of [RFC8310]) and send queries to resolve any names that fall within the claimed zones.
DNSSEC検証が成功し、トークンが一致する場合、この承認請求は検証されます。DNR [RFC9463]に示されているように、暗号化されたトランスポートを使用してクライアントが接続すると、TLS（[RFC8310]のセクション8）を使用してサーバーを認証し、クエリを送信して、クレームゾーン内に該当する名前を解決します。
+---------+ +--------------------+
| 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) |
|-------------------------------------------------------------->|
| |
Figure 4: An Example of Verifying Claims Using DNSSEC
図4：DNSSECを使用してクレームを検証する例
In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., internal.example.com). In this configuration, the message flow is similar to the flow described in Section 8.1, except that queries for hosts not within the subdomain (e.g., www.example.com) are sent to the external resolver rather than the resolver for internal.example.com.
多くのスプリットホリゾンの展開では、すべての非公開ドメイン名が別のチャイルドゾーン（internal.example.comなど）に配置されます。この構成では、メッセージフローはセクション8.1で説明されているフローに似ています。ただし、サブドメイン内ではないホストのクエリ（www.example.comなど）は、内部のリゾルバーではなく外部リゾルバーに送信されます。com。
As specified in Section 8.1, the internal DNS server will need a certificate signed by a Certification Authority (CA) trusted by the client.
セクション8.1で指定されているように、内部DNSサーバーには、クライアントが信頼する認定機関（CA）が署名する証明書が必要です。
Although placing internal domains inside a child domain is not necessary to prevent leakage, such placement reduces the frequency of changes to the Verification 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".
子ドメイン内に内部ドメインを配置することは漏れを防ぐために必要ではありませんが、そのような配置は検証記録の変化の頻度を減らします。このドキュメントでは、内部ドメインがネットワークによって宣伝されているローカルドメインのヒントの子ゾーンに保持されることを推奨しています。たとえば、PVD「DNSZONES」エントリが「internal.example.com」であり、ネットワークが提供するDNSリゾルバーが「ns1.internal.example.com」である場合、ネットワーク演算子は内部ドメイン名を「private1.internal」として構成できます。.example.com "、" private2.internal.example.com "など。ネットワーク指定のリゾルバーを使用して、ローカルドメインヒントのサブドメインを解決するために使用されます。
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]. The VPN client can use the mechanism defined in Section 6 to validate that the discovered encrypted DNS resolver is authorized to answer for the claimed subdomains.
エンドポイントがVPNトンネルを使用し、トンネルがIPSECである場合、VPNサービスプロバイダーによってホストされている暗号化されたDNSリゾルバーは、[RFC9464]で定義されたENCDNS_IP* IKEV2構成ペイロード属性タイプを使用してエンドポイントによって安全に発見できます。VPNクライアントは、セクション6で定義されているメカニズムを使用して、発見された暗号化されたDNSリゾルバーが請求されたサブドメインに対して回答することを許可されていることを検証できます。
Other VPN tunnel types have similar configuration capabilities. Note that those capabilities are not discussed in this document.
他のVPNトンネルタイプには、同様の構成機能があります。これらの機能はこのドキュメントでは説明されていないことに注意してください。
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 fetch the Verification Records again and repeat the verification procedure. This ensures the availability of updated and valid Verification Records.
検証レコードは、有効期限が切れるまで有効です。有効期限は、生きる時間（TTL）またはDNSSECの署名妥当性期間が終了するときに発生します。確認レコードの有効期限の直前に、クライアントは検証レコードを再度取得し、検証手順を繰り返す必要があります。これにより、更新された有効な検証レコードの可用性が保証されます。
A new Verification Record must be added to the RRset before the corresponding authorization claim is updated. After the claim is updated, the following procedures can be used:
対応する承認請求が更新される前に、新しい検証レコードをRRSetに追加する必要があります。クレームが更新された後、次の手順を使用できます。
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. 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.
1. DHCP再構成は、以前にDHCPクライアントと通信したDHCPサーバーによって開始され、DHCPクライアントが再構成メッセージをリッスンするために交渉し、DHCPクライアントに更新された認証請求を動的に要求するように促すことができます。このプロセスにより、クライアントが現在のリースが完了し、新しいレンジを要求する必要があり、リースの更新がDHCPサーバーによって駆動されるようになります。
2. The sequence number in the RA PvD Option can be incremented, requiring clients to fetch PvD Additional Information from the HTTPS server due to the updated sequence number in the new RA (Section 4.1 of [RFC8801]).
2. RA PVDオプションのシーケンス番号は増加することができ、新しいRA（[RFC8801]のセクション4.1）の更新されたシーケンス番号のために、クライアントがHTTPSサーバーからPVD追加情報を取得する必要があります。
3. The old Verification Record needs to be maintained until the DHCP lease or PvD Additional Information expires.
3. DHCPリースまたはPVDの追加情報が期限切れになるまで、古い検証記録を維持する必要があります。
The ADNs of authorized local encrypted resolvers are revealed in the owner names of Verification Records. This makes it easier for domain owners to understand which resolvers they are currently authorizing to 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 secret subdomain. To mitigate the impact of such leakage, local resolvers should be given names that do not reveal any sensitive information.
認定されたローカル暗号化されたリゾルバーのADNは、検証レコードの所有者名に明らかにされています。これにより、ドメインの所有者は、現在分割DNSの実装を許可しているリゾルバーを理解しやすくなります。ただし、ローカル暗号化されたリゾルバーの名前に機密情報が含まれているか、秘密のサブドメインの一部である場合、これは機密性の問題を作成する可能性があります。このような漏れの影響を緩和するには、機密情報を明らかにしない名前の名前を指定する必要があります。
The security properties of hashing algorithms are not fixed. Algorithm agility (see [RFC7696]) is achieved by providing implementations with the flexibility to choose hashing algorithms from the "ZONEMD Hash Algorithms" registry (Section 5.3 of [RFC8976]).
ハッシュアルゴリズムのセキュリティプロパティは固定されていません。アルゴリズムの俊敏性（[RFC7696]を参照）は、「Zonemd Hashアルゴリズム」レジストリ（[RFC8976のセクション5.3]）からハッシュアルゴリズムを選択できる柔軟性を実装に提供することにより実現されます。
The entropy of a salt depends on a high-quality pseudorandom number generator. For further discussion on random number generation, see [RFC4086]. The salt MUST be regenerated whenever the authorization claim is updated.
塩のエントロピーは、高品質の擬似ランダム数ジェネレーターに依存します。乱数生成に関する詳細については、[RFC4086]を参照してください。承認請求が更新されるたびに、塩を再生する必要があります。
IANA has added the following entry to the "Protocol Name Space Values" registry in the "Dynamic Host Configuration Protocol (DHCP) Authentication Option Name Spaces" registry group:
IANAは、「ダイナミックホスト構成プロトコル（DHCP）認証オプション名スペース」レジストリグループに「プロトコル名スペース値」レジストリに次のエントリを追加しました。
Value:
値：
4
4
Description:
説明：
Split-horizon DNS
スプリットホリゾンDNS
Reference:
参照：
RFC 9704
RFC 9704
IANA has added the following entry to the "Additional Information PvD Keys" registry in the "Provisioning Domains (PvDs)" registry group:
IANAは、「プロビジョニングドメイン（PVD）」レジストリグループの「追加情報PVDキー」レジストリに次のエントリを追加しました。
JSON key:
JSONキー：
splitDnsClaims
splitdnsclaims
Description:
説明：
Verifiable locally served domains
検証可能なローカルで提供されるドメイン
Type:
タイプ：
Array of Objects
オブジェクトの配列
Example:
例：
[{
"resolver": "dns.example.net",
"parent": "example.com",
"subdomains": ["sub"],
"algorithm": "SHA384",
"salt": "abc...123"
}]
Reference:
参照：
RFC 9704
RFC 9704
IANA has created a new registry called "PvD Split DNS Claims" within the "Provisioning Domains (PvDs)" registry 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 Section 5.2.2, are listed below and have been added to the registry:
IANAは、「プロビジョニングドメイン（PVD）」レジストリグループ内で「PVDスプリットDNSクレーム」と呼ばれる新しいレジストリを作成しました。この新しいレジストリは、splitdnsclaims JSONキーの下でサブディクショナリで使用するJSONキーを留保します。セクション5.2.2で説明したように、このレジストリの最初の内容を以下に示し、レジストリに追加されました。
+==========+================+=======+===================+=========+
|JSON key | Description |Type | Example |Reference|
+==========+================+=======+===================+=========+
|resolver | The |String | "dns.example.net" |RFC 9704 |
| | Authentication | | | |
| | Domain Name | | | |
+----------+----------------+-------+-------------------+---------+
|parent | The parent |String | "example.com" |RFC 9704 |
| | zone name | | | |
+----------+----------------+-------+-------------------+---------+
|subdomains| An array |Array | ["sub"] |RFC 9704 |
| | containing the |of | | |
| | claimed |Strings| | |
| | subdomains | | | |
+----------+----------------+-------+-------------------+---------+
|algorithm | The hash |String | "SHA384" |RFC 9704 |
| | algorithm | | | |
+----------+----------------+-------+-------------------+---------+
|salt | The salt |String | "abc...123" |RFC 9704 |
| | (base64url) | | | |
+----------+----------------+-------+-------------------+---------+
Table 1: Split DNS Claims
表1：DNSの分割クレーム
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.
このドキュメントで定義されているキーは必須です。キーの新しい割り当ては、このドキュメントで説明されているメカニズムの目的でオプションと見なされます。
New assignments in the "PvD Split DNS Claims" registry will be administered by IANA through Expert Review [RFC8126]. Experts are requested to ensure that defined keys do not overlap in names or semantics.
「PVD分割DNSクレーム」レジストリの新しい割り当ては、専門家レビュー[RFC8126]を通じてIANAによって管理されます。専門家は、定義されたキーが名前やセマンティクスに重複しないようにするように要求されます。
It is suggested that multiple designated experts be appointed for registry change requests.
複数の指定された専門家がレジストリの変更リクエストに任命されることをお勧めします。
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.
指定された専門家が適用すべき基準には、提案された登録が既存のエントリを複製するかどうか、登録の説明が明確であるかどうかを決定することが含まれ、このレジストリの目的に適合します。
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.
登録要求は、1人以上の指定された専門家のアドバイスに関する3週間のレビュー期間内に評価されます。レビュー期間内に、指定された専門家は登録要求を承認または拒否し、この決定をIANAに伝えます。拒否には説明を含める必要があります。必要に応じて、リクエストを成功させる方法に関する提案が含まれます。
IANA has added the following entry to the "Underscored and Globally Scoped DNS Node Names" registry in the "Domain Name System (DNS) Parameters" registry group:
IANAは、「ドメイン名システム（DNS）パラメーター」レジストリグループの「Underced and Global Scoped DNSノード名」レジストリに次のエントリを追加しました。
RR Type:
RRタイプ：
TXT
TXT
_NODE NAME:
_Node名：
_splitdns-challenge
_splitdns-challenge
Reference:
参照：
RFC 9704
RFC 9704
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<https://www.rfc-editor.org/info/rfc3118>.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
DOI 10.17487/RFC3396, November 2002,
<https://www.rfc-editor.org/info/rfc3396>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
RFC 8801, DOI 10.17487/RFC8801, July 2020,
<https://www.rfc-editor.org/info/rfc8801>.
[RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", RFC 8976,
DOI 10.17487/RFC8976, February 2021,
<https://www.rfc-editor.org/info/rfc8976>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[DOMAIN-VERIFICATION-TECHNIQUES]
Sahib, S., Huque, S., Wouters, P., and E. Nygren, "Domain
Control Validation using DNS", Work in Progress, Internet-
Draft, draft-ietf-dnsop-domain-verification-techniques-06,
21 October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-domain-verification-techniques-06>.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702,
DOI 10.17487/RFC4702, October 2006,
<https://www.rfc-editor.org/info/rfc4702>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
DOI 10.17487/RFC5986, September 2010,
<https://www.rfc-editor.org/info/rfc5986>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<https://www.rfc-editor.org/info/rfc6731>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8598, DOI 10.17487/RFC8598, May 2019,
<https://www.rfc-editor.org/info/rfc8598>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to
a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
<https://www.rfc-editor.org/info/rfc8806>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
Jensen, "Discovery of Designated Resolvers", RFC 9462,
DOI 10.17487/RFC9462, November 2023,
<https://www.rfc-editor.org/info/rfc9462>.
[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC9463, November 2023,
<https://www.rfc-editor.org/info/rfc9463>.
[RFC9464] Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov,
"Internet Key Exchange Protocol Version 2 (IKEv2)
Configuration for Encrypted DNS", RFC 9464,
DOI 10.17487/RFC9464, November 2023,
<https://www.rfc-editor.org/info/rfc9464>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Michael Richardson, Bernie Volz, Éric Vyncke, and Vinny Parla for the discussion and comments.
Mohamed Boucadair、Jim Reid、Tommy Pauly、Paul Vixie、Michael Richardson、Bernie Volz、Eric Vyncke、およびVinny Parlaに議論とコメントに感謝します。
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.
Opsdirレビューについては、Tianran Zhou、DnsdirレビューのAnthony Somerset、Secdir ReviewのWatson Ladd、IntdirレビューのBob Halley、Genart ReviewのMallory Knodelに感謝します。
Thanks to Mohamed Boucadair for the Shepherd review.
シェパードレビューをしてくれたMohamed Boucadairに感謝します。
Tirumaleswar Reddy.K
Nokia
India
Email: kondtir@gmail.com
Dan Wing
Citrix Systems, Inc.
United States of America
Email: danwing@gmail.com
Kevin Smith
Vodafone Group
One Kingdom Street
London
United Kingdom
Email: kevin.smith@vodafone.com
Benjamin Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net