Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 9532 Apple, Inc.
Category: Standards Track January 2024
ISSN: 2070-1721
This document defines the next-hop-aliases HTTP Proxy-Status Parameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop.
このドキュメントでは、Next-Hop-Aliase HTTP Proxy-Statusパラメーターを定義します。このパラメーターには、次のホップへの接続を確立するために、DNS解像度中に受け取った仲介者が受け取ったエイリアスと標準名のリストが搭載されています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9532.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9532で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Requirements
2. next-hop-aliases Parameter
2.1. Encoding Special Characters
3. Implementation Considerations
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Author's Address
The Proxy-Status HTTP response field [PROXY-STATUS] allows intermediaries to convey information about how they handled the request in HTTP responses sent to clients. It defines a set of parameters that provide information, such as the name of the next hop.
プロキシステータスHTTP応答フィールド[Proxy-Status]により、仲介者はクライアントに送信されたHTTP応答のリクエストをどのように処理したかについての情報を伝えることができます。次のホップの名前など、情報を提供するパラメーターのセットを定義します。
[PROXY-STATUS] defines a next-hop parameter, which can contain a hostname, IP address, or alias of the next hop. This parameter can contain only one such item, so it cannot be used to communicate a chain of aliases encountered during DNS resolution when connecting to the next hop.
[Proxy-Status]次のホップのホスト名、IPアドレス、またはエイリアスを含めることができるNext-Hopパラメーターを定義します。このパラメーターにはそのようなアイテムが1つしか含まれていないため、次のホップに接続するときにDNS解像度中に遭遇するエイリアスのチェーンを通信するために使用することはできません。
Knowing the full chain of names that were used during DNS resolution via CNAME records [DNS] is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method [HTTP] or UDP proxying [CONNECT-UDP]. CNAME records can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS names to influence behavior like cookie usage policies [COOKIES] or the blocking of malicious hosts.
CNAMEレコード[DNS]を介してDNS解像度中に使用された名前の完全なチェーンを知ることは、クライアントが接続メソッド[HTTP]またはUDPプロキシを使用して特定のターゲットホスト名に接続することを要求しているフォワードプロキシのクライアントに特に役立ちます。[connect-udp]。CNAMEレコードは、より無害なホスト名の背後で追跡または悪意のあるアクティビティを実行する「クローク」ホストに使用でき、WebブラウザなどのクライアントはDNS名のチェーンを使用して、Cookie使用ポリシー[Cookie]や悪意のあるホストのブロッキングなどの動作に影響を与えます。
This document allows clients to receive the CNAME chain of DNS names for the next hop by including the list of names in a new next-hop-aliases Proxy-Status parameter.
このドキュメントにより、クライアントは、新しいNext-Hop-Aliase Proxy-Statusパラメーターに名前のリストを含めることにより、次のホップのDNS名のCNAMEチェーンを受信できます。
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 value of the next-hop-aliases parameter is a String [STRUCTURED-FIELDS] that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records [DNS] during the course of resolving the next hop's hostname using DNS and MAY include the original requested hostname itself. The names ought to appear in the order in which they were received in DNS, for the sake of consistency. If there are multiple CNAME records in the chain, the first name in the next-hop-aliases list would be the value in the CNAME record for the original hostname, and the final name in the next-hop-aliases list would be the name that ultimately resolved to one or more addresses.
Next-Hop-Aliaseパラメーターの値は、コンマ分離リストに1つ以上のDNS名を含む文字列[構造化場]です。リストの項目には、DNSを使用してNext Hopのホスト名を解決する過程で、CNAMEレコード[DNS]で受信されたすべてのエイリアス名とCanonical名が含まれており、元の要求されたホスト名自体が含まれる場合があります。名前は、一貫性のために、DNSで受信された順序で表示されるべきです。チェーンに複数のcnameレコードがある場合、次のホップアリアゼリストの最初の名前は元のホスト名のcnameレコードの値であり、次のホップアリアスリストの最終名は名前ですそれは最終的に1つ以上のアドレスに解決されました。
The list of DNS names in next-hop-aliases parameter uses a comma (",") as a separator between names. Note that if a comma is included in a name itself, the comma must be encoded as described in Section 2.1.
Next-Hop-AliaseパラメーターのDNS名のリストは、名前の間のセパレーターとしてコンマ（ "、"）を使用します。コンマが名前自体に含まれている場合、セクション2.1で説明されているようにコンマをエンコードする必要があることに注意してください。
For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":
たとえば、次のホップ「host.example.com」のDNS解像度を実行するときに次のレコードを受信するプロキシ「proxy.example.net」を考えてみましょう。
host.example.com. CNAME tracker.example.com.
tracker.example.com. CNAME service1.example.com.
service1.example.com. AAAA 2001:db8::1
The proxy could include the following proxy status in its response:
プロキシには、次のプロキシステータスをその応答に含めることができます。
Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="tracker.example.com,service1.example.com"
This indicates that "proxy.example.net", which used the IP address "2001:db8::1" as the next hop for this request, encountered the names "tracker.example.com" and "service1.example.com" in the DNS resolution chain. Note that while this example includes both the next-hop and next-hop-aliases parameters, next-hop-aliases can be included without including next-hop.
これは、この要求の次のホップとしてIPアドレス「Proxy.example.net」2001：db8 :: 1 "を使用した「proxy.example.net」が、「tracker.example.com」および「service1.example.com」という名前に遭遇したことを示しています。DNS解像度チェーンで。この例には、Next-HopとNext-Hop-Aliaseの両方のパラメーターが含まれていますが、Next-Hop-Aliaseを含めることなく含めることができることに注意してください。
The proxy can also include the name of the next hop as the first item in the list. This is particularly useful for reverse proxies when clients would not otherwise know the name of the next hop, and the next-hop header is used to convey an IP address.
プロキシには、リストの最初の項目として次のホップの名前を含めることもできます。これは、クライアントが次のホップの名前を知らない場合、次のホップヘッダーを使用してIPアドレスを伝えるために使用される場合に特に役立ちます。
For example, consider a proxy "reverseproxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com":
たとえば、次のホップ「host.example.com」のDNS解像度を実行するときに次のレコードを受信するプロキシ「ruversproxy.example.net」を考えてみましょう。
host2.example.com. CNAME service2.example.com.
service2.example.com. AAAA 2001:db8::2
The proxy could include the following proxy status in its response:
プロキシには、次のプロキシステータスをその応答に含めることができます。
Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2";
next-hop-aliases="host2.example.com,service2.example.com"
The next-hop-aliases parameter only applies when DNS was used to resolve the next hop's name, and it does not apply in all situations. Clients can use the information in this parameter to determine how to use the connection established through the proxy, but they need to gracefully handle situations in which this parameter is not present.
Next-Hop-Aliaseパラメーターは、DNSが次のホップの名前を解決するために使用された場合にのみ適用され、すべての状況では適用されません。クライアントはこのパラメーターの情報を使用して、プロキシを介して確立された接続を使用する方法を決定できますが、このパラメーターが存在しない状況を優雅に処理する必要があります。
The proxy MAY send the empty string ("") as the value of next-hop-aliases parameter to indicate that no CNAME records were encountered when resolving the next hop's name.
プロキシは、空の文字列（ ""）をNext-Hop-Aliaseパラメーターの値として送信して、次のホップの名前を解決するときにCNAMEレコードが発生しなかったことを示します。
DNS names commonly contain just alphanumeric characters and hyphens ("-"), although they are allowed to contain any character ([RFC1035], Section 3.1), including a comma. To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI unreserved characters ([RFC3986], Section 2.3) MUST be percent-encoded as defined in [RFC3986], Section 2.1.
DNS名は一般に英数字とハイフン（ " - "）のみを含んでいますが、コンマを含むキャラクター（[RFC1035]、セクション3.1）を含むことは許可されています。誤った解析につながる名前のコンマやその他の特殊文字を防ぐために、このリストの名前に表示されないキャラクターは、URIの予約されていない文字（[RFC3986]、セクション2.3）に属さないキャラクターは、[RFC3986]、セクション2.1。
For example, consider the DNS name "comma,name.example.com". This name would be encoded within a next-hop-aliases parameter as follows:
たとえば、DNS名「Comma、name.example.com」を考慮してください。この名前は、次のように次のように次のように次のようにエンコードされます。
Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="comma%2Cname.example.com,service1.example.com"
It is also possible for a DNS name to include a period character (".") within a label instead of as a label separator. In this case, the period character MUST first be escaped as "\.". Since the "\" character itself will be percent-encoded, the name "dot\.label.example.com" would be encoded within a next-hop-aliases parameter as follows:
また、DNS名がラベルセパレーターとしてではなく、ラベル内にピリオド文字（ "）を含めることもできます。この場合、ピリオド文字は最初に「\」として逃げる必要があります。「\」文字自体はパーセントエンコードされるため、「dot \ .label.example.com」という名前は、次のように次のように次のように次のようにエンコードされます。
Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="dot%5C.label.example.com,service1.example.com"
Upon parsing this name, "dot%5C.label" MUST be treated as a single label.
この名前を解析すると、「dot％5c.label」は単一のラベルとして扱わなければなりません。
Similarly, the "\" character in a label MUST be escaped as "\\" and then percent-encoded. Other uses of "\" MUST NOT appear in the label after percent-decoding. For example, if there is a DNS name "backslash\name.example.com", it would first be escaped as "backslash\\name.example.com" and then percent-encoded as follows:
同様に、ラベル内の「\」文字は「\\」として逃げ、その後エンコードされている必要があります。「\」のその他の用途は、パーセント廃止後にラベルに表示されてはなりません。たとえば、DNS名「backslash \ name.example.com」がある場合、最初に「backslash \\ name.example.com」として脱出され、次にエンコードされます。
Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="backslash%5C%5Cname.example.com,s1.example.com"
In order to include the next-hop-aliases parameter, a proxy needs to have access to the chain of alias names and canonical names received in CNAME records.
Next-Hop-Aliaseパラメーターを含めるには、プロキシは、CNAMEレコードで受け取ったエイリアス名のチェーンと標準名にアクセスできる必要があります。
Implementations ought to note that the full chain of names might not be available in common DNS resolution APIs, such as getaddrinfo [POSIX]. getaddrinfo does have an option for AI_CANONNAME ([RFC3493], Section 6.1), but this will only return the last name in the chain (the canonical name), not the alias names.
実装は、getaddrinfo [posix]など、一般的なDNS解像度APIで名前の完全なチェーンが利用できない可能性があることに注意する必要があります。getaddrinfoには、ai_canonname（[rfc3493]、セクション6.1）のオプションがありますが、これはエイリアス名ではなく、チェーン（標準名）の姓のみを返します。
An implementation MAY include incomplete information in the next-hop-aliases parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use getaddrinfo as described above.
実装には、Next-Hop-Aliaseパラメーターに不完全な情報が含まれて、上記のようにgetaddrinfoのみを使用できる場合に標準名のみを含めるなど、完全なチェーンを含めることができない場合に対応する場合があります。
The next-hop-aliases parameter does not include any DNSSEC information or imply that DNSSEC was used. The information included in the parameter can only be trusted to be valid insofar as the client trusts the proxy to provide accurate information. This information is intended to be used as a hint and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy.
Next-Hop-Aliaseパラメーターには、DNSSEC情報が含まれていないか、DNSSECが使用されたことを暗示していません。パラメーターに含まれる情報は、クライアントが正確な情報を提供するためにプロキシを信頼する限り、有効であると信頼することができます。この情報は、ヒントとして使用することを目的としており、プロキシを介してアクセスされるリソースのIDについてセキュリティ決定を行うために使用すべきではありません。
Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts. However, the CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking. In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name resolution and proxies performing DNS name resolution on behalf of a client. A malicious proxy could also choose to not report these CNAME chains in order to hide the cloaking. In general, clients can trust information included (or not included) in the next-hop-aliases parameter to the degree that the proxy and any resolvers used by the proxy are trusted.
CNAMEチェーンの検査を使用して、トラッカーまたは悪意のあるホストのクローキングを検出できます。ただし、CNAMEレコードは、この形式のクローキングを隠そうとしている再帰的または権威あるリゾルバーによって省略できます。特に、再帰的または権威あるリゾルバーは、クライアントに代わってDNS名の解像度とDNS名解像度を実行するDNS名解像度とプロキシを直接実行する両方のクライアントについて、これらのレコードを省略できます。悪意のあるプロキシは、クローキングを隠すためにこれらのCNAMEチェーンを報告しないことも選択できます。一般に、クライアントは、プロキシとプロキシで使用されるリゾルバーが信頼されている程度まで、次のホップアリアスパラメーターに含まれる（または含まれていない）情報を信頼できます。
This document registers the next-hop-aliases parameter in the "HTTP Proxy-Status Parameters" registry <https://www.iana.org/assignments/ http-proxy-status> as shown in Table 1.
このドキュメントは、表1に示すように、「http proxy-statusパラメーター」レジストリ<https://www.iana.org/assignments/ http-proxy-status>の「http proxy-status parameters」レジストリのネクストホップアリアゼパラメーターを登録します。
+==================+=================================+===========+
| Name | Description | Reference |
+==================+=================================+===========+
| next-hop-aliases | A string containing one or more | RFC 9532 |
| | DNS aliases or canonical names | |
| | used to establish a proxied | |
| | connection to the next hop. | |
+------------------+---------------------------------+-----------+
Table 1: HTTP Proxy-Status Parameters Registry
表1：HTTP Proxy-Statusパラメーターレジストリ
[CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[DNS] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[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>.
[PROXY-STATUS]
Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
June 2022, <https://www.rfc-editor.org/info/rfc9209>.
[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>.
[RFC3986] 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>.
[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>.
[STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[POSIX] IEEE, "IEEE Standard for Information Technology--Portable
Operating System Interface (POSIX(TM)) Base
Specifications, Issue 7", IEEE Std 1003.1-2017,
DOI 10.1109/IEEESTD.2018.8277153, January 2018,
<https://ieeexplore.ieee.org/document/8277153>.
[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>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.
Tommy Pauly
Apple, Inc.
Email: tpauly@apple.com