[要約] RFC 8145は、DNSセキュリティ拡張（DNSSEC）における信頼アンカーの知識をシグナリングするための仕様です。その目的は、DNSSECの信頼アンカーの情報を効果的に伝達し、セキュリティの向上を図ることです。
Internet Engineering Task Force (IETF) D. Wessels
Request for Comments: 8145 Verisign
Category: Standards Track W. Kumari
ISSN: 2070-1721 Google
P. Hoffman
ICANN
April 2017
Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
DNS Security Extensions（DNSSEC）におけるシグナルトラストアンカーの知識
Abstract
概要
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.
DNS Security Extensions（DNSSEC）は、デジタル署名を使用して、DNSデータの発信元認証と整合性保護を提供するために開発されました。これらのデジタル署名は、トラストアンカーから始まり、DNSの特定のノードに至るまで、トラストのチェーンを構築することで検証できます。このドキュメントでは、リゾルバを検証してサーバーに信号を送る2つの異なる方法を指定し、どのキーが信頼の連鎖で参照されているかを示します。このようなシグナリングからのデータにより、ゾーン管理者はDNSSEC署名ゾーンでのロールオーバーの進行状況を監視できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8145.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8145で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Design Evolution ...........................................4
2. Requirements Terminology ........................................5
3. Terminology .....................................................5
4. Using the edns-key-tag Option ...................................5
4.1. Option Format ..............................................5
4.2. Use by Queriers ............................................6
4.2.1. Stub Resolvers ......................................7
4.2.1.1. Validating Stub Resolvers ..................7
4.2.1.2. Non-validating Stub Resolvers ..............7
4.2.2. Recursive Resolvers .................................7
4.2.2.1. Validating Recursive Resolvers .............7
4.2.2.2. Non-validating Recursive Resolvers .........8
4.3. Use by Responders ..........................................8
5. Using the Key Tag Query .........................................8
5.1. Query Format ...............................................8
5.2. Use by Queriers ............................................9
5.3. Use by Responders ..........................................9
5.3.1. Interaction with Aggressive Negative Caching ........9
6. IANA Considerations ............................................10
7. Security Considerations ........................................10
8. Privacy Considerations .........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Acknowledgments ...................................................13
Authors' Addresses ................................................13
The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [RFC4035] were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. DNSSEC uses Key Tags to efficiently match signatures to the keys from which they are generated. The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY resource record (RR) using a formula not unlike a ones-complement checksum. RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that validates the signature.
DNS Security Extensions（DNSSEC）[RFC4033] [RFC4034] [RFC4035]は、デジタル署名を使用してDNSデータに元の認証と整合性保護を提供するために開発されました。 DNSSECは、キータグを使用して、署名を生成元のキーと効率的に照合します。キータグは、1の補数のチェックサムとは異なり、式を使用してDNSKEYリソースレコード（RR）のRDATA部分から計算された16ビット値です。 RRSIG RRには、署名を検証するDNSKEY RRのキータグと等しい値を持つキータグフィールドが含まれています。
Likewise, Delegation Signer (DS) RRs also contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR to which it refers.
同様に、委任署名者（DS）RRには、参照先のDNSKEY RRのキータグと等しい値を持つキータグフィールドも含まれています。
This document specifies how validating resolvers can tell a server, in a DNS query, which DNSSEC key(s) they would use to validate the server's responses. It describes two independent methods for conveying Key Tag information between clients and servers:
このドキュメントでは、検証リゾルバーがDNSクエリでサーバーにどのようにしてサーバーの応答の検証に使用するDNSSECキーを通知できるかを指定します。クライアントとサーバー間でキータグ情報を伝達するための2つの独立した方法について説明します。
1. placing an EDNS option in the OPT RR [RFC6891] that contains the Key Tags (described in Section 4)
1. キータグを含むOPT RR [RFC6891]にEDNSオプションを配置する（セクション4で説明）
2. periodically sending special "Key Tag queries" to a server authoritative for the zone (described in Section 5)
2. ゾーンに対して権限のあるサーバーに特別な「キータグクエリ」を定期的に送信する（セクション5で説明）
Each of these new signaling mechanisms is OPTIONAL to implement and use. These mechanisms serve to measure the acceptance and use of new DNSSEC trust anchors and key signing keys (KSKs). This signaling data can be used by zone administrators as a gauge to measure the successful deployment of new keys. This is of particular interest for the DNS root zone in the event of key and/or algorithm rollovers that rely on [RFC5011] to automatically update a validating DNS resolver's trust anchor.
これらの新しい信号メカニズムのそれぞれは、実装および使用するオプションです。これらのメカニズムは、新しいDNSSECトラストアンカーとキー署名キー（KSK）の受け入れと使用を測定するのに役立ちます。このシグナリングデータは、ゾーン管理者が新しいキーの展開の成功を測定するためのゲージとして使用できます。これは、検証中のDNSリゾルバーのトラストアンカーを自動的に更新するために[RFC5011]に依存するキーやアルゴリズムのロールオーバーが発生した場合のDNSルートゾーンにとって特に重要です。
This document does not introduce new processes for rolling keys or updating trust anchors. Rather, it specifies a means by which a DNS query can signal the set of keys that a client uses for DNSSEC validation.
このドキュメントでは、キーをローリングしたり、トラストアンカーを更新したりするための新しいプロセスを紹介していません。むしろ、クライアントがDNSSEC検証に使用するキーのセットをDNSクエリが通知できる手段を指定します。
Initially, when the work on this document started, it proposed including Key Tag values in a new EDNS(0) option code. It was modeled after [RFC6975], which provides DNSSEC algorithm signaling.
当初、このドキュメントの作業が始まったとき、新しいEDNS（0）オプションコードにキータグ値を含めることを提案しました。 DNSSECアルゴリズムシグナリングを提供する[RFC6975]をモデルにしています。
The authors received feedback from participants in the DNSOP Working Group that it might be better to convey Key Tags in the QNAME of a separate DNS query, rather than as an EDNS(0) option. Mostly, this is because forwarding (e.g., from stub to recursive to authoritative) could be problematic. Reasons include the following:
著者は、DNSOPワーキンググループの参加者から、EDNS（0）オプションとしてではなく、個別のDNSクエリのQNAMEでキータグを伝達する方がよいというフィードバックを受け取りました。ほとんどの場合、これは転送（スタブから再帰的、信頼できるなど）が問題になる可能性があるためです。理由は次のとおりです。
1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not be forwarded by default, as per [RFC6891].
1. EDNS（0）はホップバイホッププロトコルです。 [RFC6891]のように、不明なオプションコードはデフォルトでは転送されません。
2. Middleboxes might block entire queries containing unknown EDNS(0) option codes.
2. ミドルボックスは、不明なEDNS（0）オプションコードを含むクエリ全体をブロックする場合があります。
3. A recursive resolver might need to remember Key Tag values (i.e., keep state) received from its stub clients and then forward them at a later opportunity.
3. 再帰リゾルバは、スタブクライアントから受信したキータグ値（つまり、状態を保持）を記憶し、後で機会に転送する必要がある場合があります。
One advantage of the EDNS(0) option code is that it is possible to see that a stub client has a different Key Tag list than its forwarder. In the QNAME-based approach, this is not possible because queries originated by a stub and a forwarder are indistinguishable. The authors feel that this advantage is not sufficient to justify the EDNS(0) approach.
EDNS（0）オプションコードの利点の1つは、スタブクライアントにフォワーダーとは異なるキータグリストがあることを確認できることです。 QNAMEベースのアプローチでは、スタブとフォワーダーによって生成されたクエリが区別できないため、これは不可能です。著者は、この利点はEDNS（0）アプローチを正当化するのに十分ではないと感じています。
One downside to the QNAME approach is that it uses a separate query, whereas with EDNS(0) the Key Tag values are "piggybacked" onto an existing DNSKEY query. For this reason, this document recommends only sending QNAME-based Key Tag queries for trust anchors, although EDNS-based Key Tags can be sent with any DNSKEY query.
QNAMEアプローチの欠点の1つは、別のクエリを使用することですが、EDNS（0）では、キータグの値が既存のDNSKEYクエリに「ピギーバック」されます。このため、このドキュメントでは、トラストアンカーのQNAMEベースのキータグクエリのみを送信することを推奨していますが、EDNSベースのキータグは、任意のDNSKEYクエリで送信できます。
Another downside to the QNAME-based approach is that since the trust anchor zone might not contain labels matching the QNAME, these queries could be subject to aggressive negative caching features now in development by the Working Group. This could affect the amount of signaling sent by some clients compared to others.
QNAMEベースのアプローチのもう1つの欠点は、トラストアンカーゾーンにQNAMEと一致するラベルが含まれていない可能性があるため、これらのクエリがワーキンググループによって現在開発中の積極的なネガティブキャッシング機能の対象となる可能性があることです。これは、一部のクライアントが他のクライアントと比較して送信するシグナリングの量に影響を与える可能性があります。
A probably minor downside to the QNAME-based approach is that it cannot be used with extremely long query names if the addition of the prefix would cause the name to be longer than 255 octets.
QNAMEベースのアプローチのおそらくマイナーな欠点は、プレフィックスを追加すると名前が255オクテットより長くなる場合、極端に長いクエリ名では使用できないことです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to which the trust anchor points to be signed. (This paragraph is quoted from Section 2 of [RFC4033].)
トラストアンカー：DNSKEY RRの構成済みDNSKEY RRまたはDS RRハッシュ。検証するセキュリティ対応リゾルバは、この公開鍵またはハッシュを、署名付きDNS応答への認証チェーンを構築するための開始点として使用します。一般に、検証リゾルバは、DNSプロトコルの外部の安全な手段または信頼できる手段を介して、トラストアンカーの初期値を取得する必要があります。トラストアンカーの存在は、リゾルバーがトラストアンカーが指すゾーンが署名されることを期待する必要があることも意味します。 （この段落は、[RFC4033]のセクション2から引用されています。）
Key Tag: A 16-bit integer that identifies and enables efficient selection of DNSSEC public keys. A Key Tag value can be computed over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and DS records can be used to help select the corresponding DNSKEY RR efficiently when more than one candidate DNSKEY RR is available. For most algorithms, the Key Tag is a simple 16-bit modular sum of the DNSKEY RDATA. See [RFC4034], Appendix B.
鍵タグ：DNSSEC公開鍵を効率的に選択して識別できるようにする16ビット整数。キータグの値は、DNSKEY RRのRDATAに対して計算できます。複数の候補DNSKEY RRが利用可能な場合、RRSIGおよびDSレコードのキータグフィールドを使用して、対応するDNSKEY RRを効率的に選択できます。ほとんどのアルゴリズムでは、キータグはDNSKEY RDATAの単純な16ビットモジュールの合計です。 [RFC4034]、付録Bを参照してください。
The edns-key-tag option is encoded as follows:
edns-key-tagオプションは次のようにエンコードされます。
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY-TAG |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
OPTION-CODE: The EDNS0 option code assigned to edns-key-tag (14).
OPTION-CODE：edns-key-tag（14）に割り当てられたEDNS0オプションコード。
OPTION-LENGTH: The value 2 x number of key-tag values present.
OPTION-LENGTH：値2 x存在するキータグ値の数。
KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B).
KEY-TAG：1つ以上の16ビットキータグ値（[RFC4034]、付録B）。
A validating resolver sets the edns-key-tag option in the OPT RR when sending a DNSKEY query. The validating resolver SHOULD also set the DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response.
検証リゾルバは、DNSKEYクエリを送信するときに、OPT RRのedns-key-tagオプションを設定します。検証リゾルバは、DNSSEC OKビット（DOビットとも呼ばれる）[RFC4035]も設定して、応答でDNSSEC RRを受信したいことを示す必要があります（SHOULD）。
A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY queries.
DNSクライアントは、非DNSKEYクエリのedns-key-tagオプションを含めてはなりません（MUST NOT）。
The KEY-TAG value(s) included in the edns-key-tag option represents the Key Tag of the trust anchor or DNSKEY RR that will be used to validate the expected response. When the client sends a DNSKEY query, the edns-key-tag option represents the Key Tag(s) of the KSK(s) of the zone for which the server is authoritative. A validating resolver learns the Key Tag(s) of the KSK(s) from the zone's DS record(s) (found in the parent) or from a trust anchor.
edns-key-tagオプションに含まれるKEY-TAG値は、予期される応答の検証に使用されるトラストアンカーまたはDNSKEY RRのキータグを表します。クライアントがDNSKEYクエリを送信するとき、edns-key-tagオプションは、サーバーが権限を持つゾーンのKSKのキータグを表します。検証リゾルバは、ゾーンのDSレコード（親にあります）またはトラストアンカーからKSKのキータグを学習します。
A DNS client SHOULD include the edns-key-tag option when issuing a DNSKEY query for a zone corresponding to a trust anchor.
DNSクライアントは、トラストアンカーに対応するゾーンのDNSKEYクエリを発行するときに、edns-key-tagオプションを含める必要があります（SHOULD）。
A DNS client MAY include the edns-key-tag option when issuing a DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via DS records). Since some DNSSEC validators implement bottom-up validation, a non-trust anchor Key Tags zone might not be known at the time of the query. Such a validator can include the edns-key-tag option based on previously cached data.
DNSクライアントは、非トラストアンカーゾーン（つまり、DSレコードを介して学習したキータグ）に対してDNSKEYクエリを発行するときに、edns-key-tagオプションを含めることができます（MAY）。一部のDNSSECバリデーターはボトムアップ検証を実装しているため、非トラストアンカーキータグゾーンはクエリの時点では認識されていない可能性があります。このようなバリデーターには、以前にキャッシュされたデータに基づくedns-key-tagオプションを含めることができます。
A DNS client MUST NOT include Key Tag(s) for keys that are not learned via either a trust anchor or DS records.
DNSクライアントは、トラストアンカーまたはDSレコードを介して学習されないキーのキータグを含めてはなりません（MUST NOT）。
Since the edns-key-tag option is only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values.
edns-key-tagオプションはクエリでのみ設定されるため、クライアントが応答でこれらのオプションを確認した場合、アクションを実行する必要はなく、クライアントはオプション値を無視する必要があります。
Typically, stub resolvers rely on an upstream recursive resolver (or cache) to provide a response. Optimal setting of the edns-key-tag option depends on whether the stub resolver elects to perform its own validation.
通常、スタブリゾルバーは、上流の再帰リゾルバー（またはキャッシュ）に依存して応答を提供します。 edns-key-tagオプションの最適な設定は、スタブリゾルバーが独自の検証を実行するかどうかによって異なります。
A validating stub resolver sets the DNSSEC OK bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG RRs) in the response. Such validating resolvers SHOULD include the edns-key-tag option in the OPT RR when sending a DNSKEY query.
検証スタブリゾルバは、DNSSEC OKビット[RFC4035]を設定して、応答で追加のDNSSEC RR（つまり、RRSIG RR）を受信したいことを示します。このような検証リゾルバーは、DNSKEYクエリを送信するときに、OPT RRにedns-key-tagオプションを含める必要があります（SHOULD）。
The edns-key-tag option MUST NOT be included by non-validating stub resolvers.
edns-key-tagオプションは、非検証スタブリゾルバーに含まれてはいけません（MUST NOT）。
A validating recursive resolver is, by definition, configured with at least one trust anchor. Thus, a recursive resolver SHOULD include the edns-key-tag option in its DNSKEY queries as described above.
検証用の再帰リゾルバーは、定義により、少なくとも1つのトラストアンカーで構成されます。したがって、再帰リゾルバは、上記のようにDNSKEYクエリにedns-key-tagオプションを含める必要があります（SHOULD）。
In addition, the clients of a validating recursive resolver might be configured to do their own validation, with their own trust anchor(s). When a validating recursive resolver receives a query that includes the edns-key-tag option with a Key Tag list that differs from its own, it SHOULD forward both the client's Key Tag list and its own list. When doing so, the recursive resolver SHOULD transmit the two Key Tag lists using separate instances of the edns-key-tag option code in the OPT RR. For example, if the recursive resolver's Key Tag list is (19036, 12345) and the stub/client's list is (19036, 34567), the recursive resolver would include the edns-key-tag option twice: once with values (19036, 12345) and once with values (19036, 34567).
さらに、検証する再帰リゾルバのクライアントは、独自のトラストアンカーを使用して独自の検証を行うように構成されている場合があります。検証する再帰リゾルバが、独自のキータグリストと異なるedns-key-tagオプションを含むクエリを受信すると、クライアントのキータグリストと独自のリストの両方を転送する必要があります（SHOULD）。その場合、再帰リゾルバーは、OPT RRのedns-key-tagオプションコードの個別のインスタンスを使用して、2つのキータグリストを送信する必要があります（SHOULD）。たとえば、再帰リゾルバのキータグリストが（19036、12345）で、スタブ/クライアントのリストが（19036、34567）の場合、再帰リゾルバにはedns-key-tagオプションが2回含まれます。1回は値（19036、12345）です。 ）および値（19036、34567）で1回。
A validating recursive resolver MAY combine stub/client Key Tag values from multiple incoming queries into a single outgoing query. It is RECOMMENDED that implementations place reasonable limits on the number of Key Tags to include in the outgoing edns-key-tag option.
検証する再帰リゾルバは、複数の受信クエリからのスタブ/クライアントキータグ値を単一の送信クエリに結合してもよい（MAY）。実装では、発信edns-key-tagオプションに含めるキータグの数に合理的な制限を設けることをお勧めします。
If the client included the DNSSEC OK and Checking Disabled (CD) bits but did not include the edns-key-tag option in the query, the validating recursive resolver MAY include the option with its own Key Tag values in full.
クライアントがDNSSEC OKおよびChecking Disabled（CD）ビットを含んでいたが、クエリにedns-key-tagオプションが含まれていなかった場合、検証する再帰リゾルバーは、独自のキータグ値を持つオプションを完全に含めることができます。
Validating recursive resolvers MUST NOT set the edns-key-tag option in the final response to the stub client.
再帰リゾルバの検証では、スタブクライアントへの最終応答でedns-key-tagオプションを設定してはなりません（MUST NOT）。
Recursive resolvers that do not validate responses SHOULD copy the edns-key-tag option seen in received queries, as they represent the wishes of the validating downstream resolver that issued the original query.
応答を検証しない再帰リゾルバは、元のクエリを発行した検証するダウンストリームリゾルバの希望を表すため、受信したクエリで見られるedns-key-tagオプションをコピーする必要があります。
An authoritative name server receiving queries with the edns-key-tag option MAY log or otherwise collect the Key Tag values to provide information to the zone operator.
edns-key-tagオプションでクエリを受信する信頼できるネームサーバーは、ゾーンオペレーターに情報を提供するためにログを記録するか、キータグ値を収集する場合があります。
A responder MUST NOT include the edns-key-tag option in any DNS response.
レスポンダは、DNS応答にedns-key-tagオプションを含めてはなりません（MUST NOT）。
A Key Tag query consists of a standard DNS query of type NULL and of class IN [RFC1035].
キータグクエリは、タイプがNULLでクラスがINの標準DNSクエリで構成されます[RFC1035]。
The first component of the query name is the string "_ta-" followed by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag values. The zone name corresponding to the trust anchor is appended to this first component.
クエリ名の最初のコンポーネントは、文字列 "_ta-"で、その後に16進数でエンコードされたキータグ値のハイフン区切りの並べ替えられたリストが続きます。トラストアンカーに対応するゾーン名は、この最初のコンポーネントに追加されます。
For example, a validating DNS resolver that has a single root zone trust anchor with Key Tag 17476 (decimal) would originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
たとえば、キータグ17476（10進数）の単一のルートゾーントラストアンカーを持つ検証DNSリゾルバーは、QTYPE = NULL、QCLASS = IN、QNAME = _ta-4444の形式のクエリを発信します。
Hexadecimal values MUST be zero-padded to four hexadecimal digits. For example, if the Key Tag is 999 (decimal), it is represented in hexadecimal as 03e7.
16進値は、4桁の16進数字になるようにゼロを埋め込む必要があります。たとえば、キータグが999（10進数）の場合、03e7のように16進数で表されます。
When representing multiple Key Tag values, they MUST be sorted in order from smallest to largest. For example, a validating DNS resolver that has three trust anchors for the example.com zone with Key Tags 1589, 43547, 31406 (decimal) would originate a query of the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.
複数のキータグ値を表す場合、それらは最小から最大の順にソートする必要があります。たとえば、example.comゾーンに3つのトラストアンカーがあり、キータグが1589、43547、31406（10進数）の検証DNSリゾルバーは、QTYPE = NULL、QCLASS = IN、QNAME = _ta-0635-という形式のクエリを発信します。 7aae-aa1b.example.com。
A validating DNS resolver (stub or recursive) SHOULD originate a Key Tag query whenever it also originates a DNSKEY query for a trust anchor zone. In other words, the need to issue a DNSKEY query is also the trigger to issue a Key Tag query.
検証するDNSリゾルバー（スタブまたは再帰的）は、トラストアンカーゾーンのDNSKEYクエリも発信する場合は常に、キータグクエリを発信する必要があります（SHOULD）。つまり、DNSKEYクエリを発行する必要性は、キータグクエリを発行するトリガーでもあります。
The value(s) included in the Key Tag query represents the Key Tag(s) of the trust anchor that will be used to validate the expected DNSKEY response.
キータグクエリに含まれる値は、予期されるDNSKEY応答の検証に使用されるトラストアンカーのキータグを表します。
A validating DNS resolver SHOULD NOT originate Key Tag queries when also originating DNSKEY queries for non-trust anchor zones.
検証するDNSリゾルバーは、非トラストアンカーゾーンのDNSKEYクエリも生成するときに、キータグクエリを生成するべきではありません（SHOULD NOT）。
A non-validating DNS resolver MUST NOT originate Key Tag queries.
検証されていないDNSリゾルバーは、キータグクエリを生成してはなりません。
DNS resolvers with caches SHOULD cache and reuse the response to a Key Tag query just as it would any other response.
キャッシュ付きのDNSリゾルバーは、他の応答と同じように、キータグクエリへの応答をキャッシュして再利用する必要があります（SHOULD）。
An authoritative name server receiving Key Tag queries MAY log or otherwise collect the Key Tag values to provide information to the zone operator.
キータグクエリを受信する信頼できるネームサーバーは、ゾーンオペレーターに情報を提供するためにキータグ値をログに記録するか収集することができます。
An authoritative name server MUST generate an appropriate response to the Key Tag query. A server does not need to have built-in logic that determines the response to Key Tag queries: the response code is determined by whether the data is in the zone file or covered by wildcards. The zone operator might want to add specific Key Tag records to its zone, perhaps with specific TTLs, to affect the frequency of Key Tag queries from clients.
権威ネームサーバーは、キータグクエリに対して適切な応答を生成する必要があります。サーバーには、キータグクエリへの応答を決定する組み込みロジックは必要ありません。応答コードは、データがゾーンファイルにあるか、ワイルドカードでカバーされているかによって決定されます。ゾーンオペレータは、クライアントからのキータグクエリの頻度に影響を与えるために、特定のTTLを使用して、ゾーンに特定のキータグレコードを追加することができます。
Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also affect the quality of Key Tag signaling. When the response code for a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive negative caching will send fewer Key Tag queries than resolvers that do not implement it.
アグレッシブNSEC / NSEC3ネガティブキャッシング[NSEC-NSEC3-Usage]も、キータグシグナリングの品質に影響を与える可能性があります。キータグクエリの応答コードがNXDOMAINの場合、積極的なネガティブキャッシングを実装するDNSリゾルバーは、それを実装しないリゾルバーよりも少ないキータグクエリを送信します。
For this reason, zone operators might choose to create records corresponding to expected Key Tag queries. During a rollover from Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the following records:
このため、ゾーンオペレーターは、予想されるキータグクエリに対応するレコードを作成することを選択する場合があります。キータグ1111（16進数）からキータグ2222（16進数）へのロールオーバー中に、ゾーンには次のレコードが含まれる可能性があります。
_ta-1111 IN NULL \# 0 _ta-2222 IN NULL \# 0 _ta-1111-2222 IN NULL \# 0
_ta-1111 IN NULL \＃0 _ta-2222 IN NULL \＃0 _ta-1111-2222 IN NULL \＃0
Recall that when multiple Key Tags are present, the originating client MUST sort them from smallest to largest in the query name.
複数のキータグが存在する場合、発信元クライアントはそれらをクエリ名の最小から最大にソートする必要があることを思い出してください。
IANA has assigned an EDNS0 option code for the edns-key-tag option in the "DNS EDNS0 Option Codes (OPT)" registry as follows:
IANAは、「DNS EDNS0オプションコード（OPT）」レジストリのedns-key-tagオプションにEDNS0オプションコードを次のように割り当てました。
+-------+--------------+----------+-----------+
| Value | Name | Status | Reference |
+-------+--------------+----------+-----------+
| 14 | edns-key-tag | Optional | RFC 8145 |
+-------+--------------+----------+-----------+
This document specifies two ways for a client to signal its trust anchor knowledge to a cache or server. The goal of these optional mechanisms is to signal new trust anchor uptake in clients to allow zone administrators to know when it is possible to complete a key rollover in a DNSSEC-signed zone.
このドキュメントでは、クライアントがトラストアンカーの知識をキャッシュまたはサーバーに通知する2つの方法を指定します。これらのオプションのメカニズムの目的は、クライアントでの新しいトラストアンカーの取り込みを通知して、ゾーン管理者がDNSSEC署名ゾーンでキーのロールオーバーを完了できる時期を知ることができるようにすることです。
There is a possibility that an eavesdropper or server could infer the validator in use by a client by the Key Tag list seen. This may allow an attacker to find validators using old, possibly broken, keys. It could also be used to identify the validator or to narrow down the possible validator implementations in use by a client; the validator used by the client could have a known vulnerability that could be exploited by the attacker.
盗聴者またはサーバーが、クライアントが使用しているバリデーターを、表示されたキータグリストから推測できる可能性があります。これにより、攻撃者は古い、壊れている可能性のあるキーを使用してバリデーターを見つけることができます。バリデーターを識別したり、クライアントが使用している可能性のあるバリデーター実装を絞り込むために使用することもできます。クライアントが使用するバリデーターには既知の脆弱性があり、攻撃者に悪用される可能性があります。
Consumers of data collected from the mechanisms described in this document are advised that provided Key Tag values might be "made up" by some DNS clients with malicious, or at least mischievous, intentions. For example, an attacker with sufficient resources might try to generate large numbers of queries including only old Key Tag values, with the intention of delaying the completion of a key rollover.
このドキュメントで説明されているメカニズムから収集されたデータの利用者は、提供されたキータグ値が、悪意のある、または少なくともいたずらな意図を持つ一部のDNSクライアントによって「作成」される可能性があることをお勧めします。たとえば、十分なリソースを持つ攻撃者は、キーのロールオーバーの完了を遅らせる目的で、古いキータグ値のみを含む多数のクエリを生成しようとする可能性があります。
DNSSEC does not require keys in a zone to have unique Key Tags. During a rollover, there is a small possibility that an old key and a new key will have identical Key Tag values. Zone operators relying on the edns-key-tag mechanism SHOULD take care to ensure that new keys have unique Key Tag values.
DNSSECでは、ゾーン内のキーが一意のキータグを持つ必要はありません。ロールオーバー中に、古いキーと新しいキーが同じキータグ値を持つ可能性が少しあります。 edns-key-tagメカニズムに依存するゾーンオペレーターは、新しいキーが一意のキータグ値を持つように注意する必要があります。
This proposal provides additional, optional "signaling" to DNS queries in the form of Key Tag values. While Key Tag values themselves are not considered private information, it may be possible for an eavesdropper to use Key Tag values as a fingerprinting technique to identify particular validating DNS clients. This may be especially true if the validator is configured with trust anchors for zones in addition to the root zone.
この提案は、キータグ値の形式でDNSクエリに追加のオプションの「シグナリング」を提供します。キータグ値自体は個人情報とは見なされませんが、盗聴者が特定の検証DNSクライアントを識別するためのフィンガープリント技術としてキータグ値を使用する可能性があります。これは、バリデーターがルートゾーンに加えてゾーンのトラストアンカーで構成されている場合に特に当てはまる可能性があります。
A validating resolver need not transmit the Key Tags in every applicable query. Due to privacy concerns, such a resolver MAY choose to transmit the Key Tags for a subset of queries (e.g., every 25th time) or by random chance with a certain probability (e.g., 5%).
検証リゾルバは、該当するすべてのクエリでキータグを送信する必要はありません。プライバシーの問題により、このようなリゾルバーは、クエリのサブセット（25回ごとなど）のキータグを送信するか、または特定の確率（5％など）でランダムに偶然に送信することを選択できます（MAY）。
Implementations of this specification MAY be administratively configured to only transmit the Key Tags for certain zones. For example, the software's configuration file may specify a list of zones for which the use of the mechanisms described here is allowed or denied. Since the primary motivation for this specification is to provide operational measurement data for root zone key rollovers, it is RECOMMENDED that implementations at least include the edns-key-tag option for root zone DNSKEY queries.
この仕様の実装は、特定のゾーンのキータグのみを送信するように管理上設定できます。たとえば、ソフトウェアの構成ファイルでは、ここで説明するメカニズムの使用が許可または拒否されるゾーンのリストを指定できます。この仕様の主な動機はルートゾーンキーのロールオーバーの運用測定データを提供することであるため、実装には少なくともルートゾーンDNSKEYクエリのedns-key-tagオプションを含めることをお勧めします。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Securityの紹介と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<http：// www.rfc-editor.org/info/rfc6891>。
[NSEC-NSEC3-Usage] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of DNSSEC-validated Cache", Work in Progress, draft-ietf-dnsop-nsec-aggressiveuse-09, March 2017.
[NSEC-NSEC3-Usage]藤原健一郎、加藤英明、およびW.クマリ、「DNSSEC検証済みキャッシュの積極的な使用」、作業中、draft-ietf-dnsop-nsec-aggressiveuse-09、2017年3月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011] StJohns、M。、「DNSセキュリティ（DNSSEC）トラストアンカーの自動更新」、STD 74、RFC 5011、DOI 10.17487 / RFC5011、2007年9月、<http://www.rfc-editor.org/info/ rfc5011>。
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, <http://www.rfc-editor.org/info/rfc6975>.
[RFC6975] Crocker、S。およびS. Rose、「DNS Security Extensions（DNSSEC）での暗号化アルゴリズムの理解」、RFC 6975、DOI 10.17487 / RFC6975、2013年7月、<http://www.rfc-editor.org/ info / rfc6975>。
Acknowledgments
謝辞
This document was inspired by and borrows heavily from [RFC6975] by Scott Rose and Steve Crocker. The authors would like to thank Mark Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim Wicinski, Suzanne Woolf, and other members of the DNSOP Working Group for their input.
このドキュメントは、Scott RoseとSteve Crockerによって[RFC6975]から着想を得て、大きく借りています。著者は、Mark Andrews、Casey Deccio、Burt Kalisky、Bob Harold、Edward Lewis、Tim Wicinski、Suzanne Woolf、およびDNSOPワーキンググループの他のメンバーの意見に感謝します。
Authors' Addresses
著者のアドレス
Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 United States of America
Duane Wessels Verisign 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Phone: +1 703 948-3200
Email: dwessels@verisign.com
URI: http://verisigninc.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
Paul Hoffman ICANN
ポール・ホフマンICANN
Email: paul.hoffman@icann.org