[要約] RFC 3008は、DNSSEC署名権限の要件と手順を定義する。目的は、DNSセキュリティを向上させ、信頼性のあるドメイン名システムの運用を確保すること。
Network Working Group B. Wellington
Request for Comments: 3008 Nominum
Updates: 2535 November 2000
Category: Standards Track
Domain Name System Security (DNSSEC) Signing Authority
ドメイン名システムセキュリティ（DNSSEC）署名機関
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records.
このドキュメントは、ドメイン名システムセキュリティ（DNSSEC）署名機関の改訂モデルを提案しています。改訂されたモデルは、以前のドキュメントを明確にし、安全な解像度プロセスを簡素化するための追加の制限を追加するように設計されています。具体的には、これはキーの許可に影響し、レコードのセットに署名します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
1 - Introduction
1-はじめに
This document defines additional restrictions on DNSSEC signatures (SIG) records relating to their authority to sign associated data. The intent is to establish a standard policy followed by a secure resolver; this policy can be augmented by local rules. This builds upon [RFC2535], updating section 2.3.6 of that document.
このドキュメントでは、関連データに署名する権限に関連するDNSSEC署名（SIG）レコードに関する追加の制限を定義しています。意図は、標準ポリシーを確立し、その後に安全なリゾルバーが続くことです。このポリシーは、ローカルルールによって強化される可能性があります。これは[RFC2535]に基づいており、そのドキュメントのセクション2.3.6を更新します。
The most significant change is that in a secure zone, zone data is required to be signed by the zone key.
最も重要な変更は、安全なゾーンでは、ゾーンキーによってゾーンデータに署名する必要があることです。
Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security extensions [RFC2535] is assumed.
DNSシステム[RFC1034、RFC1035]およびDNSセキュリティ拡張[RFC2535]に精通していることが想定されています。
2 - The SIG Record
2-SIGレコード
A SIG record is normally associated with an RRset, and "covers" (that is, demonstrates the authenticity and integrity of) the RRset. This is referred to as a "data SIG". Note that there can be multiple SIG records covering an RRset, and the same validation process should be repeated for each of them. Some data SIGs are considered "material", that is, relevant to a DNSSEC capable resolver, and some are "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC validation. Immaterial SIGs may have application defined roles. SIG records may exist which are not bound to any RRset; these are also considered immaterial. The validation process determines which SIGs are material; once a SIG is shown to be immaterial, no other validation is necessary.
SIGレコードは通常、RRSetに関連付けられており、RRSetの「カバー」（つまり、信頼性と完全性を示します）。これは「データSIG」と呼ばれます。RRSetをカバーする複数のSIGレコードがある可能性があり、それらのそれぞれについて同じ検証プロセスを繰り返す必要があることに注意してください。一部のデータSIGは「材料」と見なされます。つまり、DNSSEC対応リゾルバーに関連するものであり、一部のデータはDNSSEC検証には関係がないため、「重要ではない」または「DNSSEC外」です。非物質的なSIGには、アプリケーションが定義された役割がある場合があります。rrsetにバインドされていないSIGレコードが存在する場合があります。これらも重要ではないと見なされます。検証プロセスは、どのSIGが材料であるかを決定します。SIGが重要でないことが示されたら、他の検証は必要ありません。
SIGs may also be used for transaction security. In this case, a SIG record with a type covered field of 0 is attached to a message, and is used to protect message integrity. This is referred to as a SIG(0) [RFC2535, RFC2931].
SIGは、トランザクションセキュリティにも使用できます。この場合、0のタイプカバーフィールドを持つSIGレコードがメッセージに添付され、メッセージの整合性を保護するために使用されます。これは、SIG（0）[RFC2535、RFC2931]と呼ばれます。
The following sections define requirements for all of the fields of a SIG record. These requirements MUST be met in order for a DNSSEC capable resolver to process this signature. If any of these requirements are not met, the SIG cannot be further processed. Additionally, once a KEY has been identified as having generated this SIG, there are requirements that it MUST meet.
次のセクションでは、SIGレコードのすべてのフィールドの要件を定義します。これらの要件は、この署名を処理するためにDNSSEC対応のリゾルバーがあるために満たす必要があります。これらの要件のいずれかが満たされていない場合、SIGをさらに処理することはできません。さらに、キーがこのSIGを生成したと特定されると、満たす必要がある要件があります。
For a data SIG, the type covered MUST be the same as the type of data in the associated RRset. For a SIG(0), the type covered MUST be 0.
データSIGの場合、カバーされているタイプは、関連するRRSetのデータのタイプと同じでなければなりません。sig（0）の場合、カバーされた型は0でなければなりません。
The algorithm specified in a SIG MUST be recognized by the client, and it MUST be an algorithm that has a defined SIG rdata format.
SIGで指定されたアルゴリズムは、クライアントによって認識される必要があり、定義されたSIG RDATA形式を持つアルゴリズムでなければなりません。
The labels count MUST be less than or equal to the number of labels in the SIG owner name, as specified in [RFC2535, section 4.1.3].
ラベルカウントは、[RFC2535、セクション4.1.3]で指定されているように、SIG所有者名のラベルの数以下でなければなりません。
The original TTL MUST be greater than or equal to the TTL of the SIG record itself, since the TTL cannot be increased by intermediate servers. This field can be ignored for SIG(0) records.
TTLは中間サーバーでは増加できないため、元のTTLはSIGレコード自体のTTL以上である必要があります。このフィールドは、SIG（0）レコードでは無視できます。
The current time at the time of validation MUST lie within the validity period bounded by the inception and expiration times.
検証時の現在の時刻は、開始と有効期限に囲まれた有効期間内にある必要があります。
There are no restrictions on the Key Tag field, although it is possible that future algorithms will impose constraints.
将来のアルゴリズムが制約を課す可能性はありますが、キータグフィールドに制限はありません。
The signer's name field of a data SIG MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. The only exception that the signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed. This document defines a standard policy for DNSSEC validation; local policy may override the standard policy.
データSIGの署名者の名前フィールドには、データと署名が属するゾーンの名前を含める必要があります。SIGが材料と見なされる場合、署名者の名前、キータグ、およびアルゴリズムの組み合わせは、ゾーンキーを識別する必要があります。キーセットがセルフ署名されていない限り、ゾーンアペックスのSIGキーの署名者の名前がSIGキーにあるという唯一の例外は、親ゾーンの名前を含める必要があります。このドキュメントは、DNSSEC検証の標準ポリシーを定義しています。ローカルポリシーは、標準ポリシーをオーバーライドする場合があります。
There are no restrictions on the signer field of a SIG(0) record. The combination of signer's name, key tag, and algorithm MUST identify a key if this SIG(0) is to be processed.
SIG（0）レコードの署名者フィールドに制限はありません。署名者の名前、キータグ、およびアルゴリズムの組み合わせは、このSIG（0）を処理する場合、キーを識別する必要があります。
There are no restrictions on the signature field. The signature will be verified at some point, but does not need to be examined prior to verification unless a future algorithm imposes constraints.
署名フィールドに制限はありません。署名はある時点で検証されますが、将来のアルゴリズムが制約を課さない限り、検証の前に検査する必要はありません。
3 - The Signing KEY Record
3-署名キーレコード
Once a signature has been examined and its fields validated (but before the signature has been verified), the resolver attempts to locate a KEY that matches the signer name, key tag, and algorithm fields in the SIG. If one is not found, the SIG cannot be verified and is considered immaterial. If KEYs are found, several fields of the KEY record MUST have specific values if the SIG is to be considered material and authorized. If there are multiple KEYs, the following checks are performed on all of them, as there is no way to determine which one generated the signature until the verification is performed.
署名が検査され、そのフィールドが検証されたら（ただし署名が検証される前に）、ResolverはSIGの署名者名、キータグ、およびアルゴリズムフィールドに一致するキーを見つけようとします。見つからない場合、SIGは検証できず、重要ではありません。キーが見つかった場合、SIGを材料と見なし、許可される場合、キーレコードのいくつかのフィールドに特定の値が必要です。複数のキーがある場合、検証が実行されるまで署名を生成したものを決定する方法がないため、すべてのキーに次のチェックが実行されます。
The signing KEY record MUST have a flags value of 00 or 01 (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data.
署名キーレコードには、00または01のフラグ値が必要です（認証許可、機密性オプション）[RFC2535、3.1.2]。DNSSECリゾルバーは、データを認証することが許可されているキーによって生成された署名のみを信頼する必要があります。
The interpretation of this field is considerably different for data SIGs and SIG(0) records.
このフィールドの解釈は、データSIGとSIG（0）レコードでかなり異なります。
If the SIG record covers an RRset, the name type of the associated KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section 2.3.6. The DNSSEC validation process performed by a resolver MUST ignore all keys that are not zone keys unless local policy dictates otherwise.
SIGレコードがRRSetをカバーする場合、関連するキーの名前タイプは01（ゾーン）[RFC2535、3.1.2]でなければなりません。これにより、RFC 2535、セクション2.3.6が更新されます。リゾルバーによって実行されるDNSSEC検証プロセスは、ローカルポリシーが特に指示しない限り、ゾーンキーではないすべてのキーを無視する必要があります。
The primary reason that RFC 2535 allows host and user keys to generate material DNSSEC signatures is to allow dynamic update without online zone keys; that is, avoid storing private keys in an online server. The desire to avoid online signing keys cannot be achieved, though, because they are necessary to sign NXT and SOA sets [RFC3007]. These online zone keys can sign any incoming data. Removing the goal of having no online keys removes the reason to allow host and user keys to generate material signatures.
RFC 2535がホストとユーザーキーが材料DNSSEC署名を生成できる主な理由は、オンラインゾーンキーなしで動的な更新を許可することです。つまり、オンラインサーバーにプライベートキーの保存を避けてください。ただし、NXTとSOAセットに署名するために必要であるため、オンライン署名キーを避けたいという欲求は達成できません[RFC3007]。これらのオンラインゾーンキーは、着信データに署名できます。オンラインキーを持たないという目標を削除すると、ホストとユーザーキーがマテリアルシグネチャを生成できるようにする理由を削除します。
Limiting material signatures to zone keys simplifies the validation process. The length of the verification chain is bounded by the name's label depth. The authority of a key is clearly defined; a resolver does not need to make a potentially complicated decision to determine whether a key has the proper authority to sign data.
ゾーンキーに材料署名を制限すると、検証プロセスが簡素化されます。検証チェーンの長さは、名前のラベル深度によって区切られています。鍵の権限は明確に定義されています。リゾルバーは、キーがデータに署名する適切な権限を持っているかどうかを判断するために、潜在的に複雑な決定を下す必要はありません。
Finally, there is no additional flexibility granted by allowing host/user key generated material signatures. As long as users and hosts have the ability to authenticate update requests to the primary zone server, signatures by zone keys are sufficient to protect the integrity of the data to the world at large.
最後に、ホスト/ユーザーキーで生成されたマテリアルシグネチャを許可することにより、追加の柔軟性が与えられません。ユーザーとホストがプライマリゾーンサーバーに更新要求を認証する機能を持っている限り、ゾーンキーによる署名は、データの整合性を世界全体に保護するのに十分です。
If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions are initiated by a host or user, not a zone, so zone keys SHOULD not generate SIG(0) records.
SIGレコードがメッセージを保護するSIG（0）の場合、関連するキーの名前タイプは00（ユーザー）または10（ホスト/エンティティ）でなければなりません。トランザクションはゾーンではなくホストまたはユーザーによって開始されるため、ゾーンキーはSIG（0）レコードを生成してはなりません。
A client is either explicitly executed by a user or on behalf of a host, therefore the name type of a SIG(0) generated by a client SHOULD be either user or host. A nameserver is associated with a host, and its use of SIG(0) is not associated with a particular zone, so the name type of a SIG(0) generated by a nameserver SHOULD be host.
クライアントは、ユーザーによって明示的に実行されるか、ホストに代わって実行されるため、クライアントが生成するSIG（0）の名前タイプは、ユーザーまたはホストのいずれかである必要があります。名前サーバーはホストに関連付けられており、SIG（0）の使用は特定のゾーンに関連付けられていないため、名前サーバーによって生成されたSIG（0）の名前タイプはホストである必要があります。
This document does not assign any values to the signatory field, nor require any values to be present.
このドキュメントでは、署名フィールドに値を割り当てず、値を存在させる必要もありません。
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver MUST NOT trust any signature that it generates.
署名キーレコードのプロトコル値は3（DNSSEC）または255（すべて）のプロトコル値を持っている必要があります。キーがDNSSECで使用するために指定されていない場合、DNSSECリゾルバーは、生成する署名を信頼してはなりません。
The algorithm field MUST be identical to that of the generated SIG record, and MUST meet all requirements for an algorithm value in a SIG record.
アルゴリズムフィールドは、生成されたSIGレコードと同一である必要があり、SIGレコードのアルゴリズム値のすべての要件を満たす必要があります。
4 - Security Considerations
4-セキュリティ上の考慮事項
This document defines a standard baseline for a DNSSEC capable resolver. This is necessary for a thorough security analysis of DNSSEC, if one is to be done.
このドキュメントでは、DNSSEC対応リゾルバーの標準ベースラインを定義します。これは、DNSSECの徹底的なセキュリティ分析に必要です。
Specifically, this document places additional restrictions on SIG records that a resolver must validate before the signature can be considered worthy of DNSSEC trust. This simplifies the protocol, making it more robust and able to withstand scrutiny by the security community.
具体的には、このドキュメントは、署名がDNSSECトラストに値すると見なす前に、リゾルバーが検証する必要があるSIGレコードに追加の制限を配置します。これにより、プロトコルが簡素化され、セキュリティコミュニティによるより堅牢で、精査に耐えることができます。
5 - Acknowledgements
5-謝辞
The author would like to thank the following people for review and informative comments (in alphabetical order):
著者は、レビューと有益なコメント（アルファベット順）について次の人々に感謝したいと思います。
Olafur Gudmundsson Ed Lewis
Olafur Gudmundsson Ed Lewis
6 - References
6-参照
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136] Vixie（ed。）、P.、Thomson、S.、Rekhter、Y。およびJ. Bound、「ドメイン名システムの動的更新」、RFC 2136、1997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.
[RFC2931] EastLake、D。、「DNSリクエストとトランザクション署名（SIG（0）s）」、RFC 2931、2000年9月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007] Wellington、B。、「Simple Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
7 - Author's Address
7-著者の住所
Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063
ブライアンウェリントンノミナム社950チャーターストリートレッドウッドシティ、カリフォルニア94063
Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
8 Full Copyright Statement
8完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。