RFC 9157 - Revised IANA Considerations for DNSSEC (RFC 9157) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9157.html
タイトル : RFC 9157 - DNSSECのIANAの考慮事項（RFC 9157）
翻訳編集 : 自動生成

[要約] RFC 9157はDNSSEC（Domain Name System Security Extensions）に関するIANA（Internet Assigned Numbers Authority）の考慮事項を更新する文書です。この文書の目的は、DNSSECの運用と管理を改善し、セキュリティを強化するためのガイドラインを提供することです。利用場面としては、DNSSECのパラメータやリソースレコードの割り当て、更新プロセスに関わる技術者や管理者が参照します。

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 9157                                         ICANN
Updates: 5155, 6014, 8624                                  November 2021
Category: Standards Track
ISSN: 2070-1721

Revised IANA Considerations for DNSSEC

DNSSECのIANAの考慮事項を改訂しました

Abstract

概要

This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.

このドキュメントは、DNSSECアルゴリズムとIANAレジストリに追加されたリソースレコードを取得するために必要なレビュー要件を変更します。RFC 6014を更新して、委任署名者（DS）レコードのハッシュアルゴリズムと次のセキュアバージョン3（NSEC3）パラメーター（認証された存在の拒否のための）を含めます。また、DNSSECアルゴリズムの要件を備えたRFCS 5155および6014を更新し、RFC 8624を更新して、標準の追跡ではないRFCSに記載されているアルゴリズムに関連する実装推奨事項を明確にします。これらの変更の理論的根拠は、NSEC3で使用されるDSレコードとハッシュアルゴリズムの要件を、他のすべてのDNSSECアルゴリズムの要件に沿って提供することです。

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/rfc9157.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9157で取得できます。

著作権表示

著作権（c）2021 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ライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Update to RFC 6014
   3.  Update to RFC 8624
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. DNSSEC commonly uses another resource record beyond those defined in [RFC4034]: NSEC3 [RFC5155]. DS resource records were originally defined in [RFC3658], and that definition was obsoleted by [RFC4034].

DNSSECは、主に[RFC4033]、[RFC4034]、および[RFC4035]で説明されています。DNSSECは一般に、[RFC4034]：NSEC3 [RFC5155]で定義されているものを超えた別のリソースレコードを使用します。DSリソースレコードはもともと[RFC3658]で定義されており、その定義は[RFC4034]によって廃止されました。

[RFC6014] updates the requirements for how DNSSEC cryptographic algorithm identifiers in the IANA registries are assigned, reducing the requirements from "Standards Action" to "RFC Required". However, the IANA registry requirements for hash algorithms for DS records [RFC3658] and for the hash algorithms used in NSEC3 records [RFC5155] are still "Standards Action". This document updates those IANA registry requirements. (For a reference on how IANA registries can be updated in general, see [RFC8126].)

[RFC6014]は、IANAレジストリのDNSSEC暗号化アルゴリズム識別子が割り当てられ、「標準アクション」から「RFC要求」に要件を削減する方法の要件を更新します。ただし、DSレコード[RFC3658]およびNSEC3レコード[RFC5155]で使用されるハッシュアルゴリズムのハッシュアルゴリズム[RFC3658]のIANAレジストリ要件は、依然として「標準アクション」です。このドキュメントは、これらのIANAレジストリの要件を更新します。（一般的にIANAレジストリを更新する方法についての参照については、[RFC8126]を参照してください。）

1.1. Requirements Language

1.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]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. Update to RFC 6014

2. RFC 6014に更新します

Section 4 updates [RFC6014] to bring the requirements for DS records and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algorithms by allowing any DS hash algorithms, NSEC3 hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully described in an RFC to have identifiers assigned in the IANA registries. This is an addition to the IANA considerations in [RFC6014].

セクション4は[RFC6014]を更新して、DSレコードとNSEC3ハッシュアルゴリズムの要件を、DSSECの暗号化アルゴリズムの残りの部分に沿って、DSハッシュアルゴリズム、NSEC3ハッシュアルゴリズム、NSEC3パラメーター、およびNSEC3フラグを許可することにより、DNSSEC暗号化アルゴリズムの残りに沿ってもたらします。IANAレジストリに識別子が割り当てられているRFC。これは、[RFC6014]のIANAの考慮事項に追加されます。

3. Update to RFC 8624

3. RFC 8624に更新します

This document updates [RFC8624] for all DNSKEY and DS algorithms that are not on the standards track.

このドキュメントは、標準トラックにないすべてのDNSKEYおよびDSアルゴリズムの[RFC8624]を更新します。

The second paragraph of Section 1.2 of [RFC8624] currently says:

[RFC8624]のセクション1.2の2番目の段落は、現在次のように述べています。

This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that they cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in this document MAY be implemented. For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded from a MUST or a RECOMMENDED to a MAY.

このドキュメントは、推奨される義務的なアルゴリズムまたはアルゴリズムに関する推奨事項のみを提供しているため、推奨できないほど弱いです。このドキュメントに記載されていない[dnskey-yiana]および[ds-aiana]レジストリにリストされているアルゴリズムは実装できます。明確化と一貫性のために、このドキュメントのアルゴリズムは、必須または5月に推奨されている場合にのみ格下げされた場合にのみ、5月のように指定されます。

