[要約] RFC 9077は、DNSセキュリティ拡張（DNSSEC）におけるNSECおよびNSEC3レコードのTTL（Time To Live）値と積極的利用に関する指針を提供します。この文書の目的は、DNS応答のキャッシュ効率を向上させるとともに、不正なDNSデータの拡散を防ぐことにあります。主に、DNSキャッシュポイズニング攻撃やデータの改ざんを防ぐ場面で利用されます。
Internet Engineering Task Force (IETF) P. van Dijk
Request for Comments: 9077 PowerDNS
Updates: 4034, 4035, 5155, 8198 July 2021
Category: Standards Track
ISSN: 2070-1721
NSEC and NSEC3: TTLs and Aggressive Use
NSECとNSEC3：TTLSと攻撃的な使用
Abstract
概要
Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198.
以前の文書で不幸な表現の組み合わせにより、NSECおよびNSEC3レコードの積極的な使用は、拒否の意図された寿命をはるかに超える名前の存在を拒否される可能性があります。この文書は、NSECとNSEC3 TTLの定義を変更してその状況を修正します。この文書はRFCS 4034,4035,5155、および8198を更新します。
Status of This Memo
本文書の位置付け
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/rfc9077.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9077で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions and Definitions
3. NSEC and NSEC3 TTL Changes
3.1. Updates to RFC 4034
3.2. Updates to RFC 4035
3.3. Updates to RFC 5155
3.4. Updates to RFC 8198
4. Zone Operator Considerations
4.1. A Note on Wildcards
5. Security Considerations
6. IANA Considerations
7. Normative References
Acknowledgements
Author's Address
[RFC2308] defines the TTL of the Start of Authority (SOA) record that must be returned in negative answers (NXDOMAIN or NODATA):
[RFC2308]マイナスの回答（NXDOMAINまたはNODATA）で返されなければならない権限の開始（SOA）レコードのTTLを定義します。
| The TTL of this record is set from the minimum of the MINIMUM
| field of the SOA record and the TTL of the SOA itself, and
| indicates how long a resolver may cache the negative answer.
Thus, if the TTL of the SOA in the zone is lower than the SOA MINIMUM value (the last number in the SOA record), the authoritative server sends that lower value as the TTL of the returned SOA record. The resolver always uses the TTL of the returned SOA record when setting the negative TTL in its cache.
したがって、ゾーン内のSOAのTTLがSOAの最小値（SOAレコードの最後の番号）より低い場合、信頼できるサーバーはその下位値を返されたSOAレコードのTTLとして送信します。キャッシュに負のTTLを設定するときは、レゾルバは常に返されたSOAレコードのTTLを使用します。
However, [RFC4034], Section 4 has this unfortunate text:
しかし、[RFC4034]、セクション4にはこの不幸なテキストがあります。
| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL | field. This is in the spirit of negative caching ([RFC2308]).
| ..NSEC RRはSOA最小TTLと同じTTL値を持つ必要があります。分野。これはマイナスキャッシングの精神（[RFC2308]）です。
This text, while referring to [RFC2308], can cause NSEC records to have much higher TTLs than the appropriate negative TTL for a zone. [RFC5155] contains equivalent text.
このテキストは、[RFC2308]を参照しながら、NSECレコードがゾーンの適切なマイナスTTLよりもはるかに高いTTLを持つ可能性があります。[RFC5155]同等のテキストが含まれています。
[RFC8198], Section 5.4 tries to correct this:
[RFC8198]、セクション5.4はこれを修正しようとします。
| Section 5 of [RFC2308] also states that a negative cache entry TTL
| is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
| This can be less than the TTL of an NSEC or NSEC3 record, since
| their TTL is equal to the SOA.MINIMUM field (see [RFC4035],
| Section 2.3 and [RFC5155], Section 3).
|
| A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
| reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM
| field in the authority section of a negative response, if
| SOA.MINIMUM is smaller.
But the NSEC and NSEC3 RRs should, according to [RFC4034] and [RFC5155], already be at the value of the MINIMUM field in the SOA. Thus, the advice from [RFC8198] would not actually change the TTL used for the NSEC and NSEC3 RRs for authoritative servers that follow the RFCs.
しかし、[RFC4034]と[RFC5155]によると、NSECとNSEC3 RRSはすでにSOA内の最小フィールドの値にあります。したがって、[RFC8198]からのアドバイスは、RFCSに続く正式なサーバーのNSECおよびNSEC3 RRSに使用されるTTLを実際には変更されません。
As a theoretical exercise, consider a top-level domain (TLD) named .example with an SOA record like this:
理論的な演習として、次のようなSOAレコードを使用して最上位のドメイン（TLD）を検討してください。
example. 900 IN SOA primary.example. dnsadmin.example. ( 1 1800 900 604800 86400 )
例。SOAプライマリの900。サンプル。dnsadmin.example。（1 1800 900 604800 86400）
The SOA record has a 900-second TTL and an 86400-second MINIMUM TTL. Negative responses from this zone have a 900-second TTL, but the NSEC or NSEC3 records in those negative responses have an 86400-second TTL. If a resolver were to use those NSEC or NSEC3 records aggressively, they would be considered valid for a day instead of the intended 15 minutes.
SOAレコードには900秒のTTLと86400秒の最小TTLがあります。このゾーンからの負の応答は900秒のTTLを持っていますが、これらの負の応答のNSECまたはNSEC3レコードには86400秒のTTLがあります。リゾルバがそれらのNSECまたはNSEC3レコードを積極的に使用することになった場合は、目的の15分の代わりに1日有効と見なされます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC4034], [RFC4035], and [RFC5155] use the SHOULD requirement level, but they were written prior to the publication of [RFC8198] when [RFC4035] still said:
[RFC4034]、[RFC4035]、[RFC5155]は必要な要件レベルを使用しますが、[RFC4035]がまだ言ったときの[RFC8198]の出版の前に書かれていました。
| However, it seems prudent for resolvers to avoid blocking new | authoritative data or synthesizing new data on their own.
| ..ただし、ブロックを阻止しないように、リゾルバが慎重に見えます。権限のあるデータまたは自分で新しいデータを合成する。
[RFC8198] updated that text to contain:
[RFC8198]を含めるテキストを更新しました。
| ...DNSSEC-enabled validating resolvers SHOULD use wildcards and
| NSEC/NSEC3 resource records to generate positive and negative
| responses until the effective TTLs or signatures for those records
| expire.
This means that the correctness of NSEC and NSEC3 records and their TTLs has become much more important. Because of that, the updates in this document upgrade the requirement level to MUST.
つまり、NSECとNSEC3レコードとそのTTLの正確さがはるかに重要になっています。そのため、このドキュメントの更新プログラムは必要に応じて必要な要件レベルをアップグレードします。
[RFC4034] says:
[RFC4034]言う：
| The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL | field. This is in the spirit of negative caching ([RFC2308]).
| ..NSEC RRはSOA最小TTLと同じTTL値を持つ必要があります。分野。これはマイナスキャッシングの精神（[RFC2308]）です。
This is updated to say:
これは言うように更新されます。
| The TTL of the NSEC RR that is returned MUST be the lesser of the
| MINIMUM field of the SOA record and the TTL of the SOA itself.
| This matches the definition of the TTL for negative responses in
| [RFC2308]. Because some signers incrementally update the NSEC
| chain, a transient inconsistency between the observed and expected
| TTL MAY exist.
[RFC4035] says:
[RFC4035]言う：
| The TTL value for any NSEC RR SHOULD be the same as the minimum | TTL value field in the zone SOA RR.
| ..NSEC RRのTTL値は、最小と同じである必要があります。ゾーンSOA RRのTTL値フィールド。
This is updated to say:
これは言うように更新されます。
| The TTL of the NSEC RR that is returned MUST be the lesser of the
| MINIMUM field of the SOA record and the TTL of the SOA itself.
| This matches the definition of the TTL for negative responses in
| [RFC2308]. Because some signers incrementally update the NSEC
| chain, a transient inconsistency between the observed and expected
| TTL MAY exist.
[RFC5155] says:
[RFC5155]言う：
| The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL | field. This is in the spirit of negative caching [RFC2308].
| ..NSEC3 RRはSOAの最小TTLと同じTTL値を持つ必要があります。分野。これはネガティブキャッシングの精神です[RFC2308]。
This is updated to say:
これは言うように更新されます。
| The TTL of the NSEC3 RR that is returned MUST be the lesser of the
| MINIMUM field of the SOA record and the TTL of the SOA itself.
| This matches the definition of the TTL for negative responses in
| [RFC2308]. Because some signers incrementally update the NSEC3
| chain, a transient inconsistency between the observed and expected
| TTL MAY exist.
Where [RFC5155] says:
[RFC5155]は次のとおりです。
| * The TTL value for any NSEC3 RR SHOULD be the same as the | minimum TTL value field in the zone SOA RR.
| ..* NSEC3 RRのTTL値は|と同じにする必要があります。ゾーンSOA RRの最小TTL値フィールド。
This is updated to say:
これは言うように更新されます。
| * The TTL value for each NSEC3 RR MUST be the lesser of the
| MINIMUM field of the zone SOA RR and the TTL of the zone SOA RR
| itself. Because some signers incrementally update the NSEC3
| chain, a transient inconsistency between the observed and
| expected TTL MAY exist.
[RFC8198], Section 5.4 ("Consideration on TTL") is completely replaced by the following text:
[RFC8198]、セクション5.4（「TTLの考察」は次のテキストに完全に置き換えられます。
| The TTL value of negative information is especially important,
| because newly added domain names cannot be used while the negative
| information is effective.
|
| Section 5 of [RFC2308] suggests a maximum default negative cache
| TTL value of 3 hours (10800). It is RECOMMENDED that validating
| resolvers limit the maximum effective TTL value of negative
| responses (NSEC/NSEC3 RRs) to this same value.
|
| A resolver that supports aggressive use of NSEC and NSEC3 MAY
| limit the TTL of NSEC and NSEC3 records to the lesser of the
| SOA.MINIMUM field and the TTL of the SOA in a response, if
| present. It MAY also use a previously cached SOA for a zone to
| find these values.
(The third paragraph of the original is removed, and the fourth paragraph is updated to allow resolvers to also take the lesser of the SOA TTL and SOA MINIMUM.)
（オリジナルの3番目の段落が削除され、4番目の段落は更新され、リゾルバがSOA TTLとSOAの最小値のより少ないものを取ります。）
If signers and DNS servers for a zone cannot immediately be updated to conform to this document, zone operators are encouraged to consider setting their SOA record TTL and the SOA MINIMUM field to the same value. That way, the TTL used for aggressive NSEC and NSEC3 use matches the SOA TTL for negative responses.
ゾーンの署名者とDNSサーバーがすぐにこの文書に準拠して更新できない場合、ゾーン演算子は、SOAレコードTTLとSOAの最小フィールドを同じ値に設定することを検討することをお勧めします。そのように、攻撃的なNSECおよびNSEC3の使用に使用されるTTLは、負の応答のためにSOA TTLと一致します。
Note that some signers might use the SOA TTL or MINIMUM as a default for other values, such as the TTL for DNSKEY records. Operators should consult documentation before changing values.
いくつかの署名者は、DNSKeyレコードのTTLなど、他の値のデフォルトとしてSOA TTLまたは最小値を使用することがあります。値を変更する前に、オペレータはマニュアルを参照する必要があります。
Validating resolvers consider an expanded wildcard valid for the wildcard's TTL, capped by the TTLs of the NSEC or NSEC3 proof that shows that the wildcard expansion is legal. Thus, changing the TTL of NSEC or NSEC3 records (explicitly, or by implementation of this document implicitly) might affect (shorten) the lifetime of wildcards.
リゾルバを検証するWildCardのTTLに有効な拡張されたワイルドカードは、ワイルドカードの展開が合法的であることを示すNSECまたはNSEC3の証明にキャップされています。したがって、NSECまたはNSEC3レコードのTTL（明示的またはこの文書の実装によって暗黙のうちに）を変更すると、ワイルドカードの存続期間が影響（短く）影響があります。
An attacker can delay future records from appearing in a cache by seeding the cache with queries that cause NSEC or NSEC3 responses to be cached for aggressive use purposes. This document reduces the impact of that attack in cases where the NSEC or NSEC3 TTL is higher than the zone operator intended.
攻撃者は、NSECまたはNSEC3の応答を積極的に使用するためにキャッシュされるクエリでキャッシュをシードすることによって、キャッシュ内に将来のレコードを遅らせることができます。この文書は、NSECまたはNSEC3 TTLが意図されたゾーンオペレータよりも高い場合にその攻撃の影響を軽減します。
IANA has added a reference to this document in the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry for the NSEC and NSEC3 types.
IANAは、NSECおよびNSEC3タイプの「ドメインネームシステム（DNS）パラメータ」レジストリの「リソースレコード（RR）型」サブリュイストリートでこの文書への参照を追加しました。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.
[RFC2308] Andrews、M.、「DNSクエリのマイナスキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<https：//www.rfc-editor.org/info/rfc2308>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R.、およびD. Blocka、 "DNSセキュリティ（DNSSEC）ハッシュ化認証済み存在拒否"、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https：//www.rfc-editor.org/info/rfc5155>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8198]藤原、K。、加藤、A。、およびW.Kumari、「DNSSEC検証キャッシュの積極的な使用」、RFC 8198、DOI 10.17487 / RFC8198、2017年7月、<https：//www.rfc-編集者。ORG / INFO / RFC8198>。
Acknowledgements
謝辞
This document was made possible with the help of the following people:
この文書は以下の人の助けを借りて可能になりました。
* Ralph Dolmans
* ラルフドルマン
* Warren Kumari
* ウォーレンクマリ
* Matthijs Mekking
* Matthijs Mekking
* Vladimir Cunat
* Vladimir Cunat.
* Matt Nordhoff
* マットノルドホフ
* Josh Soref
* ジョシュソーレ
* Tim Wicinski
* Tim Wicinski
The author would like to explicitly thank Paul Hoffman for the extensive reviews, text contributions, and help in navigating WG comments.
作者は、Paul Hoffmanに豊富なレビュー、テキストの貢献、およびWGコメントをナビゲートするのに役立ちます。
Author's Address
著者の住所
Peter van Dijk PowerDNS Den Haag Netherlands
Peter Van Dijk Powerdns Den Haagオランダ
Email: peter.van.dijk@powerdns.com