[要約] RFC 9460 は、SVCBとHTTPS DNSリソースレコードを定義し、ネットワークサービスへの接続情報の検索を容易にします。SVCBレコードは複数のエンドポイントからサービスを提供し、将来の使用にも対応可能であり、パフォーマンスとプライバシーの両方に潜在的な利点を提供します。
Internet Engineering Task Force (IETF) B. Schwartz
Request for Comments: 9460 Meta Platforms, Inc.
Category: Standards Track M. Bishop
ISSN: 2070-1721 E. Nygren
Akamai Technologies
November 2023
This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.
このドキュメントは、「SVCB」（「サービスバインディング」）および「HTTPS」DNSリソースレコード（RR）タイプを指定して、HTTPオリジンなどのネットワークサービスに接続するために必要な情報の検索を容易にします。SVCBレコードにより、それぞれに関連するパラメーター（トランスポートプロトコル構成など）を備えた複数の代替エンドポイントからサービスを提供することができ、将来の用途（TLS ClientHelloを暗号化するためのキーなど）をサポートするために拡張可能です。また、CNAMEでは不可能であるApexドメインのエイリアシングも可能にします。HTTPS RRは、HTTPで使用するSVCBのバリエーションです（RFC 9110、「HTTPセマンティクス」を参照）。接続を確立しようとする前にクライアントにより多くの情報を提供することにより、これらのレコードはパフォーマンスとプライバシーの両方に潜在的な利点を提供します。
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/rfc9460.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9460で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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
1.1. Goals
1.2. Overview of the SVCB RR
1.3. Terminology
2. The SVCB Record Type
2.1. Zone-File Presentation Format
2.2. RDATA Wire Format
2.3. SVCB Query Names
2.4. Interpretation
2.4.1. SvcPriority
2.4.2. AliasMode
2.4.3. ServiceMode
2.5. Special Handling of "." in TargetName
2.5.1. AliasMode
2.5.2. ServiceMode
3. Client Behavior
3.1. Handling Resolution Failures
3.2. Clients Using a Proxy
4. DNS Server Behavior
4.1. Authoritative Servers
4.2. Recursive Resolvers
4.2.1. DNS64
4.3. General Requirements
4.4. EDNS Client Subnet (ECS)
5. Performance Optimizations
5.1. Optimistic Pre-connection and Connection Reuse
5.2. Generating and Using Incomplete Responses
6. SVCB-Compatible RR Types
7. Initial SvcParamKeys
7.1. "alpn" and "no-default-alpn"
7.1.1. Representation
7.1.2. Use
7.2. "port"
7.3. "ipv4hint" and "ipv6hint"
7.4. "mandatory"
8. ServiceMode RR Compatibility and Mandatory Keys
9. Using Service Bindings with HTTP
9.1. Query Names for HTTPS RRs
9.2. Comparison with Alt-Svc
9.2.1. ALPN Usage
9.2.2. Untrusted Channels
9.2.3. Cache Lifetime
9.2.4. Granularity
9.3. Interaction with Alt-Svc
9.4. Requiring Server Name Indication
9.5. HTTP Strict Transport Security (HSTS)
9.6. Use of HTTPS RRs in Other Protocols
10. Zone Structures
10.1. Structuring Zones for Flexibility
10.2. Structuring Zones for Performance
10.3. Operational Considerations
10.4. Examples
10.4.1. Protocol Enhancements
10.4.2. Apex Aliasing
10.4.3. Parameter Binding
10.4.4. Multi-CDN Configuration
10.4.5. Non-HTTP Uses
11. Interaction with Other Standards
12. Security Considerations
13. Privacy Considerations
14. IANA Considerations
14.1. SVCB RR Type
14.2. HTTPS RR Type
14.3. New Registry for Service Parameters
14.3.1. Procedure
14.3.2. Initial Contents
14.4. Other Registry Updates
15. References
15.1. Normative References
15.2. Informative References
Appendix A. Decoding Text in Zone Files
A.1. Decoding a Comma-Separated List
Appendix B. HTTP Mapping Summary
Appendix C. Comparison with Alternatives
C.1. Differences from the SRV RR Type
C.2. Differences from the Proposed HTTP Record
C.3. Differences from the Proposed ANAME Record
C.4. Comparison with Separate RR Types for AliasMode and
ServiceMode
Appendix D. Test Vectors
D.1. AliasMode
D.2. ServiceMode
D.3. Failure Cases
Acknowledgments and Related Proposals
Authors' Addresses
The SVCB ("Service Binding") and HTTPS resource records (RRs) provide clients with complete instructions for access to a service. This information enables improved performance and privacy by avoiding transient connections to a suboptimal default server, negotiating a preferred protocol, and providing relevant public keys.
SVCB（「サービスバインディング」）およびHTTPSリソースレコード（RRS）は、サービスへのアクセスのための完全な指示をクライアントに提供します。この情報により、最適下のデフォルトサーバーへの過渡的な接続を回避し、優先プロトコルの交渉、関連するパブリックキーを提供することにより、パフォーマンスとプライバシーの改善が可能になります。
For example, HTTP clients currently resolve only A and/or AAAA records for the origin hostname, learning only its IP addresses. If an HTTP client learns more about the origin before connecting, it may be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted ClientHello [ECH], or switch to an operationally preferable endpoint. It is highly desirable to minimize the number of round trips and lookups required to learn this additional information.
たとえば、HTTPクライアントは現在、Origin HostNameのAおよび/またはAAAAレコードのみを解決し、IPアドレスのみを学習しています。HTTPクライアントが接続する前にオリジンについてさらに学習した場合、「HTTP」 "URLを「HTTPS」にアップグレードしたり、HTTP/3または暗号化されたClientHello [ECH]を有効にしたり、動作的に好ましいエンドポイントに切り替えることができる場合があります。この追加情報を学習するために必要な往復と検索の数を最小限に抑えることが非常に望ましいです。
The SVCB and HTTPS RRs also help when the operator of a service wishes to delegate operational control to one or more other domains, e.g., aliasing the origin "https://example.com" to a service operator endpoint at "svc.example.net". While this case can sometimes be handled by a CNAME, that does not cover all use cases. CNAME is also inadequate when the service operator needs to provide a bound collection of consistent configuration parameters through the DNS (such as network location, protocol, and keying information).
SVCBおよびHTTPS RRSは、サービスのオペレーターがオペレーショナルコントロールを1つ以上の他のドメインに委任したい場合に役立ちます。ネット"。このケースはCNAMEによって処理される場合がありますが、すべてのユースケースをカバーするわけではありません。また、サービスオペレーターがDNSを介して一貫した構成パラメーターのバインドコレクション（ネットワークの場所、プロトコル、キーイング情報など）を提供する必要がある場合、CNAMEも不十分です。
This document first describes the SVCB RR as a general-purpose RR that can be applied directly and efficiently to a wide range of services (Section 2). It also describes the rules for defining other SVCB-compatible RR types (Section 6), starting with the HTTPS RR type (Section 9), which provides improved efficiency and convenience with HTTP by avoiding the need for an Attrleaf label [Attrleaf] (Section 9.1).
このドキュメントでは、最初にSVCB RRを、広範囲のサービスに直接かつ効率的に適用できる汎用RRとして説明します（セクション2）。また、HTTPS RRタイプ（セクション9）から始まる他のSVCB互換RRタイプ（セクション6）を定義するためのルールについても説明します。9.1）。
The SVCB RR has two modes: 1) "AliasMode", which simply delegates operational control for a resource and 2) "ServiceMode", which binds together configuration information for a service endpoint. ServiceMode provides additional key=value parameters within each RDATA set.
SVCB RRには2つのモードがあります。1）「AliAsmode」は、単にリソースのオペレーショナルコントロールを委任し、2）「サービスエンドポイントの構成情報を結合する」「ServiceMode」。ServiceModeは、各rdataセット内に追加のキー=値パラメーターを提供します。
The goal of the SVCB RR is to allow clients to resolve a single additional DNS RR in a way that:
SVCB RRの目標は、クライアントが次の方法で単一の追加のDNS RRを解決できるようにすることです。
* Provides alternative endpoints that are authoritative for the service, along with parameters associated with each of these endpoints.
* これらの各エンドポイントに関連付けられたパラメーターとともに、サービスに対して権威ある代替エンドポイントを提供します。
* Does not assume that all alternative endpoints have the same parameters or capabilities, or are even operated by the same entity. This is important, as DNS does not provide any way to tie together multiple RRsets for the same name. For example, if "www.example.com" is a CNAME alias that switches between one of three Content Delivery Networks (CDNs) or hosting environments, successive queries for that name may return records that correspond to different environments.
* すべての代替エンドポイントが同じパラメーターまたは機能を持っているか、同じエンティティによって運用されているとも想定していません。DNSは同じ名前の複数のrrsetを結び付ける方法を提供しないため、これは重要です。たとえば、「www.example.com」が3つのコンテンツ配信ネットワーク（CDN）またはホスティング環境のいずれかを切り替えるCNAMEエイリアスである場合、その名前の連続したクエリは、異なる環境に対応するレコードを返すことができます。
* Enables CNAME-like functionality at a zone apex (such as "example.com") for participating protocols and generally enables extending operational authority for a service identified by a domain name to other instances with alternate names.
* 参加プロトコルのゾーンアペックス（「Example.com」など）でCNAME-LIKE機能を有効にし、一般に、ドメイン名で識別されたサービスの運用上の権限を代替名を持つ他のインスタンスに拡張できるようにします。
Additional goals specific to HTTPS RRs and the HTTP use cases include:
HTTPS RRSおよびHTTPユースケースに固有の追加の目標は次のとおりです。
* Connecting directly to HTTP/3 (QUIC transport) alternative endpoints [HTTP/3].
* HTTP/3（QUIC Transport）の代替エンドポイント[HTTP/3]に直接接続します。
* Supporting non-default TCP and UDP ports.
* 非デフォルトTCPおよびUDPポートのサポート。
* Enabling SRV-like benefits (e.g., apex aliasing, as mentioned above) for HTTP, where SRV [SRV] has not been widely adopted.
* SRV [SRV]が広く採用されていないHTTPのSRVのような利点（上記のように、上記のApexエイリアシングなど）を有効にすること。
* Providing an indication signaling that the "https" scheme should be used instead of "http" for all HTTP requests to this host and port, similar to HTTP Strict Transport Security [HSTS] (see Section 9.5).
* HTTP Strict Transport Security [HSTS]と同様に、このホストとポートへのすべてのHTTP要求の「HTTP」スキームの代わりに「HTTPS」スキームを「HTTP」ではなく使用する必要があることを示す指示を提供します（セクション9.5を参照）。
* Enabling the conveyance of Encrypted ClientHello keys [ECH] associated with an alternative endpoint.
* 代替エンドポイントに関連付けられた暗号化されたClienthelloキー[ECH]の運搬を有効にします。
This subsection briefly describes the SVCB RR with forward references to the full exposition of each component. (As discussed in Section 6, this all applies equally to the HTTPS RR, which shares the same encoding, format, and high-level semantics.)
このサブセクションでは、各コンポーネントの完全な博覧会への前方参照を持つSVCB RRについて簡単に説明します。（セクション6で説明したように、これはすべて、同じエンコード、形式、および高レベルのセマンティクスを共有するHTTPS RRに等しく適用されます。）
The SVCB RR has two modes: 1) AliasMode (Section 2.4.2), which aliases a name to another name and 2) ServiceMode (Section 2.4.3), which provides connection information bound to a service endpoint domain. Placing both forms in a single RR type allows clients to fetch the relevant information with a single query (Section 2.3).
SVCB RRには2つのモードがあります。1）AliAsmode（セクション2.4.2）、名前は別名に名前を付け、2）ServiceMode（セクション2.4.3）を使用して、サービスエンドポイントドメインにバインドされた接続情報を提供します。両方のフォームを単一のRRタイプに配置すると、クライアントは単一のクエリ（セクション2.3）で関連情報を取得できます。
The SVCB RR has two required fields and one optional field. The fields are:
SVCB RRには、必要な2つのフィールドと1つのオプションフィールドがあります。フィールドは次のとおりです。
SvcPriority (Section 2.4.1):
svcpriority（セクション2.4.1）：
The priority of this record (relative to others, with lower values preferred). A value of 0 indicates AliasMode.
このレコードの優先順位（他のレコードと比較して、低い値が好ましい）。0の値は、aliASMODEを示します。
TargetName:
TargetName：
The domain name of either the alias target (for AliasMode) or the alternative endpoint (for ServiceMode).
エイリアスターゲット（AliASMODEの場合）または代替エンドポイント（ServiceModeの場合）のドメイン名。
SvcParams (optional):
svcparams（オプション）：
A list of key=value pairs describing the alternative endpoint at TargetName (only used in ServiceMode and otherwise ignored). SvcParams are described in Section 2.1.
TargetNameでの代替エンドポイントを説明するキー=値ペアのリスト（ServiceModeでのみ使用され、その他の無視されます）。SVCParamsはセクション2.1で説明されています。
Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records) and return them in the Additional section of the response (Section 4.2). Clients either use responses included in the Additional section returned by the recursive resolver or perform necessary SVCB, A, and AAAA record resolutions (Section 3). DNS authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional section to responses for a SVCB query (Section 4.1).
DNSの再帰リゾルバーの協力は、その後のレコード解像度（SVCB、A、およびAAAAレコードの場合）を実行し、応答の追加セクション（セクション4.2）でそれらを返します。クライアントは、再帰リゾルバーによって返された追加セクションに含まれる応答を使用するか、必要なSVCB、A、およびAAAAレコード解決策を実行します（セクション3）。DNSの権威あるサーバーは、SVCBクエリの応答の追加セクションで、Bailiwick In-Bailiwick SVCB、A、AAAA、およびCNAMEレコードを添付できます（セクション4.1）。
In ServiceMode, the SvcParams of the SVCB RR provide an extensible data model for describing alternative endpoints that are authoritative for a service, along with parameters associated with each of these alternative endpoints (Section 7).
ServiceModeでは、SVCB RRのSVCPARAMSは、これらの各代替エンドポイントに関連付けられたパラメーターとともに、サービスに対して権威ある代替エンドポイントを記述するための拡張可能なデータモデルを提供します（セクション7）。
For HTTP use cases, the HTTPS RR (Section 9) enables many of the benefits of Alt-Svc [AltSvc] without waiting for a full HTTP connection initiation (multiple round trips) before learning of the preferred alternative, and without necessarily revealing the user's intended destination to all entities along the network path.
HTTPユースケースの場合、HTTPS RR（セクション9）は、優先代替を学ぶ前に完全なHTTP接続開始（複数のラウンドトリップ）を待つことなく、ユーザーを必ずしも明らかにすることなく、ALT-SVC [AltSVC]の多くの利点を可能にします。ネットワークパスに沿ったすべてのエンティティに目的の目的地。
Terminology in this document is based on the common case where the SVCB record is used to access a resource identified by a URI whose authority field contains a DNS hostname as the host.
このドキュメントの用語は、SVCBレコードを使用して、権限フィールドがホストとしてDNSホスト名を含むURIによって識別されるリソースにアクセスするために使用される一般的なケースに基づいています。
* The "service" is the information source identified by the authority and scheme of the URI, capable of providing access to the resource. For "https" URIs, the "service" corresponds to an "origin" [RFC6454].
* 「サービス」は、リソースへのアクセスを提供できるURIの権限とスキームによって特定された情報源です。「https」urisの場合、「サービス」は「起源」に対応しています[RFC6454]。
* The "service name" is the host portion of the authority.
* 「サービス名」は当局のホスト部分です。
* The "authority endpoint" is the authority's hostname and a port number implied by the scheme or specified in the URI.
* 「機関のエンドポイント」は、当局のホスト名と、スキームによって暗示される、またはURIで指定されたポート番号です。
* An "alternative endpoint" is a hostname, port number, and other associated instructions to the client on how to reach an instance of a service.
* 「代替エンドポイント」は、サービスのインスタンスに到達する方法に関するホスト名、ポート番号、およびその他の関連する手順です。
Additional DNS terminology intends to be consistent with [DNSTerm].
追加のDNS用語は、[dnsterm]と一致することを意図しています。
SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, and future RR types that share SVCB's formats and registry are collectively known as SVCB-compatible RR types. The contraction "SVCB" is also used to refer to this system as a whole.
SVCBは「サービスバインディング」の収縮です。SVCBのフォーマットとレジストリを共有するSVCB RR、HTTPS RR、および将来のRRタイプは、SVCB互換RRタイプとして総称されます。収縮「SVCB」は、このシステム全体を参照するためにも使用されます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The SVCB DNS RR type (RR type 64) is used to locate alternative endpoints for a service.
SVCB DNS RRタイプ（RRタイプ64）は、サービスの代替エンドポイントを特定するために使用されます。
The algorithm for resolving SVCB records and associated address records is specified in Section 3.
SVCBレコードと関連するアドレスレコードを解決するためのアルゴリズムは、セクション3で指定されています。
Other SVCB-compatible RR types can also be defined as needed (see Section 6). In particular, the HTTPS RR (RR type 65) provides special handling for the case of "https" origins as described in Section 9.
他のSVCB互換RRタイプも、必要に応じて定義できます（セクション6を参照）。特に、HTTPS RR（RRタイプ65）は、セクション9で説明されている「HTTPS」起源の場合の特別な取り扱いを提供します。
SVCB RRs are extensible by a list of SvcParams, which are pairs consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a registered number. Values are in a format specific to the SvcParamKey. Each SvcParam has a specified presentation format (used in zone files) and wire encoding (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys and their formats are defined in Section 7.
SVCB RRは、SVCParamkeyとSVCParamValueで構成されるペアであるSVCParamsのリストによって拡張可能です。各SVCParamkeyには、プレゼンテーション名と登録番号があります。値は、SVCParamkeyに固有の形式です。各SVCParamには、指定されたプレゼンテーション形式（ゾーンファイルで使用）とワイヤーエンコード（ドメイン名、バイナリデータ、または数値）があります。最初のSVCParamkeysとその形式は、セクション7で定義されています。
The presentation format <RDATA> of the record ([RFC1035], Section 5.1) has the form:
レコード（[RFC1035]、セクション5.1）のプレゼンテーション形式<rdata>には次の形式があります。
SvcPriority TargetName SvcParams
The SVCB record is defined specifically within the Internet ("IN") Class ([RFC1035], Section 3.2.4).
SVCBレコードは、インターネット（ "in"）クラス（[RFC1035]、セクション3.2.4）内で特異的に定義されています。
SvcPriority is a number in the range 0-65535, TargetName is a <domain-name> ([RFC1035], Section 5.1), and the SvcParams are a whitespace-separated list with each SvcParam consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. SvcParamKeys are registered by IANA (Section 14.3).
SVCPRIORITYは0-65535の範囲の数字であり、TargetNameは<Domain-Name>（[RFC1035]、セクション5.1）であり、SVCParamsはSVCParamkey = SVCParamkeyペアまたはスタンダルノーネーネのペアで構成される各SVCPARAMを備えた白人分離リストです。svcparamkey。SVCParamkeysはIANAによって登録されています（セクション14.3）。
Each SvcParamKey SHALL appear at most once in the SvcParams. In presentation format, SvcParamKeys are lowercase alphanumeric strings. Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-". In ABNF [RFC5234],
各SVCParamkeyは、SVCParamsにせいぜい1回表示されます。プレゼンテーション形式では、SVCParamkeysは小文字の英数字の弦です。キー名には、「A」 - 「Z」、「0」 - 「9」、および「 - 」の範囲からの1〜63文字が含まれています。ABNF [RFC5234]で、
alpha-lc = %x61-7A ; a-z
SvcParamKey = 1*63(alpha-lc / DIGIT / "-")
SvcParam = SvcParamKey ["=" SvcParamValue]
SvcParamValue = char-string ; See Appendix A.
value = *OCTET ; Value before key-specific parsing
The SvcParamValue is parsed using the character-string decoding algorithm (Appendix A), producing a value. The value is then validated and converted into wire format in a manner specific to each key.
SVCParamValueは、文字弦デコードアルゴリズム（付録A）を使用して解析され、値を生成します。次に、値が検証され、各キーに固有の方法でワイヤ形式に変換されます。
When the optional "=" and SvcParamValue are omitted, the value is interpreted as empty.
オプションの "="とsvcparamvalueが省略されている場合、値は空であると解釈されます。
Arbitrary keys can be represented using the unknown-key presentation format "keyNNNNN" where NNNNN is the numeric value of the key type without leading zeros. A SvcParam in this form SHALL be parsed as specified above, and the decoded value SHALL be used as its wire-format encoding.
任意のキーは、不明なキープレゼンテーション形式「keynnnnn」を使用して表現できます。ここで、nnnnnは主要なゼロなしでキータイプの数値です。この形式のsvcparamは、上記で指定されているように解析され、デコードされた値はそのワイヤー形式のエンコードとして使用するものとします。
For some SvcParamKeys, the value corresponds to a list or set of items. Presentation formats for such keys SHOULD use a comma-separated list (Appendix A.1).
一部のsvcparamkeysの場合、値はリストまたはアイテムのセットに対応します。このようなキーのプレゼンテーション形式は、コンマ分離リストを使用する必要があります（付録A.1）。
SvcParams in presentation format MAY appear in any order, but keys MUST NOT be repeated.
プレゼンテーション形式のsvcparamsは任意の順序で表示される場合がありますが、キーを繰り返す必要はありません。
The RDATA for the SVCB RR consists of:
SVCB RRのRDATAは次のとおりです。
* a 2-octet field for SvcPriority as an integer in network byte order.
* ネットワークバイト順序での整数としてのSVCPriorityの2オクセットフィールド。
* the uncompressed, fully qualified TargetName, represented as a sequence of length-prefixed labels per Section 3.1 of [RFC1035].
* [RFC1035]のセクション3.1ごとに、長さが固定された一連のラベルとして表される、圧縮されていない、完全に適格なターゲット名。
* the SvcParams, consuming the remainder of the record (so smaller than 65535 octets and constrained by the RDATA and DNS message sizes).
* svcparamsは、残りの記録を消費します（65535オクテットよりも小さいため、RDATAおよびDNSメッセージサイズによって制約されています）。
When the list of SvcParams is non-empty, it contains a series of SvcParamKey=SvcParamValue pairs, represented as:
svcparamsのリストが空でない場合、次のように表される一連のsvcparamkey = svcparamvalueペアが含まれています。
* a 2-octet field containing the SvcParamKey as an integer in network byte order. (See Section 14.3.2 for the defined values.)
* ネットワークバイトの順序で整数としてSVCParamkeyを含む2オクセットフィールド。（定義された値については、セクション14.3.2を参照してください。）
* a 2-octet field containing the length of the SvcParamValue as an integer between 0 and 65535 in network byte order.
* ネットワークバイトの順序で0〜65535の間の整数としてSVCPARAMVALUEの長さを含む2オクテットのフィールド。
* an octet string of this length whose contents are the SvcParamValue in a format determined by the SvcParamKey.
* この長さのオクテット文字列は、SVCParamkeyによって決定された形式で内容物がsvcparamvalueである。
SvcParamKeys SHALL appear in increasing numeric order.
SVCParamkeysは、数値の増加に登場するものとします。
Clients MUST consider an RR malformed if:
クライアントは、次の場合、RR不正を検討する必要があります。
* the end of the RDATA occurs within a SvcParam.
* RDATAの終わりは、SVCPARAM内で発生します。
* SvcParamKeys are not in strictly increasing numeric order.
* SVCParamkeysは、数値を厳密に増加させていません。
* the SvcParamValue for a SvcParamKey does not have the expected format.
* SVCParamkeyのSVCParamValueには、予想される形式がありません。
Note that the second condition implies that there are no duplicate SvcParamKeys.
2番目の条件は、svcparamkeysが重複していないことを意味することに注意してください。
If any RRs are malformed, the client MUST reject the entire RRset and fall back to non-SVCB connection establishment.
RRSが不正されている場合、クライアントはRRSet全体を拒否し、非SVCB接続確立に戻る必要があります。
When querying the SVCB RR, a service is translated into a QNAME by prepending the service name with a label indicating the scheme, prefixed with an underscore, resulting in a domain name like "_examplescheme.api.example.com.". This follows the Attrleaf naming pattern [Attrleaf], so the scheme MUST be registered appropriately with IANA (see Section 11).
SVCB RRを照会するとき、サービスは、アンダースコアが付いたスキームを示すラベルでサービス名を準備し、「_examplesscheme.api.example.com」のようなドメイン名になります。これは、アトリーフの命名パターン[attrleaf]に従うため、スキームはIANAに適切に登録する必要があります（セクション11を参照）。
Protocol mapping documents MAY specify additional underscore-prefixed labels to be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one reasonable possibility is to prepend the indicated port number if a non-default port number is specified. This document terms this behavior "Port Prefix Naming" and uses it in the examples throughout.
プロトコルマッピングドキュメントでは、準備される追加のアンダースコアが作成された追加のラベルを指定する場合があります。ポート（[URI]のセクション3.2.3）を指定するスキームの場合、1つの合理的な可能性は、非デフォルトポート番号が指定されている場合、指定されたポート番号を準備することです。このドキュメントは、この動作を「ポートプレフィックスネーミング」と呼び、全体の例で使用します。
See Section 9.1 for information regarding HTTPS RR behavior.
HTTPS RRの動作に関する情報については、セクション9.1を参照してください。
When a prior CNAME or SVCB record has aliased to a SVCB record, each RR SHALL be returned under its own owner name, as in ordinary CNAME processing ([RFC1034], Section 3.6.2). For details, see the recommendations regarding aliases for clients (Section 3), servers (Section 4), and zones (Section 10).
以前のCNAMEまたはSVCBレコードがSVCBレコードにエイリアスされた場合、通常のCNAME処理（[RFC1034]、セクション3.6.2）のように、各RRは独自の所有者名で返されます。詳細については、クライアント（セクション3）、サーバー（セクション4）、ゾーン（セクション10）に関するエイリアスに関する推奨事項を参照してください。
Note that none of these forms alter the origin or authority for validation purposes. For example, TLS clients MUST continue to validate TLS certificates for the original service name.
これらのフォームのいずれも、検証目的で起源または権限を変更しないことに注意してください。たとえば、TLSクライアントは、元のサービス名のTLS証明書を引き続き検証する必要があります。
As an example, the owner of "example.com" could publish this record:
例として、「Example.com」の所有者はこのレコードを公開できます。
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
This record would indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of "example.net", in turn, could publish this record:
このレコードは、「foo：//api.example.com：8443」が「svc4.example.net」にエイリアスされることを示します。「embles.net」の所有者は、このレコードを公開できます。
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" )
This record would indicate that these services are served on port number 8004, which supports the protocol "bar" and its associated transport in addition to the default transport protocol for "foo://".
この記録は、これらのサービスがポート番号8004で提供されていることを示しています。これは、「foo：//」のデフォルトの輸送プロトコルに加えて、プロトコル「bar」とその関連するトランスポートをサポートします。
(Parentheses are used to ignore a line break in DNS zone-file presentation format, per Section 5.1 of [RFC1035].)
（括弧は、[RFC1035]のセクション5.1に従って、DNSゾーンファイルのプレゼンテーション形式のラインブレイクを無視するために使用されます。）
When SvcPriority is 0, the SVCB record is in AliasMode (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3).
SVCPriorityが0の場合、SVCBレコードはAliAsmodeにあります（セクション2.4.2）。それ以外の場合は、ServiceMode（セクション2.4.3）にあります。
Within a SVCB RRset, all RRs SHOULD have the same mode. If an RRset contains a record in AliasMode, the recipient MUST ignore any ServiceMode records in the set.
SVCB RRSet内では、すべてのRRSに同じモードが必要です。RRSetにAliASMODEにレコードが含まれている場合、受信者はセット内のServiceModeレコードを無視する必要があります。
RRsets are explicitly unordered collections, so the SvcPriority field is used to impose an ordering on SVCB RRs. A smaller SvcPriority indicates that the domain owner recommends the use of this record over ServiceMode RRs with a larger SvcPriority value.
RRSetsは明示的に順序付けられていないコレクションであるため、SVCB RRSに順序付けを課すためにSVCPriorityフィールドを使用します。SVCPriolityが小さくなると、ドメインの所有者が、SVCPriority値が大きいServiceMode RRSを介したこのレコードの使用を推奨することを示しています。
When receiving an RRset containing multiple SVCB records with the same SvcPriority value, clients SHOULD apply a random shuffle within a priority level to the records before using them, to ensure uniform load balancing.
同じSVCPRiority値を持つ複数のSVCBレコードを含むRRSETを受信する場合、クライアントはレコードを使用する前に優先レベル内にランダムシャッフルを適用して、均一な負荷分散を確保する必要があります。
In AliasMode, the SVCB record aliases a service to a TargetName. SVCB RRsets SHOULD only have a single RR in AliasMode. If multiple AliasMode RRs are present, clients or recursive resolvers SHOULD pick one at random.
AliAsmodeでは、SVCBはTargetNameへのサービスを録音します。SVCB RRSETSには、AliASMODEに単一のRRのみが必要です。複数のAliASMODE RRが存在する場合、クライアントまたは再帰的なリゾルバーはランダムに1つを選択する必要があります。
The primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed (see, for example, [RFC1912], Section 2.4). In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. (See Section 6 for aliasing of SVCB-compatible RR types.) Unlike CNAME, AliasMode records do not affect the resolution of other RR types and apply only to a specific service, not an entire domain name.
AliAsmodeの主な目的は、CNAMEが許可されていないゾーンアペックスでエイリアシングを許可することです（たとえば、[RFC1912]、セクション2.4を参照）。AliAsmodeでは、TargetNameはSVCB、AAAA、および/またはレコードに解決するドメインの名前になります。（SVCB互換RRタイプのエイリアシングについてはセクション6を参照してください。）CNAMEとは異なり、AliASMODEレコードは他のRRタイプの解像度に影響を与えず、ドメイン名全体ではなく特定のサービスにのみ適用されます。
The AliasMode TargetName SHOULD NOT be equal to the owner name, as this would result in a loop. In AliasMode, recipients MUST ignore any SvcParams that are present. Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams. The use of SvcParams in AliasMode records is currently not defined, but a future specification could extend AliasMode records to include SvcParams.
Alismode TargetNameは、所有者名に等しくないはずです。これにより、ループが発生するためです。AliAsmodeでは、受信者は存在するsvcparamsを無視する必要があります。ゾーンファイルパーサーは、AliASMODEレコードにSVCPARAMSがある場合、警告を発する場合があります。Alismode RecordsでのSVCPARAMSの使用は現在定義されていませんが、将来の仕様では、AliASMODEレコードを拡張してSVCPARAMSを含む可能性があります。
For example, the operator of "foo://example.com:8080" could point requests to a service operating at "foosvc.example.net" by publishing:
たとえば、「foo：//example.com：8080」のオペレーターは、公開して「foosvc.example.net」で操作するサービスをリクエストに向けることができます。
_8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.
Using AliasMode maintains a separation of concerns: the owner of "foosvc.example.net" can add or remove ServiceMode SVCB records without requiring a corresponding change to "example.com". Note that if "foosvc.example.net" promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME at the same owner name.
AliAsmodeを使用すると、懸念の分離が維持されます。「foosvc.example.net」の所有者は、「Example.com」への対応する変更を必要とせずにServiceMode SVCBレコードを追加または削除できます。「foosvc.example.net」が常にsvcbレコードを公開することを約束する場合、このアリスムードレコードは同じ所有者名でcnameに置き換えることができることに注意してください。
AliasMode is especially useful for SVCB-compatible RR types that do not require an underscore prefix, such as the HTTPS RR type. For example, the operator of "https://example.com" could point requests to a server at "svc.example.net" by publishing this record at the zone apex:
AliAsmodeは、HTTPS RRタイプなどのアンダースコアプレフィックスを必要としないSVCB互換RRタイプに特に役立ちます。たとえば、「https://example.com」のオペレーターは、Zone Apexでこのレコードを公開することにより、「svc.example.net」のサーバーにリクエストをポイントできます。
example.com. 3600 IN HTTPS 0 svc.example.net.
Note that the SVCB record's owner name MAY be the canonical name of a CNAME record, and the TargetName MAY be the owner of a CNAME record. Clients and recursive resolvers MUST follow CNAMEs as normal.
SVCBレコードの所有者名はCNAMEレコードの標準名であり、TargetNameはCNAMEレコードの所有者である可能性があることに注意してください。クライアントと再帰的なリゾルバーは、通常どおりのCNAMEに従う必要があります。
To avoid unbounded alias chains, clients and recursive resolvers MUST impose a limit on the total number of SVCB aliases they will follow for each resolution request. This limit MUST NOT be zero, i.e., implementations MUST be able to follow at least one AliasMode record. The exact value of this limit is left to implementations.
バウンドされていないエイリアスチェーンを避けるために、クライアントと再帰リゾルバーは、各解像度リクエストに対して従うSVCBエイリアスの総数に制限を課す必要があります。この制限はゼロであることはできません。つまり、実装は少なくとも1つのアリスマードレコードに従うことができなければなりません。この制限の正確な値は、実装に任されています。
Zones that require following multiple AliasMode records could encounter compatibility and performance issues.
複数のAliASMODEレコードをフォローする必要があるゾーンは、互換性とパフォーマンスの問題に遭遇する可能性があります。
As legacy clients will not know to use this record, service operators will likely need to retain fallback AAAA and A records alongside this SVCB record, although in a common case the target of the SVCB record might offer better performance, and therefore would be preferable for clients implementing this specification to use.
レガシーのクライアントはこのレコードを使用することを知らないため、サービスオペレーターはこのSVCBレコードと一緒にフォールバックAAAAとレコードを保持する必要がある可能性がありますが、一般的なケースではSVCBレコードのターゲットがより良いパフォーマンスを提供する可能性があります。使用するこの仕様を実装するクライアント。
AliasMode records only apply to queries for the specific RR type. For example, a SVCB record cannot alias to an HTTPS record or vice versa.
AliASMODEレコードは、特定のRRタイプのクエリにのみ適用されます。たとえば、SVCBレコードはHTTPSレコードにエイリアスすることも、その逆も同様です。
In ServiceMode, the TargetName and SvcParams within each RR associate an alternative endpoint for the service with its connection parameters.
ServiceModeでは、各RR内のTargetNameおよびSVCPARAMSは、その接続パラメーターを使用して、サービスの代替エンドポイントを関連付けます。
Each protocol scheme that uses SVCB MUST define a protocol mapping that explains how SvcParams are applied for connections of that scheme. Unless specified otherwise by the protocol mapping, clients MUST ignore any SvcParam that they do not recognize.
SVCBを使用する各プロトコルスキームは、SVCParamがそのスキームの接続に適用される方法を説明するプロトコルマッピングを定義する必要があります。プロトコルマッピングによって特に指定されていない限り、クライアントは認識していないSVCParamを無視する必要があります。
Some SvcParams impose requirements on other SvcParams in the RR. A ServiceMode RR is called "self-consistent" if its SvcParams all comply with each other's requirements. Clients MUST reject any RR whose recognized SvcParams are not self-consistent and MAY reject the entire RRset. To help zone operators avoid this condition, zone-file implementations SHOULD enforce self-consistency as well.
一部のSVCparamsは、RRの他のSVCPARAMに要件を課しています。SVCPARAMSがすべて互いの要件に準拠している場合、ServiceMode RRは「自己矛盾」と呼ばれます。クライアントは、認識されているSVCPARAMSが自己整合ではなく、RRSet全体を拒否する可能性があるRRを拒否する必要があります。ゾーンオペレーターがこの状態を回避できるように、ゾーンファイルの実装も同様に自己整合性を実施する必要があります。
If TargetName has the value "." (represented in the wire format as a zero-length label), special rules apply.
TargetNameに値がある場合。」（ワイヤ形式でゼロレングスラベルとして表されています）、特別なルールが適用されます。
For AliasMode SVCB RRs, a TargetName of "." indicates that the service is not available or does not exist. This indication is advisory: clients encountering this indication MAY ignore it and attempt to connect without the use of SVCB.
aliASMODE SVCB RRSの場合、 "。"のターゲット名。サービスが利用できないか、存在しないことを示します。この兆候はアドバイザリーです。この兆候に遭遇するクライアントは、それを無視し、SVCBを使用せずに接続しようとする場合があります。
For ServiceMode SVCB RRs, if TargetName has the value ".", then the owner name of this record MUST be used as the effective TargetName. If the record has a wildcard owner name in the zone file, the recipient SHALL use the response's synthesized owner name as the effective TargetName.
ServiceMode SVCB RRSの場合、TargetNameに値が "。"がある場合、このレコードの所有者名は効果的なターゲット名として使用する必要があります。レコードにゾーンファイルにワイルドカードの所有者名がある場合、受信者は、応答の合成された所有者名を効果的なターゲット名として使用するものとします。
Here, for example, "svc2.example.net" is the effective TargetName:
ここで、たとえば、「svc2.example.net」は効果的なターゲット名です。
example.com. 7200 IN HTTPS 0 svc.example.net.
svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPS 1 . port=8002
svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2
"SVCB resolution" is the process of enumerating and ordering the available endpoints for a service, as performed by the client. SVCB resolution is implemented as follows:
「SVCB解像度」とは、クライアントが実行するように、サービスに使用可能なエンドポイントを列挙して注文するプロセスです。SVCB解像度は次のように実装されます。
1. Let $QNAME be the service name plus appropriate prefixes for the scheme (see Section 2.3).
1. $ QNameをService Nameとスキームの適切なプレフィックスとします（セクション2.3を参照）。
2. Issue a SVCB query for $QNAME.
2. $ QNameのSVCBクエリを発行します。
3. If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs as normal), set $QNAME to its TargetName (without additional prefixes) and loop back to Step 2, subject to chain length limits and loop detection heuristics (see Section 3.1).
3. AliASMODE SVCBレコードが$ QNAME（通常のCNAMEをフォローした後）で返された場合、$ QNAMEをTargetName（追加のプレフィックスなし）に設定し、ステップ2に戻ります。。
4. If one or more "compatible" (Section 8) ServiceMode records are returned, these represent the alternative endpoints. Sort the records by ascending SvcPriority.
4. 1つ以上の「互換性」（セクション8）ServiceModeレコードが返される場合、これらは代替エンドポイントを表します。昇順のsvcpriorityでレコードを並べ替えます。
5. Otherwise, SVCB resolution has failed, and the list of available endpoints is empty.
5. それ以外の場合、SVCB解像度は失敗し、使用可能なエンドポイントのリストが空です。
This procedure does not rely on any recursive or authoritative DNS server to comply with this specification or have any awareness of SVCB.
この手順は、この仕様に準拠するために、またはSVCBの認識を持つために、再帰的または権威あるDNSサーバーに依存していません。
A client is called "SVCB-optional" if it can connect without the use of ServiceMode records; otherwise, it is called "SVCB-reliant". Clients for pre-existing protocols (e.g., HTTP) SHALL implement SVCB-optional behavior (except as noted in Section 3.1 or when modified by future specifications).
クライアントは、ServiceModeレコードを使用せずに接続できる場合、「SVCBオプション」と呼ばれます。それ以外の場合は、「svcb reliant」と呼ばれます。既存のプロトコル（HTTPなど）のクライアントは、SVCBオプションの動作を実装するものとします（セクション3.1または将来の仕様で変更された場合を除く）。
SVCB-optional clients SHOULD issue in parallel any other DNS queries that might be needed for connection establishment if the SVCB record is absent, in order to minimize delay in that case and enable the optimizations discussed in Section 5.
SVCBオプションクライアントは、SVCBレコードが存在しない場合、接続確立に必要な他のDNSクエリを並行して発行し、その場合の遅延を最小限に抑え、セクション5で説明した最適化を有効にするためです。
Once SVCB resolution has concluded, whether successful or not, if at least one AliasMode record was processed, SVCB-optional clients SHALL append to the list of endpoints an endpoint consisting of the final value of $QNAME, the authority endpoint's port number, and no SvcParams. (This endpoint will be attempted before falling back to non-SVCB connection modes. This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.)
SVCBの解決が終了すると、成功したかどうかにかかわらず、少なくとも1つのAliASMODEレコードが処理された場合、SVCBオプションクライアントはエンドポイントのリストに、$ QNAME、Authority EndPointのポート番号、およびNO NOの最終値からなるエンドポイントを追加するものとします。svcparams。（このエンドポイントは、非SVCB接続モードに戻る前に試みられます。これにより、SVCBオプションのクライアントが、ターゲット名にAおよび/またはAAAAレコードがありますが、SVCBレコードがないAliASMODEレコードを使用することが保証されます。）
The client proceeds with connection establishment using this list of endpoints. Clients SHOULD try higher-priority alternatives first, with fallback to lower-priority alternatives. Clients resolve AAAA and/or A records for the selected TargetName and MAY choose between them using an approach such as Happy Eyeballs [HappyEyeballsV2].
クライアントは、このエンドポイントのリストを使用して接続確立を進めます。クライアントは、より低い優先順位の代替品へのフォールバックを使用して、より優先順位の代替品を最初に試してみる必要があります。クライアントは、選択したTargetNameのAAAAおよび/またはレコードを解決し、Happy Eyeballs [Happyeyeballsv2]などのアプローチを使用してそれらを選択できます。
If the client is SVCB-optional and connecting using this list of endpoints has failed, the client now attempts to use non-SVCB connection modes.
クライアントがSVCBオプションであり、エンドポイントのこのリストを使用して接続すると失敗した場合、クライアントは非SVCB接続モードの使用を試みます。
Some important optimizations are discussed in Section 5 to avoid additional latency in comparison to ordinary AAAA/A lookups.
いくつかの重要な最適化については、通常のAAA/Aルックアップと比較して追加のレイテンシを回避するために、セクション5で説明します。
If DNS responses are cryptographically protected (e.g., using DNSSEC or TLS [DoT] [DoH]) and SVCB resolution fails due to an authentication error, SERVFAIL response, transport error, or timeout, the client SHOULD abandon its attempt to reach the service, even if the client is SVCB-optional. Otherwise, an active attacker could mount a downgrade attack by denying the user access to the SvcParams.
DNS応答が暗号化された（例：DNSSECまたはTLS [DOT] [DOH]を使用して）認証エラー、サーブファイルの応答、輸送エラー、またはタイムアウトのためにSVCB解像度が失敗した場合、クライアントはサービスに到達しようとする試みを放棄する必要があります。クライアントがSVCBオプションであっても。それ以外の場合、アクティブな攻撃者は、SVCParamsへのユーザーアクセスを拒否することにより、ダウングレード攻撃を行う可能性があります。
A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursive resolver is DNSSEC-validating, and the attacker is between the recursive resolver and the authoritative DNS server. A transport error or timeout can occur if an active attacker between the client and the recursive resolver is selectively dropping SVCB queries or responses, based on their size or other observable patterns.
ドメインがDNSSECに署名され、再帰リゾルバーがDNSSEC検証である場合、攻撃者は再帰リゾルバーと権威あるDNSサーバーの間にある場合、サーブファイルエラーが発生する可能性があります。クライアントと再帰リゾルバーの間のアクティブな攻撃者が、サイズまたはその他の観察可能なパターンに基づいてSVCBクエリまたは応答を選択的にドロップしている場合、トランスポートエラーまたはタイムアウトが発生する可能性があります。
If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. Otherwise, an attacker could defeat the A/AAAA protection by forging SVCB responses that direct the client to other IP addresses.
クライアントがA/AAAA応答でDNSSEC検証を実施する場合、同じ検証ポリシーをSVCBに適用する必要があります。それ以外の場合、攻撃者は、クライアントを他のIPアドレスに誘導するSVCB応答を偽造することにより、A/AAAA保護を打ち負かす可能性があります。
If DNS responses are not cryptographically protected, clients MAY treat SVCB resolution failure as fatal or nonfatal.
DNS応答が暗号化されていない場合、クライアントはSVCB解像度の障害を致命的または非致命的なものとして扱う可能性があります。
If the client is unable to complete SVCB resolution due to its chain length limit, the client MUST fall back to the authority endpoint, as if the service's SVCB record did not exist.
クライアントがチェーンの長さの制限のためにSVCB解像度を完了できない場合、クライアントは、サービスのSVCBレコードが存在しないかのように、権限のエンドポイントに戻る必要があります。
Clients using a domain-oriented transport proxy like HTTP CONNECT ([RFC7231], Section 4.3.6) or SOCKS5 [RFC1928] have the option of using named destinations, in which case the client does not perform any A or AAAA queries for destination domains. If the client is configured to use named destinations with a proxy that does not provide SVCB query capability (e.g., through an affiliated DNS resolver), the client would have to perform SVCB resolution separately, likely disclosing the destinations to additional parties and not just the proxy. Clients in this configuration SHOULD arrange for a separate SVCB resolution procedure with appropriate privacy properties. If this is not possible, SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-reliant clients MUST treat the configuration as invalid.
HTTP Connect（[RFC7231]、セクション4.3.6）またはSOCKS5 [RFC1928]などのドメイン指向のトランスポートプロキシを使用しているクライアントには、名前のある目的地を使用するオプションがあります。。クライアントが、SVCBクエリ機能を提供しないプロキシを使用して名前の名前の宛先を使用するように構成されている場合（例：関連DNSリゾルバーを介して）、クライアントはSVCB解像度を個別に実行する必要があります。プロキシ。この構成のクライアントは、適切なプライバシープロパティを備えた個別のSVCB解像度手順を手配する必要があります。これが不可能な場合、SVCBオプションのクライアントはSVCB解像度を完全に無効にしなければならず、SVCB依存のクライアントは構成を無効として扱う必要があります。
If the client does use SVCB and named destinations, the client SHOULD follow the standard SVCB resolution process, selecting the smallest-SvcPriority option that is compatible with the client and the proxy. When connecting using a SVCB record, clients MUST provide the final TargetName and port to the proxy, which will perform any required A and AAAA lookups.
クライアントがSVCBを使用し、名前付き宛先を使用している場合、クライアントは標準のSVCB解像度プロセスに従い、クライアントとプロキシと互換性のある最小のSVCPRIORITYオプションを選択する必要があります。SVCBレコードを使用して接続する場合、クライアントは最終的なTargetNameとPortをプロキシに提供する必要があります。これにより、必要なAおよびAAAAルックアップが実行されます。
This arrangement has several benefits:
この配置にはいくつかの利点があります。
* Compared to disabling SVCB:
* SVCBの無効化と比較して：
- It allows the client to use the SvcParams, if present, which are only usable with a specific TargetName. The SvcParams may include information that enhances performance (e.g., supported protocols) and privacy.
- これにより、クライアントは存在する場合はSVCParamsを使用できます。これは、特定のTargetNameでのみ使用できます。SVCParamsには、パフォーマンス（サポートされているプロトコルなど）とプライバシーを強化する情報が含まれる場合があります。
- It allows a service on an apex domain to use aliasing.
- Apexドメイン上のサービスがエイリアシングを使用できます。
* Compared to providing the proxy with an IP address:
* プロキシにIPアドレスを提供するのと比較してください。
- It allows the proxy to select between IPv4 and IPv6 addresses for the server according to its configuration.
- プロキシは、その構成に応じてサーバーのIPv4アドレスとIPv6アドレスを選択できます。
- It ensures that the proxy receives addresses based on its network geolocation, not the client's.
- これにより、プロキシは、クライアントのジオロケーションではなく、ネットワークジオロケーションに基づいてアドレスを受信することが保証されます。
- It enables faster fallback for TCP destinations with multiple addresses of the same family.
- 同じファミリの複数のアドレスを持つTCPの目的地のフォールバックをより速くすることができます。
When replying to a SVCB query, authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the Additional section for any TargetNames that are in the zone. If the zone is signed, the server SHOULD also include DNSSEC records authenticating the existence or nonexistence of these records in the Additional section.
SVCBクエリに返信する場合、権威あるDNSサーバーは、ゾーン内にある任意のターゲットネームの追加セクションにA、AAAA、およびSVCBレコードを返す必要があります。ゾーンに署名されている場合、サーバーには、追加セクションのこれらのレコードの存在または非存在を認証するDNSSECレコードも含める必要があります。
See Section 4.4 for exceptions.
例外については、セクション4.4を参照してください。
Whether the recursive resolver is aware of SVCB or not, the normal response construction process used for unknown RR types [RFC3597] generates the Answer section of the response. Recursive resolvers that are aware of SVCB SHOULD help the client to execute the procedure in Section 3 with minimum overall latency by incorporating additional useful information into the Additional section of the response as follows:
再帰リゾルバーがSVCBを認識しているかどうかにかかわらず、不明なRRタイプ[RFC3597]に使用される通常の応答構造プロセスは、応答の回答セクションを生成します。SVCBを認識している再帰リゾルバーは、次のように応答の追加セクションに追加の有用な情報を組み込むことにより、クライアントが最小の全体的な遅延でセクション3の手順を実行するのに役立つはずです。
1. Incorporate the results of SVCB resolution. If the recursive resolver's local chain length limit (which may be different from the client's limit) has been reached, terminate.
1. SVCB解像度の結果を組み込みます。再帰リゾルバーのローカルチェーン長い制限（クライアントの制限とは異なる場合がある）に達した場合、終了します。
2. If any of the resolved SVCB records are in AliasMode, choose one of them at random, and resolve SVCB, A, and AAAA records for its TargetName.
2. 解決されたSVCBレコードのいずれかがAliAsmodeにある場合は、それらのいずれかをランダムに選択し、SVCB、A、およびAAAAレコードをTargetNameのRecolvedに解決します。
* If any SVCB records are resolved, go to Step 1.
* SVCBレコードが解決された場合は、ステップ1に移動します。
* Otherwise, incorporate the results of A and AAAA resolution, and terminate.
* それ以外の場合は、AおよびAAAA解像度の結果を組み込み、終了します。
3. All the resolved SVCB records are in ServiceMode. Resolve A and AAAA queries for each TargetName (or for the owner name if TargetName is "."), incorporate all the results, and terminate.
3. 解決されたすべてのSVCBレコードはServiceModeにあります。各ターゲット名のaおよびaaaa queriesを解決します（またはターゲット名が "。"の場合、所有者名がある場合は所有者名があります）、すべての結果を組み込み、終了します。
In this procedure, "resolve" means the resolver's ordinary recursive resolution procedure, as if processing a query for that RRset. This includes following any aliases that the resolver would ordinarily follow (e.g., CNAME, DNAME [DNAME]). Errors or anomalies in obtaining additional records MAY cause this process to terminate but MUST NOT themselves cause the resolver to send a failure response.
この手順では、「Resolve」とは、そのRRSetのクエリを処理するかのように、Resolverの通常の再帰解決手順を意味します。これには、リゾルバーが通常続くエイリアス（例：cname、dname [dname]）が含まれます。追加のレコードを取得する際のエラーまたは異常は、このプロセスが終了する可能性がありますが、それ自体がリゾルバーに障害応答を送信してはなりません。
See Section 2.4.2 for additional safeguards for recursive resolvers to implement to mitigate loops.
ループを緩和するための実装する再帰リソースバーについては、追加のセーフガードについてはセクション2.4.2を参照してください。
See Section 5.2 for possible optimizations of this procedure.
この手順の最適化の可能性については、セクション5.2を参照してください。
DNS64 resolvers synthesize responses to AAAA queries for names that only have an A record (Section 5.1.7 of [RFC6147]). SVCB-aware DNS64 resolvers SHOULD apply the same synthesis logic when resolving AAAA records for the TargetName for inclusion in the Additional section (Step 2 in Section 4.2) and MAY omit the A records from this section.
DNS64リゾルバーは、Aレコードのみを持つ名前のAAAAクエリに対する応答を合成します（[RFC6147]のセクション5.1.7）。SVCB-AWARE DNS64リゾルバーは、追加のセクション（セクション4.2のステップ2）に含めるためにターゲット名のAAAAレコードを解決するときに同じ合成ロジックを適用する必要があり、このセクションのAレコードを省略する場合があります。
DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the IP hints in the SvcParams (Section 7.3). Modifying the IP hints would break DNSSEC validation for the SVCB record and would not improve performance when the above recommendation is implemented.
DNS64リゾルバーは、SVCParamsのIPヒントにAAAA合成ロジックを推定してはなりません（セクション7.3）。IPヒントを変更すると、SVCBレコードのDNSSEC検証が破壊され、上記の推奨が実装された場合、パフォーマンスが向上しません。
Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys. Resolvers MAY accomplish this by treating the entire SvcParams portion of the record as opaque, even if the contents are invalid. If a recognized SvcParamKey is followed by a value that is invalid according to the SvcParam's specification, a recursive resolver MAY report an error such as SERVFAIL instead of returning the record. For complex value types whose interpretation might differ between implementations or have additional future allowed values added (e.g., URIs or "alpn"), resolvers SHOULD limit validation to specified constraints.
再帰的なリゾルバーは、認識されていないSVCParamkeysでSVCBレコードを伝えることができなければなりません。リゾルバーは、記録のSVCPARAMS部分全体を不透明として扱うことにより、これを達成することができます。認識されたSVCParamkeyの後に、SVCParamの仕様に従って無効な値が続く場合、再帰的なリゾルバーは、レコードを返す代わりにServFailなどのエラーを報告する場合があります。解釈が実装間で異なるか、追加の将来の許可値が追加されている可能性のある複雑な値タイプ（URISや「ALPN」など）の場合、リゾルバーは特定の制約に検証を制限する必要があります。
When responding to a query that includes the DNSSEC OK bit [RFC3225], DNSSEC-capable recursive and authoritative DNS servers MUST accompany each RRset in the Additional section with the same DNSSEC-related records that they would send when providing that RRset as an Answer (e.g., RRSIG, NSEC, NSEC3).
DNSSEC OK BIT [RFC3225]を含むクエリに応答する場合、DNSSEC対応の再帰的で権威あるDNSサーバーは、追加セクションの各RRSETに、RRSEが回答としてそのRRSetを提供するときに送信するのと同じDNSSEC関連のレコードを伴う必要があります。例：RRSIG、NSEC、NSEC3）。
According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs received and cached from ... the additional data section ... should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate." Recursive resolvers therefore MAY cache records from the Additional section for use in populating Additional section responses and MAY cache them for general use if they are authenticated by DNSSEC.
[RFC2181]のセクション5.4.1によれば、「受信およびキャッシュされた認識されていないRRS ...追加のデータセクション...は、受け取ったクエリへの回答として返されるような方法でキャッシュされるべきではありません。必要に応じて追加情報として返品される場合があります。」したがって、再帰的なリゾルバーは、追加セクションの応答を使用する際に使用するために追加セクションからレコードをキャッシュし、DNSSECによって認証されている場合は一般的に使用するためにそれらをキャッシュできます。
The EDNS Client Subnet (ECS) option [RFC7871] allows recursive resolvers to request IP addresses that are suitable for a particular client IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams) or direct users to a subnet-specific TargetName, so recursive resolvers SHOULD include the same ECS option in SVCB queries as in A/AAAA queries.
EDNSクライアントサブネット（ECS）オプション[RFC7871]を使用すると、特定のクライアントIP範囲に適したIPアドレスを要求する再帰リゾルバーが許可されます。SVCBレコードには、IPアドレス（IPV*ヒントSVCPARAMS）またはサブネット固有のターゲット名にユーザーを直接含めることができるため、再帰的なリゾルバーには、A/AAAAクエリと同じECSオプションをSVCBクエリに含める必要があります。
According to Section 7.3.1 of [RFC7871], "Any records from [the Additional section] MUST NOT be tied to a network." Accordingly, when processing a response whose QTYPE is SVCB-compatible, resolvers SHOULD treat any records in the Additional section as having SOURCE PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specified in the ECS option. Authoritative servers MUST omit such records if they are not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to zero. This will cause the resolver to perform a follow-up query that can receive a properly tailored ECS. (This is similar to the usage of CNAME with the ECS option as discussed in [RFC7871], Section 7.2.1.)
[RFC7871]のセクション7.3.1によると、「[追加セクション]の記録はネットワークに結び付けられてはなりません。」したがって、QTypeがSVCB互換性のある応答を処理する場合、Resolversは、ECSオプションで指定されているように、追加セクションのレコードを追加セクションのレコードをゼロに設定し、スコーププレフィックスレングスに扱うように扱う必要があります。権威あるサーバーは、ソースプレフィックスレングスをゼロに設定するスタブリゾルバーの使用に適していない場合、そのようなレコードを省略する必要があります。これにより、リゾルバーは適切に調整されたECを受信できるフォローアップクエリを実行します。（これは、[RFC7871]、セクション7.2.1で説明されているECSオプションを使用したCNAMEの使用に似ています。）
Authoritative servers that omit Additional records can avoid the added latency of a follow-up query by following the advice in Section 10.2.
追加のレコードを省略する権威あるサーバーは、セクション10.2のアドバイスに従ってフォローアップクエリの追加の遅延を回避できます。
For optimal performance (i.e., minimum connection setup time), clients SHOULD implement a client-side DNS cache. Responses in the Additional section of a SVCB response SHOULD be placed in cache before performing any follow-up queries. With this behavior, and with conforming DNS servers, using SVCB does not add network latency to connection setup.
最適なパフォーマンス（つまり、最小接続セットアップ時間）のために、クライアントはクライアント側のDNSキャッシュを実装する必要があります。フォローアップクエリを実行する前に、SVCB応答の追加セクションの応答をキャッシュに配置する必要があります。この動作により、DNSサーバーの適合性により、SVCBを使用しても、接続セットアップにネットワークレイテンシが追加されません。
To improve performance when using a non-conforming recursive resolver, clients SHOULD issue speculative A and/or AAAA queries in parallel with each SVCB query, based on a predicted value of TargetName (see Section 10.2).
不適合な再帰リゾルバーを使用するときにパフォーマンスを改善するには、ターゲットの予測値に基づいて、各SVCBクエリと並行して投機的Aおよび/またはAAAAクエリを発行する必要があります（セクション10.2を参照）。
After a ServiceMode RRset is received, clients MAY try more than one option in parallel and MAY prefetch A and AAAA records for multiple TargetNames.
ServiceMode RRSETを受信した後、クライアントは複数のオプションを並行して試み、複数のターゲット名のAおよびAAAAレコードをプリフェッチできます。
If an address response arrives before the corresponding SVCB response, the client MAY initiate a connection as if the SVCB query returned NODATA but MUST NOT transmit any information that could be altered by the SVCB response until it arrives. For example, future SvcParamKeys could be defined that alter the TLS ClientHello.
対応するSVCB応答の前にアドレス応答が到着した場合、クライアントはSVCBクエリがNodataを返したかのように接続を開始することができますが、SVCB応答が到着するまで変更できる情報を送信してはなりません。たとえば、TLS ClientHelloを変更する将来のSVCParamkeysを定義できます。
Clients implementing this optimization SHOULD wait for 50 milliseconds before starting optimistic pre-connection, as per the guidance in [HappyEyeballsV2].
[Happyeyeballsv2]のガイダンスに従って、この最適化を実装するクライアントは、楽観的な事前接続を開始する前に50ミリ秒を待つ必要があります。
A SVCB record is consistent with a connection if the client would attempt an equivalent connection when making use of that record. If a SVCB record is consistent with an active or in-progress connection C, the client MAY prefer that record and use C as its connection. For example, suppose the client receives this SVCB RRset for a protocol that uses TLS over TCP:
SVCBレコードは、クライアントがそのレコードを使用するときに同等の接続を試みる場合、接続と一致します。SVCBレコードがアクティブまたは進行中の接続Cと一致している場合、クライアントはそのレコードを好み、Cを接続として使用できます。たとえば、TCPを介してTLSを使用するプロトコルに対して、クライアントがこのSVCB RRSetを受信したとします。
_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
ipv6hint=2001:db8::1 port=1234 )
SVCB 2 svc2.example.net. (
ipv6hint=2001:db8::2 port=1234 )
If the client has an in-progress TCP connection to [2001:db8::2]:1234, it MAY proceed with TLS on that connection, even though the other record in the RRset has higher priority.
クライアントが[2001：DB8 :: 2]への進行中のTCP接続を持っている場合、RRSetの他のレコードの優先度が高いにもかかわらず、その接続でTLSを続行する場合があります。
If none of the SVCB records are consistent with any active or in-progress connection, clients proceed with connection establishment as described in Section 3.
SVCBレコードがアクティブまたは進行中の接続と一致していない場合、クライアントはセクション3で説明されているように接続確立を進めます。
When following the procedure in Section 4.2, recursive resolvers MAY terminate the procedure early and produce a reply that omits some of the associated RRsets. This is REQUIRED when the chain length limit is reached (Step 1 in Section 4.2) but might also be appropriate when the maximum response size is reached or when responding before fully chasing dependencies would improve performance. When omitting certain RRsets, recursive resolvers SHOULD prioritize information for smaller-SvcPriority records.
セクション4.2の手順に従うと、再帰的なリゾルバーは手順を早期に終了し、関連するRRSetの一部を省略する返信を作成する場合があります。これは、チェーンの長さの制限に達したとき（セクション4.2のステップ1）が必要ですが、最大応答サイズに到達した場合、または依存関係を完全に追跡する前に応答する場合にも適切である場合があります。特定のrrsetsを省略する場合、再帰的なリゾルバーは、より小さなSVCPriolityレコードの情報を優先する必要があります。
As discussed in Section 3, clients MUST be able to fetch additional information that is required to use a SVCB record, if it is not included in the initial response. As a performance optimization, if some of the SVCB records in the response can be used without requiring additional DNS queries, the client MAY prefer those records, regardless of their priorities.
セクション3で説明したように、クライアントは、最初の応答に含まれていない場合は、SVCBレコードを使用するために必要な追加情報を取得できる必要があります。パフォーマンスの最適化として、追加のDNSクエリを必要とせずに応答のSVCBレコードの一部を使用できる場合、クライアントは優先順位に関係なく、それらのレコードを好む場合があります。
An RR type is called "SVCB-compatible" if it permits an implementation that is identical to SVCB in its:
RRタイプは、SVCBと同一の実装を許可する場合、「SVCB互換」と呼ばれます。
* RDATA presentation format
* RDATAプレゼンテーション形式
* RDATA wire format
* rdataワイヤ形式
* IANA registry used for SvcParamKeys
* svcparamkeysに使用されるIANAレジストリ
* Authoritative server Additional section processing
* 権威あるサーバーの追加セクション処理
* Recursive resolution process
* 再帰解決プロセス
* Relevant Class (i.e., Internet ("IN") [RFC1035])
* 関連するクラス（つまり、インターネット（ "in"）[RFC1035]）
This allows authoritative and recursive DNS servers to apply identical processing to all SVCB-compatible RR types.
これにより、信頼できる再帰的なDNSサーバーが、すべてのSVCB互換RRタイプに同一の処理を適用できます。
All other behaviors described as applying to the SVCB RR also apply to all SVCB-compatible RR types unless explicitly stated otherwise. When following an AliasMode record (Section 2.4.2) of RR type $T, the follow-up query to the TargetName MUST also be for type $T.
SVCB RRに適用されると説明されている他のすべての動作は、明示的に明示的に記載されていない限り、すべてのSVCB互換RRタイプにも適用されます。RRタイプ$ tのAliASMODEレコード（セクション2.4.2）に従う場合、TargetNameのフォローアップクエリもタイプ$ tの場合が必要です。
This document defines one SVCB-compatible RR type (other than SVCB itself): the HTTPS RR type (Section 9), which avoids Attrleaf label prefixes [Attrleaf] in order to improve compatibility with wildcards and CNAMEs, which are widely used with HTTP.
このドキュメントでは、1つのSVCB互換RRタイプ（SVCB自体を除く）を定義します。HTTPSRRタイプ（セクション9）は、HTTPと広く使用されているワイルドカードとCNAMEとの互換性を向上させるために、アトリーフラベルのプレフィックス[アトリーフ]を回避します。
Standards authors should consider carefully whether to use SVCB or define a new SVCB-compatible RR type, as this choice cannot easily be reversed after deployment.
標準の著者は、SVCBを使用するか、新しいSVCB互換RRタイプを定義するかを慎重に検討する必要があります。この選択は、展開後に簡単に逆転することはできません。
A few initial SvcParamKeys are defined here. These keys are useful for the "https" scheme, and most are expected to be generally applicable to other schemes as well.
ここでは、いくつかの初期svcparamkeysが定義されています。これらのキーは「HTTPS」スキームに役立ち、ほとんどは一般に他のスキームにも適用できると予想されます。
Each new protocol mapping document MUST specify which keys are applicable and safe to use. Protocol mappings MAY alter the interpretation of SvcParamKeys but MUST NOT alter their presentation or wire formats.
新しいプロトコルマッピングドキュメントは、どのキーが適用可能で安全に使用できるかを指定する必要があります。プロトコルマッピングは、SVCParamkeysの解釈を変更する可能性がありますが、プレゼンテーションまたはワイヤー形式を変更してはなりません。
The "alpn" and "no-default-alpn" SvcParamKeys together indicate the set of Application-Layer Protocol Negotiation (ALPN) protocol identifiers [ALPN] and associated transport protocols supported by this service endpoint (the "SVCB ALPN set").
「ALPN」および「NO-DEFAULT-ALPN」SVCPARAMKEYSは、アプリケーション層プロトコルネゴシエーション（ALPN）プロトコル識別子[ALPN]およびこのサービスエンドポイントでサポートされている関連する輸送プロトコルのセット（「SVCB ALPNセット」）を示しています。
As with Alt-Svc [AltSvc], each ALPN protocol identifier is used to identify the application protocol and associated suite of protocols supported by the endpoint (the "protocol suite"). The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this service endpoint, described by TargetName and the other parameters (e.g., "port"), offers service with the protocol suite associated with this ALPN identifier.
ALT-SVC [AltSVC]と同様に、各ALPNプロトコル識別子を使用して、エンドポイント（「プロトコルスイート」）でサポートされているアプリケーションプロトコルと関連するプロトコルのスイートを識別します。SVCB ALPNセットにALPNプロトコル識別子の存在は、TargetNameおよびその他のパラメーター（「ポート」など）で記述されたこのサービスエンドポイントが、このALPN識別子に関連付けられたプロトコルスイートでサービスを提供することを示しています。
Clients filter the set of ALPN identifiers to match the protocol suites they support, and this informs the underlying transport protocol used (such as QUIC over UDP or TLS over TCP). ALPN protocol identifiers that do not uniquely identify a protocol suite (e.g., an Identification Sequence that can be used with both TLS and DTLS) are not compatible with this SvcParamKey and MUST NOT be included in the SVCB ALPN set.
クライアントは、ALPN識別子のセットをフィルタリングしてサポートするプロトコルスイートに一致します。これは、使用される基礎となる輸送プロトコル（UDPよりもQUICやTCPよりもTLSなど）を通知します。プロトコルスイートを一意に識別しないALPNプロトコル識別子（たとえば、TLSとDTLの両方で使用できる識別シーケンス）は、このSVCParamkeyと互換性がなく、SVCB ALPNセットに含める必要はありません。
ALPNs are identified by their registered "Identification Sequence" (alpn-id), which is a sequence of 1-255 octets.
ALPNは、登録された「識別シーケンス」（ALPN-ID）によって識別されます。これは、1〜255オクテットのシーケンスです。
alpn-id = 1*255OCTET
For "alpn", the presentation value SHALL be a comma-separated list (Appendix A.1) of one or more alpn-ids. Zone-file implementations MAY disallow the "," and "\" characters in ALPN IDs instead of implementing the value-list escaping procedure, relying on the opaque key format (e.g., key1=\002h2) in the event that these characters are needed.
「ALPN」の場合、プレゼンテーション値は、1つ以上のALPN-IDのコンマ分離リスト（付録A.1）でなければなりません。ゾーンファイルの実装は、これらの文字が必要な場合に不透明なキー形式（key1 = \ 002h2など）に依存して、値リストの逃げる手順を実装する代わりに、alpn idsの「、」文字を許可する場合があります。。
The wire-format value for "alpn" consists of at least one alpn-id prefixed by its length as a single octet, and these length-value pairs are concatenated to form the SvcParamValue. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed.
「ALPN」のワイヤ形式値は、その長さによって単一のオクテットとして付けられた少なくとも1つのALPN-IDで構成されており、これらの長さと価値のペアは連結されてSVCPARAMValueを形成します。これらのペアは、svcparamvalueを正確に埋める必要があります。それ以外の場合、svcparamvalueは奇形です。
For "no-default-alpn", the presentation and wire-format values MUST be empty. When "no-default-alpn" is specified in an RR, "alpn" must also be specified in order for the RR to be "self-consistent" (Section 2.4.3).
「no-default-alpn」の場合、プレゼンテーションとワイヤー形式の値は空でなければなりません。「no-default-alpn」がRRで指定されている場合、RRが「自己整合的」になるためには、「ALPN」も指定する必要があります（セクション2.4.3）。
Each scheme that uses this SvcParamKey defines a "default set" of ALPN IDs that are supported by nearly all clients and servers; this set MAY be empty. To determine the SVCB ALPN set, the client starts with the list of alpn-ids from the "alpn" SvcParamKey, and it adds the default set unless the "no-default-alpn" SvcParamKey is present.
このSVCParamkeyを使用する各スキームは、ほぼすべてのクライアントとサーバーによってサポートされているALPN IDの「デフォルトセット」を定義します。このセットは空になる可能性があります。SVCB ALPNセットを決定するために、クライアントは「ALPN」SVCParamkeyのALPN-IDのリストから開始し、「no-default-alpn」svcparamkeyが存在しない限りデフォルトセットを追加します。
To establish a connection to the endpoint, clients MUST
エンドポイントへの接続を確立するには、クライアントは
1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB ALPN set that the client supports.
1. SVCB-ALPNインターセクションを、クライアントがサポートするSVCB ALPNセットのプロトコルのセットとします。
2. Let Intersection-Transports be the set of transports (e.g., TLS, DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.
2. 交差点輸送は、SVCB-ALPNインターセクションのプロトコルによって暗示される輸送のセット（たとえば、TLS、DTLS、QUIC）のセットとします。
3. For each transport in Intersection-Transports, construct a ProtocolNameList containing the Identification Sequences of all the client's supported ALPN protocols for that transport, without regard to the SVCB ALPN set.
3. 交差点輸送の各トランスポートについて、SVCB ALPNセットに関係なく、そのトランスポート用のすべてのクライアントのサポートされているALPNプロトコルの識別シーケンスを含むプロトコルナムリストを作成します。
For example, if the SVCB ALPN set is ["http/1.1", "h3"] and the client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using TLS over TCP with a ProtocolNameList of ["http/1.1", "h2"] and could also attempt a connection using QUIC with a ProtocolNameList of ["h3"].
たとえば、SVCB ALPNセットが["http/1.1"、 "h3"]の場合、クライアントがHTTP/1.1、HTTP/2、およびHTTP/3をサポートする場合、クライアントはTCPを使用してTLSを使用してプロトコルナムマリストを接続しようとすることができます。["http/1.1"、 "h2"]の["h3"]のプロトコルナムリストを使用してquicを使用して接続を試みることもできます。
Once the client has constructed a ClientHello, protocol negotiation in that handshake proceeds as specified in [ALPN], without regard to the SVCB ALPN set.
クライアントがClientHelloを構築すると、SVCB ALPNセットに関係なく、[ALPN]で指定されているように、その握手のプロトコル交渉が進行します。
Clients MAY implement a fallback procedure, using a less-preferred transport if more-preferred transports fail to connect. This fallback behavior is vulnerable to manipulation by a network attacker who blocks the more-preferred transports, but it may be necessary for compatibility with existing networks.
クライアントは、より優れたトランスポートが接続に失敗した場合、より優れた輸送を使用して、フォールバック手順を実装できます。このフォールバックの動作は、より優れた輸送をブロックするネットワーク攻撃者による操作に対して脆弱ですが、既存のネットワークとの互換性に必要な場合があります。
With this procedure in place, an attacker who can modify DNS and network traffic can prevent a successful transport connection but cannot otherwise interfere with ALPN protocol selection. This procedure also ensures that each ProtocolNameList includes at least one protocol from the SVCB ALPN set.
この手順を導入すると、DNSとネットワークトラフィックを変更できる攻撃者は、輸送接続の成功を防ぐことができますが、それ以外の場合はALPNプロトコルの選択を妨げることはできません。また、この手順により、各プロトコルナムリストには、SVCB ALPNセットからの少なくとも1つのプロトコルが含まれることが保証されます。
Clients SHOULD NOT attempt connection to a service endpoint whose SVCB ALPN set does not contain any supported protocols.
クライアントは、SVCB ALPNセットにサポートされているプロトコルが含まれていないサービスエンドポイントへの接続を試みてはなりません。
To ensure consistency of behavior, clients MAY reject the entire SVCB RRset and fall back to basic connection establishment if all of the compatible RRs indicate "no-default-alpn", even if connection could have succeeded using a non-default ALPN protocol.
動作の一貫性を確保するために、クライアントは、互換性のあるRRのすべてが「ノーデフォルトALPN」を示している場合、SVCB RRSET全体を拒否し、基本的な接続確立に戻ることができます。
Zone operators SHOULD ensure that at least one RR in each RRset supports the default transports. This enables compatibility with the greatest number of clients.
ゾーンオペレーターは、各RRSetに少なくとも1つのRRがデフォルトのトランスポートをサポートするようにする必要があります。これにより、最大数のクライアントとの互換性が可能になります。
The "port" SvcParamKey defines the TCP or UDP port that should be used to reach this alternative endpoint. If this key is not present, clients SHALL use the authority endpoint's port number.
「ポート」SVCParamkeyは、この代替エンドポイントに到達するために使用する必要があるTCPまたはUDPポートを定義します。このキーが存在しない場合、クライアントは機関エンドポイントのポート番号を使用するものとします。
The presentation value of the SvcParamValue is a single decimal integer between 0 and 65535 in ASCII. Any other value (e.g., an empty value) is a syntax error. To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences.
SVCParamValueの表示値は、ASCIIの0〜65535の間の単一の小数整数です。その他の値（空の値など）は構文エラーです。よりシンプルな解析を有効にするために、このSVCParamValueがエスケープシーケンスを含めてはなりません。
The wire format of the SvcParamValue is the corresponding 2-octet numeric value in network byte order.
SVCParamValueのワイヤ形式は、ネットワークバイトの順序で対応する2-OCTET数値です。
If a port-restricting firewall is in place between some client and the service endpoint, changing the port number might cause that client to lose access to the service, so operators should exercise caution when using this SvcParamKey to specify a non-default port.
一部のクライアントとサービスエンドポイントの間にポート制限ファイアウォールが整っている場合、ポート番号を変更すると、クライアントがサービスへのアクセスを失う可能性があるため、オペレーターはこのSVCParamkeyを使用して非デフォルトポートを指定する場合は注意を払う必要があります。
The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName per Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance.
「IPv4Hint」および「IPv6Hint」キーは、クライアントがサービスに到達するために使用できるIPアドレスを伝えます。TargetNameのAおよびAAAAレコードがローカルで利用可能な場合、クライアントはこれらのヒントを無視する必要があります。それ以外の場合、クライアントはセクション3ごとにターゲット名のAおよび/またはAAAAクエリを実行する必要があり、クライアントは将来の接続のためにそれらの応答でIPアドレスを使用する必要があります。クライアントは、ヒントのアドレスを使用して接続を終了することを選択し、代わりにTargetNameクエリに応じてアドレスに切り替えることができます。Aおよび/またはAAAA応答アドレスの使用の失敗は、負荷分散または他の地理認識機能に悪影響を与える可能性があり、それによりクライアントのパフォーマンスを低下させる可能性があります。
The presentation value SHALL be a comma-separated list (Appendix A.1) of one or more IP addresses of the appropriate family in standard textual format [RFC5952] [RFC4001]. To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences.
プレゼンテーション値は、標準のテキスト形式[RFC5952] [RFC4001]で、適切なファミリの1つ以上のIPアドレスのコンマ分離リスト（付録A.1）でなければなりません。よりシンプルな解析を有効にするために、このSVCParamValueがエスケープシーケンスを含めてはなりません。
The wire format for each parameter is a sequence of IP addresses in network byte order (for the respective address family). Like an A or AAAA RRset, the list of addresses represents an unordered collection, and clients SHOULD pick addresses to use in a random order. An empty list of addresses is invalid.
各パラメーターのワイヤ形式は、ネットワークバイト順序の一連のIPアドレスです（それぞれのアドレスファミリ用）。aまたはaaaa rrsetのように、アドレスのリストは順序付けられていないコレクションを表し、クライアントはランダムな順序で使用するアドレスを選択する必要があります。アドレスの空のリストは無効です。
When selecting between IPv4 and IPv6 addresses to use, clients may use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only "ipv4hint" is present, NAT64 clients may synthesize IPv6 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA resolution (Section 3). For best performance, server operators SHOULD include an "ipv6hint" parameter whenever they include an "ipv4hint" parameter.
IPv4アドレスとIPv6アドレスを使用して使用する場合、クライアントはHappy Eyeballs [HappyEyeballsv2]などのアプローチを使用できます。「IPv4Hint」のみが存在する場合、NAT64クライアントは[RFC7050]で指定されているようにIPv6アドレスを合成するか、「IPv4Hint」キーを無視してAAAA解像度を待ちます（セクション3）。最高のパフォーマンスのために、サーバーオペレーターには「IPv6hint」パラメーターが「IPv4hint」パラメーターを含めるときはいつでも含める必要があります。
These parameters are intended to minimize additional connection latency when a recursive resolver is not compliant with the requirements in Section 4 and SHOULD NOT be included if most clients are using compliant recursive resolvers. When TargetName is the service name or the owner name (which can be written as "."), server operators SHOULD NOT include these hints, because they are unlikely to convey any performance benefit.
これらのパラメーターは、再帰的なリゾルバーがセクション4の要件に準拠していない場合、追加の接続レイテンシを最小限に抑えることを目的としており、ほとんどのクライアントが準拠した再帰リソースバーを使用している場合は含めてはなりません。TargetNameがサービス名または所有者名（「。」として記述できる）である場合、サーバーオペレーターは、パフォーマンスの利点を伝える可能性が低いため、これらのヒントを含めるべきではありません。
See Section 8.
セクション8を参照してください。
In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not function correctly for clients that ignore this SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys that are "automatically mandatory", i.e., mandatory if they are present in an RR. The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR, in addition to any automatically mandatory keys that are present.
ServiceMode RRでは、RRがこのSVCParamkeyを無視するクライアントに対して正しく機能しない場合、SVCParamkeyは「必須」と見なされます。各SVCBプロトコルマッピングは、「自動的に必須」のキーのセットを指定する必要があります。つまり、RRに存在する場合は必須です。SVCParamkeyの「必須」は、存在する自動的に必須のキーに加えて、このRRの必須キーを示すために使用されます。
A ServiceMode RR is considered "compatible" by a client if the client recognizes all the mandatory keys and their values indicate that successful connection establishment is possible. Incompatible RRs are ignored (see step 5 of the procedure defined in Section 3).
クライアントがすべての必須キーを認識し、その値が成功した接続確立が可能であることを示している場合、クライアントはクライアントが「互換性がある」と見なされます。互換性のないRRは無視されます（セクション3で定義されている手順のステップ5を参照）。
The presentation value SHALL be a comma-separated list (Appendix A.1) of one or more valid SvcParamKeys, either by their registered name or in the unknown-key format (Section 2.1). Keys MAY appear in any order but MUST NOT appear more than once. For self-consistency (Section 2.4.3), listed keys MUST also appear in the SvcParams.
プレゼンテーション値は、登録名または未知のキー形式（セクション2.1）のいずれかで、1つ以上の有効なSVCParamkeysのコンマ分離リスト（付録A.1）です。キーは任意の順序で表示される場合がありますが、複数回表示してはなりません。自己整合性（セクション2.4.3）の場合、リストされたキーもSVCparamsに表示する必要があります。
To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences.
よりシンプルな解析を有効にするために、このSVCParamValueがエスケープシーケンスを含めてはなりません。
For example, the following is a valid list of SvcParams:
たとえば、以下はsvcparamsの有効なリストです。
ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint
In wire format, the keys are represented by their numeric values in network byte order, concatenated in strictly increasing numeric order.
ワイヤ形式では、キーはネットワークバイトの順序で数値で表され、厳密に増加する数値順序で連結されます。
This SvcParamKey is always automatically mandatory and MUST NOT appear in its own value-list. Other automatically mandatory keys SHOULD NOT appear in the list either. (Including them wastes space and otherwise has no effect.)
このSVCParamkeyは常に自動的に必須であり、独自のバリューリストに表示されてはなりません。その他の自動的に必須のキーもリストに表示されないはずです。（それらを含むスペースを廃棄し、そうでなければ効果はありません。）
The use of any protocol with SVCB requires a protocol-specific mapping specification. This section specifies the mapping for the "http" and "https" URI schemes [HTTP].
SVCBでプロトコルを使用するには、プロトコル固有のマッピング仕様が必要です。このセクションでは、「HTTP」および「HTTPS」URIスキーム[HTTP]のマッピングを指定します。
To enable special handling for HTTP use cases, the HTTPS RR type is defined as a SVCB-compatible RR type, specific to the "https" and "http" schemes. Clients MUST NOT perform SVCB queries or accept SVCB responses for "https" or "http" schemes.
HTTPユースケースの特別な取り扱いを可能にするために、HTTPS RRタイプは、「HTTPS」および「HTTP」スキームに固有のSVCB互換RRタイプとして定義されます。クライアントは、「HTTPS」または「HTTP」スキームのSVCBクエリを実行したり、SVCB応答を受け入れたりしてはなりません。
The presentation format of the record is:
レコードのプレゼンテーション形式は次のとおりです。
Name TTL IN HTTPS SvcPriority TargetName SvcParams
All the SvcParamKeys defined in Section 7 are permitted for use in HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1". The "automatically mandatory" keys (Section 8) are "port" and "no-default-alpn". (As described in Section 8, clients must either implement these keys or ignore any RR in which they appear.) Clients that restrict the destination port in "https" URIs (e.g., using the "bad ports" list from [FETCH]) SHOULD apply the same restriction to the "port" SvcParam.
セクション7で定義されているすべてのSVCParamkeysは、HTTPS RRSでの使用が許可されています。ALPN IDのデフォルトセットは、単一値「HTTP/1.1」です。「自動的に必須」キー（セクション8）は「ポート」と「ノーデフォルトAlpn」です。（セクション8で説明されているように、クライアントはこれらのキーを実装するか、表示されるRRを無視する必要があります。）「https」urisの宛先ポートを制限するクライアント（たとえば、[fetch]の「悪いポート」リストを使用するなど）が必要です。同じ制限を「ポート」SVCPARAMに適用します。
The presence of an HTTPS RR for an origin also indicates that clients should connect securely and use the "https" scheme, as discussed in Section 9.5. This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, while ensuring that the client uses a secure and authenticated connection.
起源のHTTPS RRの存在は、セクション9.5で説明したように、クライアントが安全に接続し、「HTTPS」スキームを使用する必要があることも示しています。これにより、HTTPS RRSは、クライアントが安全で認証された接続を使用するようにしながら、既存の「HTTP」スキームURLに適用できます。
The HTTPS RR parallels the concepts introduced in "HTTP Alternative Services" [AltSvc]. Clients and servers that implement HTTPS RRs are not required to implement Alt-Svc.
HTTPS RRは、「HTTP Alternative Services」[AltSVC]で導入された概念と類似しています。HTTPS RRSを実装するクライアントとサーバーは、Alt-SVCを実装するために必要ではありません。
The HTTPS RR uses Port Prefix Naming (Section 2.3), with one modification: if the scheme is "https" and the port is 443, then the client's original QNAME is equal to the service name (i.e., the origin's hostname), without any prefix labels.
HTTPS RRは、ポートプレフィックスネーミング（セクション2.3）を使用し、1つの変更：スキームが「HTTPS」であり、ポートが443の場合、クライアントの元のQNAMEはサービス名（つまり、Originのホスト名）に等しくなります。プレフィックスラベル。
By removing the Attrleaf labels [Attrleaf] used in SVCB, this construction enables offline DNSSEC signing of wildcard domains, which are commonly used with HTTP. Using the service name as the owner name of the HTTPS record, without prefixes, also allows the targets of existing CNAME chains (e.g., CDN hosts) to start returning HTTPS RR responses without requiring origin domains to configure and maintain an additional delegation.
SVCBで使用されるアトリーフラベル[attrleaf]を削除することにより、この構造により、HTTPで一般的に使用されるワイルドカードドメインのオフラインDNSSECの署名が可能になります。サービス名をプレフィックスなしでHTTPSレコードの所有者名として使用すると、既存のCNAMEチェーン（CDNホストなど）のターゲットが、原点ドメインに追加の委任を構成および維持する必要なく、HTTPS RR応答の返却を開始できます。
The procedure for following HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB (as described in Sections 2.4.2 and 3).
HTTPS AliASMODE RRSおよびCNAMEエイリアスを追跡する手順は、SVCBから変更されていません（セクション2.4.2および3で説明されています）。
Clients always convert "http" URLs to "https" before performing an HTTPS RR query using the process described in Section 9.5, so domain owners MUST NOT publish HTTPS RRs with a prefix of "_http".
クライアントは、セクション9.5で説明されているプロセスを使用してHTTPS RRクエリを実行する前に、「HTTP」URLを常に「HTTPS」に変換するため、ドメインの所有者は「_HTTP」のプレフィックスでHTTPS RRSを公開してはなりません。
Note that none of these forms alter the HTTPS origin or authority. For example, clients MUST continue to validate TLS certificate hostnames based on the origin.
これらのフォームのいずれも、HTTPSの起源または権限を変更しないことに注意してください。たとえば、クライアントは、Originに基づいてTLS証明書のホスト名を引き続き検証する必要があります。
Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to transmitting an Alt-Svc field value over HTTP, and receiving an HTTPS RR is intended to be similar to receiving that field value over HTTP. However, there are some differences in the intended client and server behavior.
DNSでServiceMode HTTPS RRを公開することは、HTTPを介してAlt-SVCフィールド値を送信することと同様であることを目的としており、HTTPS RRを受信することは、HTTPを介してそのフィールド値を受信することに似ていることを目的としています。ただし、意図したクライアントとサーバーの動作にはいくつかの違いがあります。
Unlike Alt-Svc field values, HTTPS RRs can contain multiple ALPN IDs. The meaning and use of these IDs are discussed in Section 7.1.2.
Alt-SVCフィールド値とは異なり、HTTPS RRSには複数のALPN IDを含めることができます。これらのIDの意味と使用については、セクション7.1.2で説明します。
HTTPS records do not require or provide any assurance of authenticity. (DNSSEC signing and verification, which would provide such assurance, are OPTIONAL.) The DNS resolution process is modeled as an untrusted channel that might be controlled by an attacker, so Alt-Svc parameters that cannot be safely received in this model MUST NOT have a corresponding defined SvcParamKey. For example, there is no SvcParamKey corresponding to the Alt-Svc "persist" parameter, because this parameter is not safe to accept over an untrusted channel.
HTTPSレコードは、信頼性の保証を必要としないか、提供しません。（そのような保証を提供するDNSSECの署名と検証はオプションです。）DNS解像度プロセスは、攻撃者によって制御される可能性のある信頼されていないチャネルとしてモデル化されているため、このモデルで安全に受信できないALT-SVCパラメーターはそうではありません対応する定義されたSVCParamkey。たとえば、このパラメーターは信頼されていないチャネルで受け入れるのは安全ではないため、Alt-SVCの「永続的な」パラメーターに対応するSVCParamkeyはありません。
There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter. Instead, server operators encode the expiration time in the DNS TTL.
Alt-SVC "Ma"（最大年齢）パラメーターに対応するSVCParamkeyはありません。代わりに、サーバーオペレーターはDNS TTLの有効期限をエンコードします。
The appropriate TTL value might be different from the "ma" value used for Alt-Svc, depending on the desired efficiency and agility. Some DNS caches incorrectly extend the lifetime of DNS records beyond the stated TTL, so server operators cannot rely on HTTPS RRs expiring on time. Shortening the TTL to compensate for incorrect caching is NOT RECOMMENDED, as this practice impairs the performance of correctly functioning caches and does not guarantee faster expiration from incorrect caches. Instead, server operators SHOULD maintain compatibility with expired records until they observe that nearly all connections have migrated to the new configuration.
適切なTTL値は、目的の効率と俊敏性に応じて、ALT-SVCに使用される「MA」値とは異なる場合があります。一部のDNSキャッシュは、指定されたTTLを超えてDNSレコードの寿命を誤って延長するため、サーバーオペレーターは時間通りに期限切れになるHTTPS RRに依存することはできません。このプラクティスは正しく機能するキャッシュのパフォーマンスを損ない、誤ったキャッシュからのより速い有効期限を保証するものではないため、誤ったキャッシュを補うためにTTLを短縮することは推奨されません。代わりに、サーバーオペレーターは、ほとんどすべての接続が新しい構成に移行したことが観察されるまで、期限切れのレコードとの互換性を維持する必要があります。
Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc field value specifically to the client. When using an HTTPS RR, groups of clients will necessarily receive the same SvcParams. Therefore, HTTPS RRs are not suitable for uses that require single-client granularity.
HTTPを介してAlt-SVCを送信すると、サーバーはALT-SVCフィールド値をクライアントに特別に調整できます。HTTPS RRを使用する場合、クライアントのグループは必然的に同じSVCPARAMSを受け取ります。したがって、HTTPS RRSは、単クライアントの粒度を必要とする使用には適していません。
Clients that implement support for both Alt-Svc and HTTPS records and are making a connection based on a cached Alt-Svc response SHOULD retrieve any HTTPS records for the Alt-Svc alt-authority and ensure that their connection attempts are consistent with both the Alt-Svc parameters and any received HTTPS SvcParams. If present, the HTTPS record's TargetName and port are used for connection establishment (per Section 3). For example, suppose that "https://example.com" sends an Alt-Svc field value of:
ALT-SVCとHTTPSレコードの両方のサポートを実装し、キャッシュされたALT-SVC応答に基づいて接続を作成しているクライアントは、ALT-SVC ALT-AuthorityのHTTPSレコードを取得し、接続の試みがALTの両方と一致していることを確認する必要があります。-SVCパラメーターおよび受信したHTTPS svcparams。存在する場合、HTTPSレコードのTargetNameとポートは、接続確立に使用されます（セクション3ごと）。たとえば、「https://example.com」が次のようなalt-svcフィールド値を送信するとします。
Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"
The client would retrieve the following HTTPS records:
クライアントは、次のHTTPSレコードを取得します。
alt.example. IN HTTPS 1 . alpn=h2,h3 foo=...
alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 foo=...
_8443._https.example.com. IN HTTPS 1 alt3.example. (
port=9443 alpn=h2,h3 foo=... )
Based on these inputs, the following connection attempts would always be allowed:
これらの入力に基づいて、次の接続の試行は常に許可されます。
* HTTP/2 to alt.example:443
* http/2 to alt.example：443
* HTTP/3 to alt3.example:9443
* http/3 to alt3.example：9443
* Fallback to the client's non-Alt-Svc connection behavior
* クライアントの非ALT-SVC接続動作へのフォールバック
The following connection attempts would not be allowed:
次の接続試行は許可されません。
* HTTP/3 to alt.example:443 (not consistent with Alt-Svc)
* http/3 to alt.example：443（alt-svcと一致しない）
* Any connection to alt2b.example (no ALPN ID consistent with both the HTTPS record and Alt-Svc)
* alt2b.exampleへの接続（HTTPSレコードとALT-SVCの両方と一致するALPN IDはありません）
* HTTPS over TCP to any port on alt3.example (not consistent with Alt-Svc)
* alt3.exampleの任意のポートにtcpを介してhttps（alt-svcと一致していません）
Suppose that "foo" is a SvcParamKey that renders the client SVCB-reliant. The following Alt-Svc-only connection attempts would be allowed only if the client does not support "foo", as they rely on SVCB-optional fallback behavior:
「foo」は、クライアントSVCB依存者をレンダリングするSVCParamkeyであると仮定します。以下のALT-SVCのみの接続試行は、クライアントがSVCBオプションのフォールバック動作に依存しているため、クライアントが「Foo」をサポートしていない場合にのみ許可されます。
* HTTP/2 to alt2.example:443
* http/2 to alt2.example：443
* HTTP/3 to example.com:8443
* http/3 to example.com：8443
Alt-authorities SHOULD carry the same SvcParams as the origin unless a deviation is specifically known to be safe. As noted in Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc connection according to their own criteria, e.g., disallowing Alt-Svc connections that lack support for privacy features that are available on the authority endpoint.
Alt-authoritiesは、偏差が安全であることが特に知られている場合を除き、原点と同じSVCPARAMを搭載する必要があります。[AltSVC]のセクション2.4で述べたように、クライアントは、独自の基準に従ってAlt-SVC接続を許可する場合があります。
Clients MUST NOT use an HTTPS RR response unless the client supports the TLS Server Name Indication (SNI) extension and indicates the origin name in the TLS ClientHello (which might be encrypted via a future specification such as [ECH]). This supports the conservation of IP addresses.
クライアントがTLSサーバー名表示（SNI）拡張機能をサポートし、TLS ClientHelloのオリジナル名（[ECH]などの将来の仕様を介して暗号化される可能性がある）を示していない限り、クライアントはHTTPS RR応答を使用してはなりません。これは、IPアドレスの保存をサポートします。
Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate the origin, not the TargetName.
TLS SNI（およびHTTP "HOST"または "：authority"）は、ターゲット名ではなく起源を示していることに注意してください。
An HTTPS RR directs the client to communicate with this host only over a secure transport, similar to HSTS [HSTS]. Prior to making an "http" scheme request, the client SHOULD perform a lookup to determine if any HTTPS RRs exist for that origin. To do so, the client SHOULD construct a corresponding "https" URL as follows:
HTTPS RRは、HSTS [HSTS]と同様に、安全なトランスポート上でのみこのホストと通信するようクライアントに指示します。「HTTP」スキーム要求を作成する前に、クライアントは検索を実行して、その起源に対してHTTPS RRが存在するかどうかを判断する必要があります。そのために、クライアントは次のように対応する「HTTPS」URLを構築する必要があります。
1. Replace the "http" scheme with "https".
1. 「HTTP」スキームを「HTTPS」に置き換えます。
2. If the "http" URL explicitly specifies port 80, specify port 443.
2. 「HTTP」URLがポート80を明示的に指定する場合、ポート443を指定します。
3. Do not alter any other aspect of the URL.
3. URLの他の側面を変更しないでください。
This construction is equivalent to Section 8.3 of [HSTS], Step 5.
この構造は、[HSTS]のセクション8.3、ステップ5に相当します。
If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs or any compatible ServiceMode HTTPS RRs (see Section 8), the client SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code with this "https" URL in the "Location" field. (Receipt of an incompatible ServiceMode RR does not trigger the redirect behavior.) Because HTTPS RRs are received over an often-insecure channel (DNS), clients MUST NOT place any more trust in this signal than if they had received a 307 (Temporary Redirect) response over cleartext HTTP.
この「HTTPS」URLのHTTPS RRクエリがAliASMODE HTTPS RRまたは互換性のあるServiceMode HTTPS RRSを返す場合（セクション8を参照）、クライアントはこの「HTTPSでHTTP 307（一時リダイレクト）ステータスコードを受け取ったかのように動作する必要があります。「ロケーション」フィールドのURL。（互換性のないServiceMode RRの受領は、リダイレクト動作をトリガーしません。）HTTPS RRは、しばしば安全なチャネル（DNS）で受信されるため、クライアントは307を受け取った場合よりもこのシグナルに信頼を置いてはなりません（一時リダイレクトを受け取ってはなりません。）ClearText HTTPに対する応答。
Publishing an HTTPS RR can potentially lead to unexpected results or a loss in functionality in cases where the "http" resource neither redirects to the "https" resource nor references the same underlying resource.
HTTPS RRを公開すると、「HTTP」リソースが「HTTPS」リソースにリダイレクトしたり、同じ基礎となるリソースを参照したりしない場合、予期しない結果や機能の損失につながる可能性があります。
When an "https" connection fails due to an error in the underlying secure transport, such as an error in certificate validation, some clients currently offer a "user recourse" that allows the user to bypass the security error and connect anyway. When making an "https" scheme request to an origin with an HTTPS RR, either directly or via the above redirect, such a client MAY remove the user recourse option. Origins that publish HTTPS RRs therefore MUST NOT rely on user recourse for access. For more information, see Sections 8.4 and 12.1 of [HSTS].
証明書の検証のエラーなど、基礎となる安全なトランスポートのエラーにより「HTTPS」接続が失敗した場合、一部のクライアントは現在、ユーザーがセキュリティエラーをバイパスしてとにかく接続できる「ユーザーの頼み」を提供しています。HTTPS RRを使用してOriginに「HTTPS」スキームを要求する場合、直接または上記のリダイレクトを介して、そのようなクライアントはユーザーの頼みのオプションを削除する場合があります。したがって、HTTPS RRSを公開するオリジンは、アクセスのためにユーザーの頼みに依存してはなりません。詳細については、[HSTS]のセクション8.4および12.1を参照してください。
All HTTP connections to named origins are eligible to use HTTPS RRs, even when HTTP is used as part of another protocol or without an explicit HTTP-related URI scheme (Section 4.2 of [HTTP]). For example, clients that support HTTPS RRs and implement [WebSocket] using the altered opening handshake from [FETCH-WEBSOCKETS] SHOULD use HTTPS RRs for the requestURL.
名前のオリジンへのすべてのHTTP接続は、HTTPが別のプロトコルの一部として使用されている場合、または明示的なHTTP関連のURIスキーム（[HTTP]のセクション4.2）なしでもHTTPS RRSを使用する資格があります。たとえば、[fetch-websockets]からの変更されたオープニングハンドシェイクを使用してHTTPS RRSをサポートし、[WebSocket]を実装するクライアントは、requestURLにHTTPS RRSを使用する必要があります。
When HTTP is used in a context where URLs or redirects are not applicable (e.g., connections to an HTTP proxy), clients that find a corresponding HTTPS RR SHOULD implement security upgrade behavior equivalent to that specified in Section 9.5.
HTTPがURLまたはリダイレクトが適用されないコンテキスト（HTTPプロキシへの接続など）で使用される場合、対応するHTTPS RRを見つけたクライアントは、セクション9.5で指定されたものに相当するセキュリティアップグレード動作を実装する必要があります。
Such protocols MAY define their own SVCB mappings, which MAY be defined to take precedence over HTTPS RRs.
このようなプロトコルは、独自のSVCBマッピングを定義する場合があります。これは、HTTPS RRSよりも優先されるように定義される場合があります。
Each ServiceMode RRset can only serve a single scheme. The scheme is indicated by the owner name and the RR type. For the generic SVCB RR type, this means that each owner name can only be used for a single scheme. The underscore prefixing requirement (Section 2.3) ensures that this is true for the initial query, but it is the responsibility of zone owners to choose names that satisfy this constraint when using aliases, including CNAME and AliasMode records.
各ServiceMode RRSetは、単一のスキームのみを提供できます。スキームは、所有者名とRRタイプで示されます。一般的なSVCB RRタイプの場合、これは各所有者名が単一のスキームにのみ使用できることを意味します。アンダースコアのプレフィックス要件（セクション2.3）は、これが初期クエリに当てはまることを保証しますが、ゾーンオーナーの責任は、CNAMEおよびAliASMODEレコードを含むエイリアスを使用するときにこの制約を満たす名前を選択する責任です。
When using the generic SVCB RR type with aliasing, zone owners SHOULD choose alias target names that indicate the scheme in use (e.g., "foosvc.example.net" for "foo" schemes). This will help to avoid confusion when another scheme needs to be added to the configuration. When multiple port numbers are in use, it may be helpful to repeat the prefix labels in the alias target name (e.g., "_1234._foo.svc.example.net").
エイリアシングで汎用SVCB RRタイプを使用する場合、ゾーンオーナーは、使用中のスキームを示すエイリアスターゲット名を選択する必要があります（たとえば、「foo」スキームの「foosvc.example.net」）。これは、別のスキームを構成に追加する必要がある場合、混乱を避けるのに役立ちます。複数のポート番号が使用されている場合、エイリアスターゲット名でプレフィックスラベルを繰り返すと役立つ場合があります（例： "_1234._foo.svc.example.net"）。
To avoid a delay for clients using a non-conforming recursive resolver, domain owners SHOULD minimize the use of AliasMode records and SHOULD choose TargetName according to a predictable convention that is known to the client, so that clients can issue A and/or AAAA queries for TargetName in advance (see Section 5). Unless otherwise specified, the convention is to set TargetName to the service name for an initial ServiceMode record, or to "." if it is reached via an alias.
不適合な再帰リゾルバーを使用しているクライアントの遅延を回避するために、ドメインの所有者はAlismodeレコードの使用を最小限に抑え、クライアントに知られている予測可能な慣習に従ってターゲット名を選択して、クライアントがAおよび/またはAAAAクエリを発行できるようにする必要があります事前にターゲット名の場合（セクション5を参照）。特に指定されていない限り、コンベンションは、初期ServiceModeレコードのターゲット名をサービス名に設定するか、「。」に設定することです。エイリアスを介して到達した場合。
$ORIGIN example.com. ; Origin
foo 3600 IN CNAME foosvc.example.net.
_8080._foo.foo 3600 IN CNAME foosvc.example.net.
bar 300 IN AAAA 2001:db8::2
_9090._bar.bar 3600 IN SVCB 1 bar key65444=...
$ORIGIN example.net. ; Service provider zone
foosvc 3600 IN SVCB 1 . key65333=...
foosvc 300 IN AAAA 2001:db8::1
Figure 1: "foo://foo.example.com:8080" Is Available at "foosvc.example.net", but "bar://bar.example.com:9090" Is Served Locally
図1：「foo：//foo.example.com：8080」は「foosvc.example.net」で入手できますが、「bar：//bar.example.com：9090」が地元で提供されています
Domain owners SHOULD avoid using a TargetName that is below a DNAME, as this is likely unnecessary and makes responses slower and larger. Also, zone structures that require following more than eight aliases (counting both AliasMode and CNAME records) are NOT RECOMMENDED.
ドメインの所有者は、DNAMEの下にあるTargetNameの使用を避ける必要があります。これは、おそらく不要であり、応答がより遅く、より大きくなるためです。また、8つ以上のエイリアスをフォローする必要があるゾーン構造（AliASMODEとCNAMEレコードの両方をカウント）は推奨されません。
Some authoritative DNS servers may not allow A or AAAA records on names starting with an underscore (e.g., [BIND-CHECK-NAMES]). This could create an operational issue when the TargetName contains an Attrleaf label, or when using a TargetName of "." if the owner name contains an Attrleaf label.
一部の権威あるDNSサーバーには、アンダースコア（[Bind-check-names]など）から始まる名前のAまたはAAAAのレコードが許可されない場合があります。これにより、TargetNameにAttrleafラベルが含まれている場合、または "所有者名にアトリーフラベルが含まれている場合。
Consider a simple zone of the form:
フォームの単純なゾーンを考えてみましょう。
$ORIGIN simple.example. ; Simple example zone
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
The domain owner could add this record:
ドメインの所有者はこのレコードを追加できます。
@ 7200 IN HTTPS 1 . alpn=h3
This record would indicate that "https://simple.example" supports QUIC in addition to HTTP/1.1 over TLS over TCP (the implicit default). The record could also include other information (e.g., a non-standard port). For "https://simple.example:8443", the record would be:
このレコードは、「https：//simple.example」は、TCPを介したTLSよりもHTTP/1.1に加えてQUICをサポートしていることを示します（暗黙的なデフォルト）。レコードには、他の情報（標準以外のポートなど）を含めることもできます。「https：//simple.example：8443」の場合、レコードは次のとおりです。
_8443._https 7200 IN HTTPS 1 . alpn=h3
These records also respectively tell clients to replace the scheme with "https" when loading "http://simple.example" or "http://simple.example:8443".
これらのレコードは、それぞれクライアントに、「http：//simple.example」または「http：//simple.example：8443」をロードするときに、スキームを「https」に置き換えることを指示します。
Consider a zone that is using CNAME aliasing:
cnameエイリアシングを使用しているゾーンを検討してください。
$ORIGIN aliased.example. ; A zone that is using a hosting service
; Subdomain aliased to a high-performance server pool
www 7200 IN CNAME pool.svc.example.
; Apex domain on fixed IPs because CNAME is not allowed at the apex
@ 300 IN A 192.0.2.1
IN AAAA 2001:db8::1
With HTTPS RRs, the owner of aliased.example could alias the apex by adding one additional record:
HTTPS RRSを使用すると、Alise.exampleの所有者は、1つのレコードを追加することでApexをエイリアスできます。
@ 7200 IN HTTPS 0 pool.svc.example.
With this record in place, HTTPS-RR-aware clients will use the same server pool for aliased.example and www.aliased.example. (They will also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR-aware clients will just ignore the new record.
このレコードを導入すると、https-rr-awareクライアントは、同じサーバープールを使用してairased.exampleとwww.aliade.exampleを使用します。（また、「http：//aliased.example/...」に「https」にアップグレードします。）非https-rr-awareクライアントは、新しいレコードを無視するだけです。
Similar to CNAME, HTTPS RRs have no impact on the origin name. When connecting, clients will continue to treat the authoritative origins as "https://www.aliased.example" and "https://aliased.example", respectively, and will validate TLS server certificates accordingly.
CNAMEと同様に、HTTPS RRSはオリジン名に影響を与えません。接続すると、クライアントは権威ある起源をそれぞれ「https：//www.aliade.example」および「https：//aliade.example」として扱い続け、それに応じてTLSサーバー証明書を検証します。
Suppose that svc.example's primary server pool supports HTTP/3 but its backup server pool does not. This can be expressed in the following form:
SVC.exampleのプライマリサーバープールがHTTP/3をサポートしているが、そのバックアップサーバープールがサポートしていないと仮定します。これは、次の形式で表現できます。
$ORIGIN svc.example. ; A hosting provider
pool 7200 IN HTTPS 1 . alpn=h2,h3
HTTPS 2 backup alpn=h2 port=8443
pool 300 IN A 192.0.2.2
AAAA 2001:db8::2
backup 300 IN A 192.0.2.3
AAAA 2001:db8::3
This configuration is entirely compatible with the "apex aliasing" example, whether the client supports HTTPS RRs or not. If the client does support HTTPS RRs, all connections will be upgraded to HTTPS, and clients will use HTTP/3 if they can. Parameters are "bound" to each server pool, so each server pool can have its own protocol, port number, etc.
この構成は、クライアントがHTTPS RRSをサポートするかどうかにかかわらず、「APEXエイリアシング」の例と完全に互換性があります。クライアントがHTTPS RRSをサポートしている場合、すべての接続はHTTPSにアップグレードされ、クライアントはできる場合はHTTP/3を使用します。パラメーターは各サーバープールに「バインド」されるため、各サーバープールには独自のプロトコル、ポート番号などがあります。
The HTTPS RR is intended to support HTTPS services operated by multiple independent entities, such as different CDNs or different hosting providers. This includes the case where a service is migrated from one operator to another, as well as the case where the service is multiplexed between multiple operators for performance, redundancy, etc.
HTTPS RRは、異なるCDNや異なるホスティングプロバイダーなど、複数の独立したエンティティが運営するHTTPSサービスをサポートすることを目的としています。これには、サービスがあるオペレーターから別のオペレーターに移行される場合、およびパフォーマンス、冗長性などのために複数のオペレーター間でサービスが多重化される場合が含まれます。
This example shows such a configuration, with www.customer.example having different DNS responses to different queries, either over time or due to logic within the authoritative DNS server:
この例は、www.customer.exampleが異なるクエリに対して異なるDNS応答を持つような構成を示しています。
; This zone contains/returns different CNAME records
; at different points in time. The RRset for "www" can
; only ever contain a single CNAME.
; Sometimes the zone has:
$ORIGIN customer.example. ; A multi-CDN customer domain
www 900 IN CNAME cdn1.svc1.example.
; and other times it contains:
$ORIGIN customer.example.
www 900 IN CNAME customer.svc2.example.
; and yet other times it contains:
$ORIGIN customer.example.
www 900 IN CNAME cdn3.svc3.example.
; With the following remaining constant and always included:
$ORIGIN customer.example. ; A multi-CDN customer domain
; The apex is also aliased to www to match its configuration.
@ 7200 IN HTTPS 0 www
; Non-HTTPS-aware clients use non-CDN IPs.
A 203.0.113.82
AAAA 2001:db8:203::2
; Resolutions following the cdn1.svc1.example
; path use these records.
; This CDN uses a different alternative service for HTTP/3.
$ORIGIN svc1.example. ; domain for CDN 1
cdn1 1800 IN HTTPS 1 h3pool alpn=h3
HTTPS 2 . alpn=h2
A 192.0.2.2
AAAA 2001:db8:192::4
h3pool 300 IN A 192.0.2.3
AAAA 2001:db8:192:7::3
; Resolutions following the customer.svc2.example
; path use these records.
; Note that this CDN only supports HTTP/2.
$ORIGIN svc2.example. ; domain operated by CDN 2
customer 300 IN HTTPS 1 . alpn=h2
60 IN A 198.51.100.2
A 198.51.100.3
A 198.51.100.4
AAAA 2001:db8:198::7
AAAA 2001:db8:198::12
; Resolutions following the cdn3.svc3.example
; path use these records.
; Note that this CDN has no HTTPS records.
$ORIGIN svc3.example. ; domain operated by CDN 3
cdn3 60 IN A 203.0.113.8
AAAA 2001:db8:113::8
Note that in the above example, the different CDNs have different configurations and different capabilities, but clients will use HTTPS RRs as a bound-together unit.
上記の例では、異なるCDNには異なる構成と異なる機能がありますが、クライアントはHTTPS RRをバウンドユニットとして使用します。
Domain owners should be cautious when using a multi-CDN configuration, as it introduces a number of complexities highlighted by this example:
マルチCDN構成を使用する場合、ドメインの所有者は、この例で強調されている多くの複雑さを導入するため、注意する必要があります。
* If CDN 1 supports a desired protocol or feature and CDN 2 does not, the client is vulnerable to downgrade by a network adversary who forces clients to get CDN 2 records.
* CDN 1が目的のプロトコルまたは機能をサポートし、CDN 2がそうでない場合、クライアントはクライアントがCDN 2レコードを取得するように強制するネットワーク敵によって格下げしやすくなります。
* Aliasing the apex to its subdomain simplifies the zone file but likely increases resolution latency, especially when using a non-HTTPS-aware recursive resolver. An alternative would be to alias the zone apex directly to a name managed by a CDN.
* 頂点をサブドメインにエイリアスすると、ゾーンファイルが簡素化されますが、特に非HTTPSを認識していない再帰リゾルバーを使用する場合、解像度の遅延が増加する可能性があります。別の方法は、CDNによって管理された名前にゾーンアペックスを直接エイリアスすることです。
* The A, AAAA, and HTTPS resolutions are independent lookups, so resolvers may observe and follow different CNAMEs to different CDNs. Clients may thus find that the A and AAAA responses do not correspond to the TargetName in the HTTPS response; these clients will need to perform additional queries to retrieve the correct IP addresses. Including ipv6hint and ipv4hint will reduce the performance impact of this case.
* A、AAAA、およびHTTPSの解像度は独立した検索であるため、リゾルバーは異なるCDNを観察し、異なるCNAMEを追跡する場合があります。したがって、クライアントは、AおよびAAAA応答がHTTPS応答のターゲット名に対応していないことを発見する場合があります。これらのクライアントは、正しいIPアドレスを取得するために追加のクエリを実行する必要があります。IPv6hintとIPv4hintを含めると、このケースのパフォーマンスへの影響が減ります。
* If not all CDNs publish HTTPS records, clients will sometimes receive NODATA for HTTPS queries (as with cdn3.svc3.example above) but could receive A/AAAA records from a different CDN. Clients will attempt to connect to this CDN without the benefit of its HTTPS records.
* すべてのCDNSがHTTPSレコードを公開している場合、クライアントはHTTPSクエリのNodata（cdn3.svc3.example上記のように）を受け取ることがありますが、別のCDNからA/AAAAレコードを受信することがあります。クライアントは、HTTPSレコードの利益なしにこのCDNに接続しようとします。
For protocols other than HTTP, the SVCB RR and an Attrleaf label [Attrleaf] will be used. For example, to reach an example resource of "baz://api.example.com:8765", the following SVCB record would be used to alias it to "svc4-baz.example.net.", which in turn could return AAAA/A records and/or SVCB records in ServiceMode:
HTTP以外のプロトコルの場合、SVCB RRとAttreafラベル[アトリーフ]が使用されます。たとえば、「baz：//api.example.com：8765」の例に到達するために、次のSVCBレコードを使用して「svc4-baz.example.net」にエイリアスします。AAAA/Aレコードおよび/またはSVCBレコードのServiceMode：
_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
HTTPS RRs use similar Attrleaf labels if the origin contains a non-default port.
HTTPS RRSは、Originに非デフォルトポートが含まれている場合、同様のアトリーフラベルを使用します。
This standard is intended to reduce connection latency and improve user privacy. Server operators implementing this standard SHOULD also implement TLS 1.3 [RFC8446] and Online Certificate Status Protocol (OCSP) Stapling (i.e., Certificate Status Request in Section 8 of [RFC6066]), both of which confer substantial performance and privacy benefits when used in combination with SVCB records.
この標準は、接続の遅延を減らし、ユーザーのプライバシーを改善することを目的としています。この標準を実装するサーバーオペレーターは、TLS 1.3 [RFC8446]およびオンライン証明書ステータスプロトコル（OCSP）ステープル化（つまり、[RFC6066]のセクション8の証明書ステータス要求）を実装する必要があります。SVCBレコード付き。
To realize the greatest privacy benefits, this proposal is intended for use over a privacy-preserving DNS transport (like DNS over TLS [DoT] or DNS over HTTPS [DoH]). However, performance improvements, and some modest privacy improvements, are possible without the use of those standards.
最大のプライバシーメリットを実現するために、この提案は、プライバシーを提供するDNSトランスポート（TLS [DOT]を介したDNSまたはHTTPS [DOH]を介したDNSなど）で使用することを目的としています。ただし、パフォーマンスの改善、およびいくつかの控えめなプライバシーの改善は、それらの基準を使用せずに可能です。
Any specification for the use of SVCB with a protocol MUST have an entry for its scheme under the SVCB RR type in the IANA DNS "Underscored and Globally Scoped DNS Node Names" registry [Attrleaf]. The scheme MUST have an entry in the "Uniform Resource Identifier (URI) Schemes" registry [RFC7595] and MUST have a defined specification for use with SVCB.
プロトコルを使用してSVCBを使用するための仕様には、IANA DNSのSVCB RRタイプの下にあるスキームのエントリが必要です。スキームには、「均一なリソース識別子（URI）スキーム」レジストリ[RFC7595]にエントリが必要であり、SVCBで使用するための定義仕様が必要です。
SVCB/HTTPS RRs permit distribution over untrusted channels, and clients are REQUIRED to verify that the alternative endpoint is authoritative for the service (similar to Section 2.1 of [AltSvc]). Therefore, DNSSEC signing and validation are OPTIONAL for publishing and using SVCB and HTTPS RRs.
SVCB/HTTPS RRSは、信頼されていないチャネル上の分布を許可しており、クライアントは、代替エンドポイントがサービスの権威あることを確認するために必要です（[AltSVC]のセクション2.1と同様）。したがって、DNSSECの署名と検証は、SVCBおよびHTTPS RRSを公開および使用するためにオプションです。
Clients MUST ensure that their DNS cache is partitioned for each local network, or flushed on network changes, to prevent a local adversary in one network from implanting a forged DNS record that allows them to track users or hinder their connections after they leave that network.
クライアントは、DNSキャッシュがローカルネットワークごとに分割されたり、ネットワークの変更でフラッシュされたりして、1つのネットワーク内のローカル敵が偽造されたDNSレコードを埋め込むことを防ぐ必要があります。
An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, even when the client and recursive resolver validate DNSSEC and use a secure transport. These downgrade attacks can prevent the "https" upgrade provided by the HTTPS RR (Section 9.5) and can disable any other protections coordinated via SvcParams. To prevent downgrades, Section 3.1 recommends that clients abandon the connection attempt when such an attack is detected.
SVCBの解決を防ぐことができる攻撃者は、関連するセキュリティ利益をクライアントに拒否できます。敵対的な再帰リゾルバーは、常にSVCBクエリへのサービスを拒否できますが、ネットワーク仲介業者は、クライアントと再帰リゾルバーがDNSSECを検証し、安全なトランスポートを使用する場合でも、解決を防ぐことができます。これらのダウングレード攻撃は、HTTPS RR（セクション9.5）によって提供される「HTTPS」アップグレードを防ぎ、SVCParamsを介して調整された他の保護を無効にすることができます。ダウングレードを防ぐために、セクション3.1は、そのような攻撃が検出されたときにクライアントが接続の試みを放棄することを推奨します。
A hostile DNS intermediary might forge AliasMode "." records (Section 2.5.1) as a way to block clients from accessing particular services. Such an adversary could already block entire domains by forging erroneous responses, but this mechanism allows them to target particular protocols or ports within a domain. Clients that might be subject to such attacks SHOULD ignore AliasMode "." records.
敵対的なDNS仲介者は、アリスマデを偽造する可能性があります。クライアントが特定のサービスへのアクセスをブロックする方法としての記録（セクション2.5.1）。このような敵は、誤った応答を偽造することにより、すでにドメイン全体をブロックする可能性がありますが、このメカニズムにより、ドメイン内の特定のプロトコルまたはポートをターゲットにすることができます。そのような攻撃の対象となる可能性のあるクライアントは、AliAsmodeを無視する必要があります。記録。
A hostile DNS intermediary or authoritative server can return SVCB records indicating any IP address and port number, including IP addresses inside the local network and port numbers assigned to internal services. If the attacker can influence the client's payload (e.g., TLS session ticket contents) and an internal service has a sufficiently lax parser, the attacker could gain access to the internal service. (The same concerns apply to SRV records, HTTP Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping documents SHOULD indicate any port number restrictions that are appropriate for the supported transports.
敵対的なDNS仲介者または権威あるサーバーは、ローカルネットワーク内のIPアドレスや内部サービスに割り当てられたポート番号を含むIPアドレスとポート番号を示すSVCBレコードを返すことができます。攻撃者がクライアントのペイロード（TLSセッションチケットのコンテンツなど）に影響を与え、内部サービスが十分に緩いパーサーを持っている場合、攻撃者は内部サービスにアクセスできます。（同じ懸念がSRVレコード、HTTP ALT-SVC、およびHTTPリダイレクトに適用されます。）緩和として、SVCBマッピングドキュメントは、サポートされている輸送に適したポート番号の制限を示す必要があります。
Standard address queries reveal the user's intent to access a particular domain. This information is visible to the recursive resolver, and to many other parties when plaintext DNS transport is used. SVCB queries, like queries for SRV records and other specific RR types, additionally reveal the user's intent to use a particular protocol. This is not normally sensitive information, but it should be considered when adding SVCB support in a new context.
標準アドレスクエリは、特定のドメインにアクセスするユーザーの意図を明らかにしています。この情報は、再帰的なリゾルバー、およびPlantext DNSトランスポートが使用される場合の他の多くの関係者に表示されます。SRVレコードやその他の特定のRRタイプのクエリなど、SVCBクエリは、特定のプロトコルを使用するというユーザーの意図をさらに明らかにします。これは通常、機密情報ではありませんが、新しいコンテキストでSVCBサポートを追加するときに考慮する必要があります。
IANA has registered the following new DNS RR type in the "Resource Record (RR) TYPEs" registry on the "Domain Name System (DNS) Parameters" page:
IANAは、「ドメイン名システム（DNS）パラメーター」ページで「リソースレコード（RR）タイプ」レジストリに次の新しいDNS RRタイプを登録しました。
Type:
タイプ：
SVCB
SVCB
Value:
価値：
64
64
Meaning:
意味：
General-purpose service binding
汎用サービスバインディング
Reference:
参照：
RFC 9460
RFC 9460
IANA has registered the following new DNS RR type in the "Resource Record (RR) TYPEs" registry on the "Domain Name System (DNS) Parameters" page:
IANAは、「ドメイン名システム（DNS）パラメーター」ページで「リソースレコード（RR）タイプ」レジストリに次の新しいDNS RRタイプを登録しました。
Type:
タイプ：
HTTPS
https
Value:
価値：
65
65
Meaning:
意味：
SVCB-compatible type for use with HTTP
HTTPで使用するSVCB互換タイプ
Reference:
参照：
RFC 9460
RFC 9460
IANA has created the "Service Parameter Keys (SvcParamKeys)" registry in the "Domain Name System (DNS) Parameters" category on a new page entitled "DNS Service Bindings (SVCB)". This registry defines the namespace for parameters, including string representations and numeric SvcParamKey values. This registry is shared with other SVCB-compatible RR types, such as the HTTPS RR.
IANAは、「DNS Service Bindings（SVCB）」というタイトルの新しいページに「ドメイン名システム（DNS）パラメーター」カテゴリに「Service Parameter Keys（SVCParamkeys）」レジストリを作成しました。このレジストリは、文字列表現や数値SVCParamkey値を含むパラメーターの名前空間を定義します。このレジストリは、HTTPS RRなどの他のSVCB互換RRタイプと共有されます。
A registration MUST include the following fields:
登録には、次のフィールドを含める必要があります。
Number:
番号：
Wire-format numeric identifier (range 0-65535)
ワイヤ形式の数値識別子（範囲0-65535）
Name:
名前：
Unique presentation name
ユニークなプレゼンテーション名
Meaning:
意味：
A short description
簡単な説明
Reference:
参照：
Location of specification or registration source
仕様または登録ソースの場所
Change Controller:
Change Controller：
Person or entity, with contact information if appropriate
必要に応じて連絡先情報を含む個人またはエンティティ
The characters in the registered Name field entry MUST be lowercase alphanumeric or "-" (Section 2.1). The name MUST NOT start with "key" or "invalid".
登録名のフィールドエントリの文字は、小文字の英数字または「 - 」でなければなりません（セクション2.1）。名前は、「キー」または「無効」から始めてはなりません。
The registration policy for new entries is Expert Review ([RFC8126], Section 4.5). The designated expert MUST ensure that the reference is stable and publicly available and that it specifies how to convert the SvcParamValue's presentation format to wire format. The reference MAY be any individual's Internet-Draft or a document from any other source with similar assurances of stability and availability. An entry MAY specify a reference of the form "Same as (other key name)" if it uses the same presentation and wire formats as an existing key.
新しいエントリの登録ポリシーは、専門家レビュー（[RFC8126]、セクション4.5）です。指定された専門家は、参照が安定して公開されていることを確認し、SVCParamValueのプレゼンテーション形式をワイヤ形式に変換する方法を指定する必要があります。参照は、安定性と可用性に関する同様の保証を持つ他のソースからの個人のインターネットドラフトまたはドキュメントである場合があります。エントリは、既存のキーと同じプレゼンテーションとワイヤー形式を使用する場合、「（他のキー名）と同じ（他のキー名）と同じ」フォームの参照を指定できます。
This arrangement supports the development of new parameters while ensuring that zone files can be made interoperable.
この配置は、ゾーンファイルを相互運用可能にできるようにしながら、新しいパラメーターの開発をサポートします。
The "Service Parameter Keys (SvcParamKeys)" registry has been populated with the following initial registrations:
「Service Parameter Keys（svcparamkeys）」レジストリには、以下の初期登録が入力されています。
+===========+=================+================+=========+==========+
| Number | Name | Meaning |Reference|Change |
| | | | |Controller|
+===========+=================+================+=========+==========+
| 0 | mandatory | Mandatory |RFC 9460,|IETF |
| | | keys in this |Section 8| |
| | | RR | | |
+-----------+-----------------+----------------+---------+----------+
| 1 | alpn | Additional |RFC 9460,|IETF |
| | | supported |Section | |
| | | protocols |7.1 | |
+-----------+-----------------+----------------+---------+----------+
| 2 | no-default-alpn | No support |RFC 9460,|IETF |
| | | for default |Section | |
| | | protocol |7.1 | |
+-----------+-----------------+----------------+---------+----------+
| 3 | port | Port for |RFC 9460,|IETF |
| | | alternative |Section | |
| | | endpoint |7.2 | |
+-----------+-----------------+----------------+---------+----------+
| 4 | ipv4hint | IPv4 address |RFC 9460,|IETF |
| | | hints |Section | |
| | | |7.3 | |
+-----------+-----------------+----------------+---------+----------+
| 5 | ech | RESERVED |N/A |IETF |
| | | (held for | | |
| | | Encrypted | | |
| | | ClientHello) | | |
+-----------+-----------------+----------------+---------+----------+
| 6 | ipv6hint | IPv6 address |RFC 9460,|IETF |
| | | hints |Section | |
| | | |7.3 | |
+-----------+-----------------+----------------+---------+----------+
|65280-65534| N/A | Reserved for |RFC 9460 |IETF |
| | | Private Use | | |
+-----------+-----------------+----------------+---------+----------+
| 65535 | N/A | Reserved |RFC 9460 |IETF |
| | | ("Invalid | | |
| | | key") | | |
+-----------+-----------------+----------------+---------+----------+
Table 1
Per [Attrleaf], the following entry has been added to the DNS "Underscored and Globally Scoped DNS Node Names" registry:
[attrleaf]ごとに、次のエントリがDNSに追加されました。
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| HTTPS | _https | RFC 9460 |
+---------+------------+-----------+
Table 2
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[DoH] 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>.
[DoT] 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>.
[HappyEyeballsV2]
Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>.
[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>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001,
<https://www.rfc-editor.org/info/rfc3225>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,
<https://www.rfc-editor.org/info/rfc4001>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[WebSocket]
Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
[AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[ANAME-DNS-RR]
Finch, T., Hunt, E., van Dijk, P., Eden, A., and W.
Mekking, "Address-specific DNS aliases (ANAME)", Work in
Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8
July 2019, <https://datatracker.ietf.org/doc/html/draft-
ietf-dnsop-aname-04>.
[BIND-CHECK-NAMES]
Internet Systems Consortium, "BIND v9.19.11 Configuration
Reference: "check-names"", September 2023,
<https://bind9.readthedocs.io/en/v9.19.11/
reference.html#namedconf-statement-check-names>.
[DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-17, 9 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-17>.
[FETCH] WHATWG, "Fetch Living Standard", October 2023,
<https://fetch.spec.whatwg.org/>.
[FETCH-WEBSOCKETS]
WHATWG, "WebSockets Living Standard", September 2023,
<https://websockets.spec.whatwg.org/>.
[HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>.
[HTTP-DNS-RR]
Bellis, R., "A DNS Resource Record for HTTP", Work in
Progress, Internet-Draft, draft-bellis-dnsop-http-record-
00, 3 November 2018,
<https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-
http-record-00>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
<https://www.rfc-editor.org/info/rfc1912>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
DNS zone files are capable of representing arbitrary octet sequences in basic ASCII text, using various delimiters and encodings, according to an algorithm defined in Section 5.1 of [RFC1035]. The following summarizes some allowed inputs to that algorithm, using ABNF:
DNSゾーンファイルは、[RFC1035]のセクション5.1で定義されているアルゴリズムに従って、さまざまな区切り文字とエンコーディングを使用して、基本的なASCIIテキストの任意のオクテットシーケンスを表すことができます。以下は、ABNFを使用して、そのアルゴリズムへの許可された入力を要約しています。
; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\".
non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E
; non-digit is VCHAR minus DIGIT.
non-digit = %x21-2F / %x3A-7E
; dec-octet is a number 0-255 as a three-digit decimal number.
dec-octet = ( "0" / "1" ) 2DIGIT /
"2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )
escaped = "\" ( non-digit / dec-octet )
contiguous = 1*( non-special / escaped )
quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE
char-string = contiguous / quoted
The decoding algorithm allows char-string to represent any *OCTET, using quoting to group values (e.g., those with internal whitespace), and escaping to represent each non-printable octet as a single escaped sequence. In this document, this algorithm is referred to as "character-string decoding", because Section 5.1 of [RFC1035] uses this algorithm to produce a <character-string>. Note that while the length of a <character-string> is limited to 255 octets, the character-string decoding algorithm can produce output of any length.
デコードアルゴリズムにより、チャーストリングは任意の *オクテットを表すことができ、引用符はグループ値（例えば、内部の空白のあるもの）に引用を使用し、それぞれの印刷不可能なオクテットを単一の脱出シーケンスとして表すために逃げます。このドキュメントでは、[RFC1035]のセクション5.1がこのアルゴリズムを使用してA <文字ストリング>を生成するため、このアルゴリズムは「キャラクターストリングデコード」と呼ばれます。A <文字ストリング>の長さは255オクテットに制限されていますが、文字弦デコードアルゴリズムは任意の長さの出力を生成できることに注意してください。
In order to represent lists of items in zone files, this specification uses comma-separated lists. When the allowed items in the list cannot contain "," or "\", this is trivial. (For simplicity, empty items are not allowed.) A value-list parser that splits on "," and prohibits items containing "\" is sufficient to comply with all requirements in this document. This corresponds to the simple-comma-separated syntax:
ゾーンファイル内のアイテムのリストを表すために、この仕様ではコンマ区切りリストを使用します。リスト内の許可されたアイテムが「、」または「\」を含めることができない場合、これは些細なことです。（簡単にするために、空のアイテムは許可されていません。）「\」を含むアイテムを含む項目を禁止するバリューリストパーサーは、このドキュメントのすべての要件を遵守するのに十分です。これは、単純なコマを分離した構文に対応します。
; item-allowed is OCTET minus "," and "\".
item-allowed = %x00-2B / %x2D-5B / %x5D-FF
simple-item = 1*item-allowed
simple-comma-separated = [simple-item *("," simple-item)]
For implementations that allow "," and "\" in item values, the following escaping syntax applies:
アイテム値に「」、「\」を許可する実装の場合、次の逃げる構文が適用されます。
item = 1*OCTET
escaped-item = 1*(item-allowed / "\," / "\\")
comma-separated = [escaped-item *("," escaped-item)]
Decoding of value-lists happens after character-string decoding. For example, consider these char-string SvcParamValues:
バリューリストのデコードは、文字通りのデコード後に発生します。たとえば、これらのチャーストリングsvcparamvaluesを考慮してください。
"part1,part2,part3\\,part4\\\\"
part1\,\p\a\r\t2\044part3\092,part4\092\\
These inputs are equivalent: character-string decoding either of them would produce the same value:
これらの入力は同等です。文字弦デコードのいずれかが同じ値を生成すると、次の値が生成されます。
part1,part2,part3\,part4\\
Applying comma-separated list decoding to this value would produce a list of three items:
この値にデコードするコンマ分離リストを適用すると、3つの項目のリストが作成されます。
part1
part2
part3,part4\
This table serves as a non-normative summary of the HTTP mapping for SVCB (Section 9). Future protocol mappings may provide a similar summary table.
この表は、SVCBのHTTPマッピングの非規範的な要約として機能します（セクション9）。将来のプロトコルマッピングは、同様の要約表を提供する場合があります。
+--------------------------+----------------------+
| *Mapped scheme* | "https" |
+--------------------------+----------------------+
| *Other affected schemes* | "http", "wss", "ws", |
| | (other HTTP-based) |
+--------------------------+----------------------+
| *RR type* | HTTPS (65) |
+--------------------------+----------------------+
| *Name prefix* | None for port 443, |
| | else _$PORT._https |
+--------------------------+----------------------+
| *Automatically mandatory | port, no-default- |
| keys* | alpn |
+--------------------------+----------------------+
| *SvcParam defaults* | alpn: ["http/1.1"] |
+--------------------------+----------------------+
| *Special behaviors* | Upgrade from HTTP to |
| | HTTPS |
+--------------------------+----------------------+
| *Keys that records must | None |
| include* | |
+--------------------------+----------------------+
Table 3
The SVCB and HTTPS RR types closely resemble, and are inspired by, some existing record types and proposals. One complaint regarding all of the alternatives is that web clients have seemed unenthusiastic about implementing them. The hope here is that an extensible solution that solves multiple problems will overcome this inertia and have a path to achieve client implementation.
SVCBおよびHTTPS RRタイプは、いくつかの既存のレコードタイプと提案に非常に似ており、触発されています。すべての代替案に関する1つの不満は、Webクライアントがそれらを実装することに熱心に存在していないように見えることです。ここでの希望は、複数の問題を解決する拡張可能なソリューションがこの慣性を克服し、クライアントの実装を達成するための道を持つことです。
An SRV record [SRV] can perform a function similar to that of the SVCB record, informing a client to look in a different location for a service. However, there are several differences:
SRVレコード[SRV]は、SVCBレコードの機能と同様の関数を実行でき、クライアントにサービスの別の場所を調べるように通知できます。ただし、いくつかの違いがあります。
* SRV records are typically mandatory, whereas SVCB is intended to be optional when used with pre-existing protocols.
* SRVレコードは通常必須ですが、SVCBは既存のプロトコルで使用する場合にオプションになることを目的としています。
* SRV records cannot instruct the client to switch or upgrade protocols, whereas SVCB can signal such an upgrade (e.g., to HTTP/2).
* SRVレコードは、クライアントにプロトコルを切り替えたりアップグレードしたりするように指示することはできませんが、SVCBはそのようなアップグレード（例：HTTP/2）を信号することができます。
* SRV records are not extensible, whereas SVCB and HTTPS RRs can be extended with new parameters.
* SRVレコードは拡張できませんが、SVCBおよびHTTPS RRSは新しいパラメーターで拡張できます。
* SRV records specify a "weight" for unbalanced randomized load balancing. SVCB only supports balanced randomized load balancing, although weights could be added via a future SvcParam.
* SRVレコードは、不均衡なランダム化負荷分散の「重量」を指定します。SVCBは、バランスの取れたランダム化負荷分散のみをサポートしますが、将来のSVCparamを介して重みを追加できます。
Unlike [HTTP-DNS-RR], this approach is extensible to cover Alt-Svc and Encrypted ClientHello use cases. Like that proposal, this addresses the zone-apex CNAME challenge.
[http-dns-rr]とは異なり、このアプローチは、Alt-SVCおよび暗号化されたClientHelloユースケースをカバーするために拡張可能です。その提案のように、これはZone-Apex CName Challengeに対処します。
Like that proposal, it remains necessary to continue to include address records at the zone apex for legacy clients.
その提案のように、レガシークライアントのゾーンアペックスに住所記録を引き続き含める必要があります。
Unlike [ANAME-DNS-RR], this approach is extensible to cover Alt-Svc and Encrypted ClientHello use cases. This approach also does not require any changes or special handling on either authoritative or primary servers, beyond optionally returning in-bailiwick additional records.
[ANAME-DNS-RR]とは異なり、このアプローチはAlt-SVCおよび暗号化されたClientHelloユースケースをカバーするために拡張可能です。また、このアプローチでは、オプションでバイリウィックの追加レコードを返すことを超えて、権威あるサーバーまたはプライマリサーバーの変更や特別な取り扱いは必要ありません。
Like that proposal, this addresses the zone-apex CNAME challenge for clients that implement this.
その提案のように、これはこれを実装するクライアントのゾーンAPEX CNAMEチャレンジに対処します。
However, with this SVCB proposal, it remains necessary to continue to include address records at the zone apex for legacy clients. If deployment of this standard is successful, the number of legacy clients will fall over time. As the number of legacy clients declines, the operational effort required to serve these users without the benefit of SVCB indirection should fall. Server operators can easily observe how much traffic reaches this legacy endpoint and may remove the apex's address records if the observed legacy traffic has fallen to negligible levels.
ただし、このSVCBの提案により、レガシークライアントのゾーンアペックスに住所記録を引き続き含める必要があります。この標準の展開が成功した場合、レガシークライアントの数は時間とともに減少します。レガシークライアントの数が減少するにつれて、SVCBの間接の恩恵を受けることなくこれらのユーザーにサービスを提供するために必要な運用努力が低下するはずです。サーバーオペレーターは、このレガシーエンドポイントに到達するトラフィックの量を簡単に観察でき、観察されたレガシートラフィックが無視できるレベルに低下した場合、Apexのアドレスレコードを削除する場合があります。
Abstractly, functions of AliasMode and ServiceMode are independent, so it might be tempting to specify them as separate RR types. However, this would result in serious performance impairment, because clients cannot rely on their recursive resolver to follow SVCB aliases (unlike CNAME). Thus, clients would have to issue queries for both RR types in parallel, potentially at each step of the alias chain. Recursive resolvers that implement the specification would, upon receipt of a ServiceMode query, emit both a ServiceMode query and an AliasMode query to the authoritative DNS server. Thus, splitting the RR type would double, or in some cases triple, the load on clients and servers, and would not reduce implementation complexity.
抽象的には、AliAsmodeとServiceModeの関数は独立しているため、個別のRRタイプとして指定するのが魅力的かもしれません。ただし、クライアントはSVCBエイリアスを追跡するために再帰的なリゾルバーに依存することはできないため、これは深刻なパフォーマンス障害につながります（CNAMEとは異なります）。したがって、クライアントは両方のRRタイプのクエリを並列で、潜在的にエイリアスチェーンの各ステップで発行する必要があります。仕様を実装する再帰リゾルバーは、ServiceModeクエリを受信すると、ServiceModeクエリとAliASMODEクエリの両方を権威あるDNSサーバーに発射します。したがって、RRタイプの分割は、クライアントとサーバーの負荷を2倍にするか、場合によっては3倍になり、実装の複雑さを軽減しません。
These test vectors only contain the RDATA portion of SVCB/HTTPS records in presentation format, generic format [RFC3597], and wire format. The wire format uses hexadecimal (\xNN) for each non-ASCII byte. As the wire format is long, it is broken into several lines.
これらのテストベクトルには、SVCB/HTTPSレコードのRDATA部分のみがプレゼンテーション形式、汎用形式[RFC3597]、およびワイヤ形式のみが含まれています。ワイヤ形式は、各非ASCIIバイトに対して16進数（\ xnn）を使用します。ワイヤ形式が長いため、いくつかの行に分かれています。
example.com. HTTPS 0 foo.example.com.
\# 19 (
00 00 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
)
\x00\x00 # priority
\x03foo\x07example\x03com\x00 # target
Figure 2: AliasMode
図2：aliAsmode
example.com. SVCB 1 .
\# 3 (
00 01 ; priority
00 ; target (root label)
)
\x00\x01 # priority
\x00 # target (root label)
Figure 3: TargetName Is "."
図3：TargetNameは「」です。
example.com. SVCB 16 foo.example.com. port=53
\# 25 (
00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 03 ; key 3
00 02 ; length 2
00 35 ; value
)
\x00\x10 # priority
\x03foo\x07example\x03com\x00 # target
\x00\x03 # key 3
\x00\x02 # length 2
\x00\x35 # value
Figure 4: Specifies a Port
図4：ポートを指定します
example.com. SVCB 1 foo.example.com. key667=hello
\# 28 (
00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b ; key 667
00 05 ; length 5
68 65 6c 6c 6f ; value
)
\x00\x01 # priority
\x03foo\x07example\x03com\x00 # target
\x02\x9b # key 667
\x00\x05 # length 5
hello # value
Figure 5: A Generic Key and Unquoted Value
図5：一般的なキーと引用のない値
example.com. SVCB 1 foo.example.com. key667="hello\210qoo"
\# 32 (
00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b ; key 667
00 09 ; length 9
68 65 6c 6c 6f d2 71 6f 6f ; value
)
\x00\x01 # priority
\x03foo\x07example\x03com\x00 # target
\x02\x9b # key 667
\x00\x09 # length 9
hello\xd2qoo # value
Figure 6: A Generic Key and Quoted Value with a Decimal Escape
図6：小数点以下のエスケープを伴う一般的なキーと引用値
example.com. SVCB 1 foo.example.com. (
ipv6hint="2001:db8::1,2001:db8::53:1"
)
\# 55 (
00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 06 ; key 6
00 20 ; length 32
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address
20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address
)
\x00\x01 # priority
\x03foo\x07example\x03com\x00 # target
\x00\x06 # key 6
\x00\x20 # length 32
\x20\x01\x0d\xb8\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x01 # first address
\x20\x01\x0d\xb8\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x53\x00\x01 # second address
Figure 7: Two Quoted IPv6 Hints
図7：引用された2つのIPv6ヒント
example.com. SVCB 1 example.com. (
ipv6hint="2001:db8:122:344::192.0.2.33"
)
\# 35 (
00 01 ; priority
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 06 ; key 6
00 10 ; length 16
20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address
)
\x00\x01 # priority
\x07example\x03com\x00 # target
\x00\x06 # key 6
\x00\x10 # length 16
\x20\x01\x0d\xb8\x01\x22\x03\x44
\x00\x00\x00\x00\xc0\x00\x02\x21 # address
Figure 8: An IPv6 Hint Using the Embedded IPv4 Syntax
図8：埋め込まれたIPv4構文を使用したIPv6ヒント
example.com. SVCB 16 foo.example.org. (
alpn=h2,h3-19 mandatory=ipv4hint,alpn
ipv4hint=192.0.2.1
)
\# 48 (
00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 00 ; key 0
00 04 ; param length 4
00 01 ; value: key 1
00 04 ; value: key 4
00 01 ; key 1
00 09 ; param length 9
02 ; alpn length 2
68 32 ; alpn value
05 ; alpn length 5
68 33 2d 31 39 ; alpn value
00 04 ; key 4
00 04 ; param length 4
c0 00 02 01 ; param value
)
\x00\x10 # priority
\x03foo\x07example\x03org\x00 # target
\x00\x00 # key 0
\x00\x04 # param length 4
\x00\x01 # value: key 1
\x00\x04 # value: key 4
\x00\x01 # key 1
\x00\x09 # param length 9
\x02 # alpn length 2
h2 # alpn value
\x05 # alpn length 5
h3-19 # alpn value
\x00\x04 # key 4
\x00\x04 # param length 4
\xc0\x00\x02\x01 # param value
Figure 9: SvcParamKey Ordering Is Arbitrary in Presentation Format but Sorted in Wire Format
図9：SVCParamkeyの注文はプレゼンテーション形式で任意ですが、ワイヤー形式でソートされています
example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2
\# 35 (
00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 01 ; key 1
00 0c ; param length 12
08 ; alpn length 8
66 5c 6f 6f 2c 62 61 72 ; alpn value
02 ; alpn length 2
68 32 ; alpn value
)
\x00\x10 # priority
\x03foo\x07example\x03org\x00 # target
\x00\x01 # key 1
\x00\x0c # param length 12
\x08 # alpn length 8
f\oo,bar # alpn value
\x02 # alpn length 2
h2 # alpn value
Figure 10: An "alpn" Value with an Escaped Comma and an Escaped Backslash in Two Presentation Formats
図10：逃げたコンマと2つのプレゼンテーション形式で逃げたバックスラッシュを備えた「ALPN」値
This subsection contains test vectors that are not compliant with this document. The various reasons for non-compliance are explained with each example.
このサブセクションには、このドキュメントに準拠していないテストベクトルが含まれています。コンプライアンス違反のさまざまな理由が、各例で説明されています。
example.com. SVCB 1 foo.example.com. (
key123=abc key123=def
)
Figure 11: Multiple Instances of the Same SvcParamKey
図11：同じsvcparamkeyの複数のインスタンス
example.com. SVCB 1 foo.example.com. mandatory
example.com. SVCB 1 foo.example.com. alpn
example.com. SVCB 1 foo.example.com. port
example.com. SVCB 1 foo.example.com. ipv4hint
example.com. SVCB 1 foo.example.com. ipv6hint
Figure 12: Missing SvcParamValues That Must Be Non-Empty
図12：空でなければならないsvcparamvaluesの欠落
example.com. SVCB 1 foo.example.com. no-default-alpn=abc
Figure 13: The "no-default-alpn" SvcParamKey Value Must Be Empty
図13：「no-default-alpn」svcparamkey値は空でなければなりません
example.com. SVCB 1 foo.example.com. mandatory=key123
Figure 14: A Mandatory SvcParam Is Missing
図14：必須のsvcparamがありません
example.com. SVCB 1 foo.example.com. mandatory=mandatory
Figure 15: The "mandatory" SvcParamKey Must Not Be Included in the Mandatory List
図15：「必須」SVCParamkeyを必須リストに含めてはなりません
example.com. SVCB 1 foo.example.com. (
mandatory=key123,key123 key123=abc
)
Figure 16: Multiple Instances of the Same SvcParamKey in the Mandatory List
図16：必須リストにある同じsvcparamkeyの複数のインスタンス
Over the years, IETF participants have proposed a wide range of solutions to the "CNAME at the zone apex" challenge, including [HTTP-DNS-RR], [ANAME-DNS-RR], and others. The authors are grateful for their work to elucidate the problem and identify promising strategies to address it, some of which are reflected in this document.
長年にわたり、IETFの参加者は、[http-dns-rr]、[aname-dns-rr]などを含む「ゾーンアペックスのCNAME」チャレンジに対する幅広いソリューションを提案してきました。著者は、問題を解明し、それに対処するための有望な戦略を特定する仕事に感謝しています。そのいくつかはこの文書に反映されています。
Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many others for their feedback and suggestions on this document.
Ian Swett、Ralf Weber、Jon Reed、Martin Thomson、Lucas Pardue、Ilari Liusvaara、Tim Wicinski、Tommy Pauly、Chris Wood、David Benjamin、Mark Andrews、Emily Stark、Eric Orth、Kyle Rose、Craig Taylor、Dan McArdle、ブライアン・ディクソン、ウィレム・トゥーロップ、ピーター・レキス、プニート・スッド、オリビエ・ポイトリー、マッシュー・ムハイメン、トム・カーペイなど、この文書に関するフィードバックと提案について。
Ben Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net
Mike Bishop
Akamai Technologies
Email: mbishop@evequefou.be
Erik Nygren
Akamai Technologies
Email: erik+ietf@nygren.org