That paragraph is now replaced with the following:

その段落は、以下に置き換えられました。

This document provides recommendations with respect to mandatory-to-implement algorithms, algorithms so weak that they cannot be recommended, and algorithms defined in RFCs that are not on the standards track. Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in this document MAY be implemented. For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded from a MUST or a RECOMMENDED to a MAY.

このドキュメントでは、必須の実装アルゴリズム、推奨されるほど弱いアルゴリズム、および標準トラックにないRFCで定義されているアルゴリズムに関する推奨事項を提供します。このドキュメントに記載されていない[dnskey-yiana]および[ds-aiana]レジストリにリストされているアルゴリズムは実装できます。明確化と一貫性のために、このドキュメントのアルゴリズムは、必須または5月に推奨されている場合にのみ格下げされた場合にのみ、5月のように指定されます。

This update is also reflected in the IANA considerations in Section 4.

この更新は、セクション4のIANAの考慮事項にも反映されています。

4. IANA Considerations

4. IANAの考慮事項

In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" registry, the registration procedure for "DNSSEC NSEC3 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" has been changed from "Standards Action" to "RFC Required", and this document has been added as a reference.

「ドメイン名システムセキュリティ（DNSSEC）NextSecure3（NSEC3）パラメーター「レジストリ」、「DNSSEC NSEC3フラグ」の登録手順、「DNSEC NSEC3ハッシュアルゴリズム」、「DNSSEC NSEC3PARAMフラグ」の「DNSSEC NSEC3PARAMフラグ」「RFCが必要」、このドキュメントは参照として追加されています。

In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry, the registration procedure for "Digest Algorithms" has been changed from "Standards Action" to "RFC Required", and this document has been added as a reference.

「DNSSEC委任署名者（DS）リソースレコード（RR）タイプダイジェストアルゴリズム」レジストリでは、「ダイジェストアルゴリズム」の登録手順は「標準アクション」から「RFC必要」に変更されており、このドキュメントは参照。

5. Security Considerations

5. セキュリティ上の考慮事項

Changing the requirements for adding security algorithms to IANA registries as described in this document will make it easier to add both good and bad algorithms to the registries. It is impossible to weigh the security impact of those two changes.

このドキュメントで説明されているように、IANAレジストリにセキュリティアルゴリズムを追加するための要件を変更すると、良いアルゴリズムと悪いアルゴリズムの両方をレジストリに簡単に追加できます。これら2つの変更のセキュリティへの影響を比較検討することは不可能です。

Administrators of DNSSEC-signed zones and validating resolvers may have been making security decisions based on the contents of the IANA registries. This was a bad idea in the past, and now it is an even worse idea because there will be more algorithms in those registries that may not have gone through IETF review. Security decisions about which algorithms are safe and not safe should be made by reading the security literature, not by looking in IANA registries.

DNSSECに署名したゾーンの管理者とリゾルバーの検証は、IANAレジストリの内容に基づいてセキュリティ決定を行っていた可能性があります。これは過去に悪い考えでしたが、今ではさらに悪いアイデアです。なぜなら、これらのレジストリには、IETFレビューを行っていないかもしれないより多くのアルゴリズムがあるからです。どのアルゴリズムが安全で安全ではないかについてのセキュリティの決定は、IANAレジストリを見るのではなく、セキュリティ文献を読むことによって行う必要があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、DOI 10.17487/RFC4033、2005年3月、<https：//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, <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.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル修正」、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. Blacka、「DNS Security（DNSSEC）は認証された存在拒否」、RFC 5155、DOI 10.17487/RFC5155、2008年3月、<HTTPS：//www.rfc-editor.org/info/rfc5155>。

[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, November 2010, <https://www.rfc-editor.org/info/rfc6014>.

[RFC6014] Hoffman、P。、「DNSSECの暗号化アルゴリズム識別子割り当て」、RFC 6014、DOI 10.17487/RFC6014、2010年11月、<https://www.rfc-editor.org/info/rfc6014>

[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>.

[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, <https://www.rfc-editor.org/info/rfc8624>.

[RFC8624] Wouters、P。and O. Sury、「DNSSECのアルゴリズムの実装要件と使用ガイダンス」、RFC 8624、DOI 10.17487/RFC8624、2019年6月、<https：//www.rfc-editor.org/fo/RFC86244>。

6.2. Informative References

6.2. 参考引用

[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, <https://www.rfc-editor.org/info/rfc3658>.

[RFC3658] Gudmundsson、O。、「Delegation Signer（DS）Resource Record（RR）」、RFC 3658、DOI 10.17487/RFC3658、2003年12月、<https://www.rfc-editor.org/info/rfc3658>

Acknowledgements

謝辞

Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and Benjamin Kaduk contributed to this document.

ドナルド・イーストレイク、マレー・クチェラウィ、ダン・ハーキンス、マーティン・デューク、ベンジャミン・カドゥクがこの文書に貢献しました。

Author's Address

著者の住所

Paul Hoffman ICANN

ポール・ホフマン・イカン

   Email: paul.hoffman@icann.org