RFC2137 日本語訳
2137 Secure Domain Name System Dynamic Update. D. Eastlake 3rd. April 1997. (Format: TXT=24824 bytes) (Obsoleted by RFC3007) (Updates RFC1035) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 2137 CyberCash, Inc. Updates: 1035 April 1997 Category: Standards Track
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 2137のサイバーキャッシュInc.アップデート: 1035 1997年4月のカテゴリ: 標準化過程
Secure Domain Name System Dynamic Update
安全なドメインネームシステムダイナミック・アップデート
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services [RFC2065]. DNS Dynamic Update operations have also been defined [RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys.
ドメインネームシステム(DNS)プロトコル拡大は、DNSのデータを認証して、主要な配布サービス[RFC2065]を提供するために定義されました。 また、しかし、DNSダイナミック・アップデート操作はアップデート操作のためにセキュリティの詳述なしで定義されました[RFC2136]。 このメモは、どのようにアップデートを保証するために要求とデータを含んでいるDNSSECデジタル署名を使用して、アップデートをupdaterの暗号化キーの所持によって示されるようにそれらを実行するのが認可されたものに制限するかを説明します。
Acknowledgements
承認
The contributions of the following persons (who are listed in alphabetic order) to this memo are gratefully acknowledged:
以下の人々(アルファベット順に記載されています)のこのメモへの貢献は感謝して承諾されます:
Olafur Gudmundsson (ogud@tis.com>
Charlie Kaufman <Charlie_Kaufman@iris.com>
Stuart Kwan <skwan@microsoft.com>
Edward Lewis <lewis@tis.com>
Olafur Gudmundsson (ogud@tis.com> Charlie Kaufman <Charlie_Kaufman@iris.com> Stuart Kwan <skwan@microsoft.com> Edward Lewis <lewis@tis.com>
Table of Contents
目次
1. Introduction............................................2
1.1 Overview of DNS Dynamic Update.........................2
1.2 Overview of DNS Security...............................2
2. Two Basic Modes.........................................3
3. Keys....................................................5
3.1 Update Keys............................................6
3.1.1 Update Key Name Scope................................6
3.1.2 Update Key Class Scope...............................6
3.1.3 Update Key Signatory Field...........................6
1. 序論…2 DNSダイナミック・アップデートの1.1概要…2 DNSセキュリティの1.2概要…2 2. 2つの基本のモード…3 3. キー…5 3.1 キーをアップデートしてください…6 3.1 .1 主要な名前範囲をアップデートしてください…6 3.1 .2 キークラス範囲をアップデートしてください…6 3.1 .3 主要な署名している分野をアップデートしてください…6
Eastlake Standards Track [Page 1] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[1ページ]。
3.2 Zone Keys and Update Modes.............................8
3.3 Wildcard Key Punch Through.............................9
4. Update Signatures.......................................9
4.1 Update Request Signatures..............................9
4.2 Update Data Signatures................................10
5. Security Considerations................................10
References................................................10
Author's Address..........................................11
3.2 ゾーンキーとアップデートモード…8 キーが突き抜けるのにパンチする3.3ワイルドカード…9 4. 署名をアップデートしてください…9 4.1 要求署名をアップデートしてください…9 4.2 データ署名をアップデートしてください…10 5. セキュリティ問題…10の参照箇所…10作者のアドレス…11
1. Introduction
1. 序論
Dynamic update operations have been defined for the Domain Name System (DNS) in RFC 2136, but without a detailed description of security for those updates. Means of securing the DNS and using it for key distribution have been defined in RFC 2065.
ダイナミックなアップデート操作はRFC2136のドメインネームシステム(DNS)のために定義されますが、それらのアップデートのためのセキュリティの詳述なしで定義されました。 DNSを固定して、主要な分配にそれを使用する手段はRFC2065で定義されました。
This memo proposes techniques based on the defined DNS security mechanisms to authenticate DNS updates.
このメモはDNSアップデートを認証するために定義されたDNSセキュリティー対策に基づくテクニックを提案します。
Familiarity with the DNS system [RFC 1034, 1035] is assumed. Familiarity with the DNS security and dynamic update proposals will be helpful.
DNSシステム[RFC1034、1035]への親しみは想定されます。 DNSセキュリティとダイナミックなアップデート提案への親しみは役立つでしょう。
1.1 Overview of DNS Dynamic Update
1.1 DNSダイナミック・アップデートの概要
DNS dynamic update defines a new DNS opcode, new DNS request and response structure if that opcode is used, and new error codes. An update can specify complex combinations of deletion and insertion (with or without pre-existence testing) of resource records (RRs) with one or more owner names; however, all testing and changes for any particular DNS update request are restricted to a single zone. Updates occur at the primary server for a zone.
DNSのダイナミックなアップデートはそのopcodeが中古の、そして、新しいエラーコードであるなら新しいDNS opcode、新しいDNS要求、および応答構造を定義します。 アップデートは1つ以上の所有者名によるリソース記録(RRs)の削除と挿入(プレ存在テストのあるなしにかかわらず)の複雑な組み合わせを指定できます。 しかしながら、どんな特定のDNS更新要求のためのすべてのテストと変化もただ一つのゾーンに制限されます。 アップデートはゾーンへのプライマリサーバで起こります。
The primary server for a secure dynamic zone must increment the zone SOA serial number when an update occurs or the next time the SOA is retrieved if one or more updates have occurred since the previous SOA retrieval and the updates themselves did not update the SOA.
アップデートが起こるか、または前のSOA検索とアップデート自体がSOAをアップデートしないで以来1つ以上のアップデートが起こっているならSOAが次の時に検索されるとき、安全なダイナミックなゾーンへのプライマリサーバはゾーンSOA通し番号を増加しなければなりません。
1.2 Overview of DNS Security
1.2 DNSセキュリティの概要
DNS security authenticates data in the DNS by also storing digital signatures in the DNS as SIG resource records (RRs). A SIG RR provides a digital signature on the set of all RRs with the same owner name and class as the SIG and whose type is the type covered by the SIG. The SIG RR cryptographically binds the covered RR set to the signer, time signed, signature expiration date, etc. There are one or more keys associated with every secure zone and all data in the secure zone is signed either by a zone key or by a dynamic update
DNSセキュリティは、また、SIGリソース記録(RRs)としてDNSにデジタル署名を保存することによって、DNSのデータを認証します。 SIG RRはSIGとだれのタイプがSIGでカバーされたタイプであるかとしてすべてのRRsのセットで同じ所有者名とクラスにデジタル署名を提供します。 SIG RRは暗号で署名者、署名している時間署名有効期限などにカバーされたRRセットを縛ります。 あらゆる安全なゾーンに関連している1個以上のキーがあります、そして、ゾーンキーかダイナミックなアップデートで安全なゾーンのすべてのデータが署名されます。
Eastlake Standards Track [Page 2] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[2ページ]。
key tracing its authority to a zone key.
ゾーンキーへの権威をたどるキー。
DNS security also defines transaction SIGs and request SIGs. Transaction SIGs appear at the end of a response. Transaction SIGs authenticate the response and bind it to the corresponding request with the key of the host where the responding DNS server is. Request SIGs appear at the end of a request and authenticate the request with the key of the submitting entity.
また、DNSセキュリティはトランザクションSIGと要求SIGを定義します。 トランザクションSIGは応答の終わりに現れます。 トランザクションSIGは、応じているDNSサーバがそうであるホストのキーで応答を認証して、対応する要求にそれを縛ります。 SIGが要求の終わりに現れて、提出実体のキーで要求を認証するよう要求してください。
Request SIGs are the primary means of authenticating update requests.
SIGが更新要求を認証するプライマリ手段であるよう要求してください。
DNS security also permits the storage of public keys in the DNS via KEY RRs. These KEY RRs are also, of course, authenticated by SIG RRs. KEY RRs for zones are stored in their superzone and subzone servers, if any, so that the secure DNS tree of zones can be traversed by a security aware resolver.
また、DNSセキュリティはKEY RRsを通してDNSでの公開鍵のストレージを可能にします。 また、これらのKEY RRsはもちろんSIG RRsによって認証されます。 ゾーンへのKEY RRsはそれらの「スーパー-ゾーン」と「副-ゾーン」サーバで保存されます、もしあれば、セキュリティの意識しているレゾルバがゾーンの安全なDNS木を横断できるように。
2. Two Basic Modes
2. 2つの基本のモード
A dynamic secure zone is any secure DNS zone containing one or more KEY RRs that can authorize dynamic updates, i.e., entity or user KEY RRs with the signatory field non-zero, and whose zone KEY RR signatory field indicates that updates are implemented. There are two basic modes of dynamic secure zone which relate to the update strategy, mode A and mode B. A summary comparison table is given below and then each mode is described.
ダイナミックな安全なゾーンは署名している分野が非ゼロに合わせていてダイナミックなアップデート、すなわち、実体かユーザKEY RRsを認可できて、ゾーンのKEY RRの署名している分野がアップデートが実装されるのを示す1KEY RRsを含むあらゆる安全なDNSゾーンです。 アップデート戦略に関連するダイナミックな安全なゾーンの2つの基本のモードがあります、そして、AとモードB.A概要比較が見送るモードを以下に与えます、そして、次に、各モードを説明します。
Eastlake Standards Track [Page 3] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[3ページ]。
SUMMARY OF DYNAMIC SECURE ZONE MODES
ダイナミックな安全なゾーンモードの概要
CRITERIA: | MODE A | MODE B =========================+====================+=================== Definition: | Zone Key Off line | Zone Key On line =========================+====================+=================== Server Workload | Low | High -------------------------+--------------------+------------------- Static Data Security | Very High | Medium-High -------------------------+--------------------+------------------- Dynamic Data Security | Medium | Medium-High -------------------------+--------------------+------------------- Key Restrictions | Fine grain | Coarse grain -------------------------+--------------------+------------------- Dynamic Data Temporality | Transient | Permanent -------------------------+--------------------+------------------- Dynamic Key Rollover | No | Yes -------------------------+--------------------+-------------------
評価基準: | モードA| モードB=========================+====================+=================== 定義: | ゾーンKey Off線| ゾーンKey On線=========================+====================+=================== サーバワークロード| 安値| 高値-------------------------+--------------------+------------------- 静的なデータ機密保護| 非常に高いです。| 媒体高いです。-------------------------+--------------------+------------------- ダイナミックなデータ機密保護| 媒体| 媒体高いです。-------------------------+--------------------+------------------- 主要な制限| 細粒| 粗粉-------------------------+--------------------+------------------- ダイナミックなデータ一時性| 一時的| 永久的-------------------------+--------------------+------------------- ダイナミックな主要なロールオーバー| いいえ| はい-------------------------+--------------------+-------------------
For mode A, the zone owner key and static zone master file are always kept off-line for maximum security of the static zone contents.
モードAにおいて、ゾーンの所有者の主要で静的なゾーン基本ファイルは静的なゾーンコンテンツの最大のセキュリティのためにオフラインにいつも保たれます。
As a consequence, any dynamicly added or changed RRs are signed in the secure zone by their authorizing dynamic update key and they are backed up, along with this SIG RR, in a separate online dynamic master file. In this type of zone, server computation is minimized since the server need only check signatures on the update data and request, which have already been signed by the updater, generally a much faster operation than signing data. However, the AXFR SIG and NXT RRs which covers the zone under the zone key will not cover dynamically added data. Thus, for type A dynamic secure zones, zone transfer security is not automatically provided for dynamically added RRs, where they could be omitted, and authentication is not provided for the server denial of the existence of a dynamically added type. Because the dynamicly added RRs retain their update KEY signed SIG, finer grained control of updates can be implemented via bits in the KEY RR signatory field. Because dynamic data is only stored in the online dynamic master file and only authenticated by dynamic keys which expire, updates are transient in nature. Key rollover for an entity that can authorize dynamic updates is more cumbersome since the authority of their key must be traceable to a zone key and so, in general, they must securely communicate a new key to the zone authority for manual transfer to the off line static master file. NOTE: for this mode the zone SOA must be signed by a dynamic update key and that private key must be kept on line so that the SOA can be changed for updates.
彼らがダイナミックなアップデートキーを認可することによって、安全なゾーンは変えられたRRsにサインインされます、そして、結果として、どんなダイナミックも加えたか、または彼らは支援されます、このSIG RRと共に、別々のオンラインダイナミックな基本ファイルで。 このタイプのゾーンでは、サーバがアップデートデータと要求(updater(一般にデータに署名するよりはるかに速い操作)によって既に署名された)のときに署名をチェックするだけでよいので、サーバ計算が最小にされます。 しかしながら、AXFR SIGとゾーンキーの下のゾーンをカバーするNXT RRsがダイナミックに付記されたデータをカバーしないでしょう。 したがって、タイプA動力安全なゾーンにおいて、ゾーン転送セキュリティはダイナミックに加えられたRRsに自動的に提供されません。そこでは、彼らを省略できて、認証はダイナミックに加えられたタイプの存在のサーバ否定に提供されません。 ダイナミックが、RRsがSIGであると署名される彼らのアップデートKEYを保有すると言い足したので、KEY RRの署名している分野のビットによってアップデートの、よりよい粒状の管理を実施されることができます。 ダイナミックなデータがオンラインダイナミックな基本ファイルに保存されるだけであり、期限が切れるダイナミックなキーによって認証されるだけであるので、アップデートは現実に一時的です。 それらのキーの権威がゾーンキーに起因しているに違いなくて、ダイナミックなアップデートを認可できる実体のための主要なロールオーバーは、より厄介です、そして、そのように、そして、一般に、彼らはオフラインの静的な基本ファイルへの手動移載式のためにしっかりとゾーン権威の新しいキーを伝えなければなりません。 以下に注意してください。 このモードにおいて、ダイナミックなアップデートキーでゾーンSOAに署名しなければなりません、そして、アップデートのためにSOAを変えることができるようにその秘密鍵を稼働中に保たなければなりません。
Eastlake Standards Track [Page 4] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[4ページ]。
For mode B, the zone owner key and master file are kept on-line at the zone primary server. When authenticated updates succeed, SIGs under the zone key for the resulting data (including the possible NXT type bit map changes) are calculated and these SIG (and possible NXT) changes are entered into the zone and the unified on-line master file. (The zone transfer AXFR SIG may be recalculated for each update or on demand when a zone transfer is requested and it is out of date.)
モードBにおいて、ゾーン所有者キーと基本ファイルはゾーンのプライマリサーバでオンラインに保たれます。認証されると、アップデートは成功します、そして、結果として起こるデータ(可能なNXTタイプビットマップ変化を含んでいる)に、主要なゾーンの下におけるSIGは計算されます、そして、これらのSIG(そして、可能なNXT)変化はゾーンと統一されたオンライン基本ファイルに入れられます。 (ゾーン転送が要求されていて、それが各アップデートか要求のときに時代遅れであるときに、ゾーン転送AXFR SIGは再計算されるかもしれません。)
As a consequence, this mode requires considerably more computational effort on the part of the server as the public/private keys are generally arranged so that signing (calculating a SIG) is more effort than verifying a signature. The security of static data in the zone is decreased because the ultimate state of the static data being served and the ultimate zone authority private key are all on-line on the net. This means that if the primary server is subverted, false data could be authenticated to secondaries and other servers/resolvers. On the other hand, this mode of operation means that data added dynamically is more secure than in mode A. Dynamic data will be covered by the AXFR SIG and thus always protected during zone transfers and will be included in NXT RRs so that it can be falsely denied by a server only to the same extent that static data can (i.e., if it is within a wild card scope). Because the zone key is used to sign all the zone data, the information as to who originated the current state of dynamic RR sets is lost, making unavailable the effects of some of the update control bits in the KEY RR signatory field. In addition, the incorporation of the updates into the primary master file and their authentication by the zone key makes then permanent in nature. Maintaining the zone key on-line also means that dynamic update keys which are signed by the zone key can be dynamically updated since the zone key is available to dynamically sign new values.
公衆/秘密鍵が一般にアレンジされるとき結果として、このモードがサーバ側のかなり多くの計算量を必要とするので、署名(SIGについて計算する)は署名について確かめるより多くの取り組みです。 役立たれている静的なデータの究極の状態と究極のゾーン権威秘密鍵がネットですべてオンラインであるので、ゾーンにおける、静的なデータのセキュリティは下がります。 これは、プライマリサーバが打倒されるなら、誤ったデータが代理人と他のサーバ/レゾルバに認証されるかもしれないことを意味します。 他方では、この運転モードは、ダイナミックに加えられたデータが流行しているA.Dynamicデータがサーバによって静的なデータがそうすることができることが間違って同じ範囲だけに対して否定される場合がある(すなわち、ワイルドカード範囲の中にそれがあるなら)ようにAXFR SIGでカバーされていて、ゾーン転送の間、このようにしていつも保護されて、NXT RRsに含まれるより安全であることを意味します。 ゾーンキーがすべてのゾーンデータに署名するのに使用されるので、だれがダイナミックなRRセットの現状を溯源したかの情報は無くなります、KEY RRの署名している分野のいくつかのアップデートコントロールビットの効果を入手できなくして。 さらに、プライマリ基本ファイルへのアップデートの編入とゾーンキーによる彼らの認証で、その時は現実に永久的になります。 また、ゾーンキーをオンラインに維持するのは、ゾーンキーがダイナミックに新しい値に署名するために利用可能であるのでダイナミックにゾーンキーによって署名されるダイナミックなアップデートキーはアップデートできることを意味します。
NOTE: The Mode A / Mode B distinction only effects the validation and performance of update requests. It has no effect on retrievals. One reasonable operational scheme may be to keep a mostly static main zone operating in Mode A and have one or more dynamic subzones operating in Mode B.
以下に注意してください。 Mode A/モードB区別は更新要求の合法化と性能に作用するだけです。 それはretrievalsで効き目がありません。 1つの妥当な操作上の体系は、ほとんど静的な主なゾーンをMode Aで作動させ続けて、1つ以上のダイナミックな「副-ゾーン」をMode Bで作動させることであるかもしれません。
3. Keys
3. キー
Dynamic update requests depend on update keys as described in section 3.1 below. In addition, the zone secure dynamic update mode and availability of some options is indicated in the zone key. Finally, a special rule is used in searching for KEYs to validate updates as described in section 3.3.
ダイナミックな更新要求は下のセクション3.1で説明されるようにアップデートキーによります。 さらに、いくつかのオプションのゾーンの安全なダイナミックな更新モードと有用性はゾーンキーで示されます。 最終的に、特別な規則はセクション3.3で説明されるようにアップデートを有効にするためにKEYsを捜し求める際に使用されます。
Eastlake Standards Track [Page 5] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[5ページ]。
3.1 Update Keys
3.1 アップデートキー
All update requests to a secure zone must include signatures by one or more key(s) that together can authorize that update. In order for the Domain Name System (DNS) server receiving the request to confirm this, the key or keys must be available to and authenticated by that server as a specially flagged KEY Resource Record.
安全なゾーンへのすべての更新要求が1時までに署名を含まなければならない、さもなければ、そんなに一緒にいるより多くのキーがそのアップデートを認可できます。 これを確認するという要求を受け取るドメインネームシステム(DNS)サーバにおいて整然とします、キーかキーが、特に、旗を揚げさせられたKEY Resource Recordとしてのそのサーバで利用可能で認証していなければなりません。
The scope of authority of such keys is indicated by their KEY RR owner name, class, and signatory field flags as described below. In addition, such KEY RRs must be entity or user keys and not have the authentication use prohibited bit on. All parts of the actual update must be within the scope of at least one of the keys used for a request SIG on the update request as described in section 4.
そのようなキーの権限の範囲は以下で説明されるようにそれらのKEY RR所有者名、クラス、および署名している分野旗で示されます。 さらに、そのようなKEY RRsは実体かユーザキーであり、噛み付かれた状態で禁止された認証使用をオンに持ってはいけません。 少なくとも更新要求のときに要求SIGにセクション4で説明されるように使用されたキーの1つの範囲の中に実際のアップデートのすべての部品があるに違いありません。
3.1.1 Update Key Name Scope
3.1.1 アップデートの主要な名前範囲
The owner name of any update authorizing KEY RR must (1) be the same as the owner name of any RRs being added or deleted or (2) a wildcard name including within its extended scope (see section 3.3) the name of any RRs being added or deleted and those RRs must be in the same zone.
KEY RRを認可すると(1) いずれかの所有者名と(2) 加えられるか、または削除されるRRsかワイルドカードが拡張範囲(セクション3.3を見る)の中の包含を名前と命名する同じくらいが加えられるか、または削除されるどんなRRsとそれらのRRsであったならもそうしなければならないどんなアップデートの所有者名も同じゾーンにあるに違いありません。
3.1.2 Update Key Class Scope
3.1.2 アップデートキークラス範囲
The class of any update authorizing KEY RR must be the same as the class of any RR's being added or deleted.
KEY RRを認可するどんなアップデートのクラスも加えられるか、または削除されるどんなRRのクラスとも同じであるに違いありません。
3.1.3 Update Key Signatory Field
3.1.3 アップデートの主要な署名している分野
The four bit "signatory field" (see RFC 2065) of any update authorizing KEY RR must be non-zero. The bits have the meanings described below for non-zone keys (see section 3.2 for zone type keys).
KEY RRを認可するどんなアップデートの4ビット「署名している分野」(RFC2065を見る)も非ゼロであるに違いありません。 ビットには、非ゾーンキーのために以下で説明された意味があります(ゾーンタイプキーのためにセクション3.2を見てください)。
UPDATE KEY RR SIGNATORY FIELD BITS
主要なRR署名している分野ビットをアップデートしてください。
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
0 1 2 3 +-----------+-----------+-----------+-----------+ | ゾーン| 強い| ユニーク| 一般| +-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones.
ビット0、地域空調--非零であるなら、このキーは、NS、接着剤A、およびゾーンKEY RR(s)を作成して、削除することによってゾーンを付けて、取り外して、動かすのが認可されます。 ゼロであるなら、キーはそのようなRRsに作用するどんなアップデートも認可できません。 両方のタイプAとタイプBのダイナミックな安全なゾーンに、このビットは重要です。
Eastlake Standards Track [Page 6] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[6ページ]。
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
以下に注意してください。 「ゾーン」署名している分野ビットを「ゾーン」主要なタイプビットに混乱させないでください。
Bit 1, strong update - If nonzero, this key is authorized to add and
delete RRs even if there are other RRs with the same owner name
and class that are authenticated by a SIG signed with a
different dynamic update KEY. If zero, the key can only
authorize updates where any existing RRs of the same owner and
class are authenticated by a SIG using the same key. This bit
is meaningful only for type A dynamic zones and is ignored in
type B dynamic zones.
ビット1、強いアップデート--非零であるなら、同じ所有者名と異なったダイナミックなアップデートKEYを契約されたSIGによって認証されるクラスがある他のRRsがあっても、このキーは、RRsを加えて、削除するのが認可されます。 ゼロである場合にだけ、同じ所有者とクラスのどんな既存のRRsも同じキーを使用することでSIGによって認証されるところでキーはアップデートを認可できます。 このビットは、タイプA動力ゾーンだけに重要であり、タイプB動力ゾーンで無視されます。
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are limited in interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
いずれとも異なった所有者名でRRsに作用できないのを除いて、同じであるか入れ子にされたワイルドカード所有者名がある複数のKEY RRsのゼロが存在する名前を作成して、削除できる複数の実体を可能にするこのビットをそれらが作成した保つこと。 事実上、これは2つのレベルのダイナミックなアップデートキー、強弱、どこに弱いキーが互いを妨げるのが制限されますが、強いキーが何か弱いキーを妨げることができるか、そして、または他の強いキーを創造します。
Bit 2, unique name update - If nonzero, this key is authorized to add
and update RRs for only a single owner name. If there already
exist RRs with one or more names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones and is ignored in mode B dynamic zones. This bit
is meaningful only if the owner name is a wildcard. (Any
dynamic update KEY with a non-wildcard name is, in effect, a
unique name update key.)
ビット2、ユニークな名前アップデート--非零であるなら、このキーは、ただ一つの所有者名だけのためにRRsを加えて、アップデートするのが認可されます。 1つ以上の名前がこのキーによって調印されているRRsが既に存在しているなら、それらをアップデートするかもしれませんが、既存の名前の数まで作成されたどんな新しい名前もゼロまで減少させません。 このビットは、モードのAダイナミックなゾーンだけに重要であり、モードのBダイナミックなゾーンで無視されます。 このビットは所有者名がワイルドカードである場合にだけ重要です。 (事実上、非ワイルドカード名があるどんなダイナミックなアップデートKEYもユニークな名前アップデートキーです。)
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
新しい名前でゾーンをあふれさせるのでKEYを制限するのにこのビットを使用できます。 特定の名前があるダイナミックなRRsの数における地方の行政上課された限界に関連して、それは、RRsと共にゾーンをあふれさせるので、KEYを完全に制限する場合があります。
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero to designate that the key
is an update key. The meaning of all values of the signatory
field with the general bit and one or more other signatory field
bits on is reserved.
ビット3、一般的なアップデート--署名している分野ビットが意味しながらいいえ特別にする一般的なアップデート。 それが他の3ビットがすべてゼロであるなら、1であるに違いないので、分野がキーにそれを指定するために非ゼロに合わせることは、アップデートキーです。 一般的なビットと他の署名している1分野のビット以上がオンの署名している分野のすべての値の意味は予約されています。
All the signatory bit update authorizations described above only apply if the update is within the name and class scope as per sections 3.1.1 and 3.1.2.
すべての署名しているビット、上で説明されたアップデート承認はアップデートが名前の中のそうであり、セクション3.1 .1と3.1に従ってクラス範囲が.2である場合にだけ適用されます。
Eastlake Standards Track [Page 7] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[7ページ]。
3.2 Zone Keys and Update Modes
3.2 ゾーンキーと更新モード
Zone type keys are automatically authorized to sign anything in their zone, of course, regardless of the value of their signatory field. For zone keys, the signatory field bits have different means than they they do for update keys, as shown below. The signatory field MUST be zero if dynamic update is not supported for a zone and MUST be non-zero if it is.
ゾーンタイプキーがそれらの署名している分野の値にかかわらずもちろんそれらのゾーンで何にでも署名するのが自動的に認可されます。 署名者分野ビットには、ゾーンキーに関して、それらと異なった手段があります。それらはアップデートキーのために以下で示されるとしてします。 署名している分野はそれがゼロであるならダイナミックなアップデートがゾーンにサポートされないで、非ゼロに合わせなければならないならゼロであるに違いありません。
ZONE KEY RR SIGNATORY FIELD BITS
ゾーン主要なRR署名している分野ビット
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
0 1 2 3 +-----------+-----------+-----------+-----------+ | モード| 強い| ユニーク| 一般| +-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
ビット0、モード--このビットはこのゾーンに更新モードを示します。 人はモードBを示しますが、ゼロはモードAを示します。
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available. Has no effect if the zone is a mode B secure update
zone.
ビット1、強いアップデート--非零であるなら、これは、上のセクション3.1.3で説明された「強い」重要な特色がこの安全なゾーンに実装されて、可能にされるのを示します。 ゼロであるなら、特徴は利用可能ではありません。 ゾーンがモードのB安全なアップデートゾーンであるなら、効き目がありません。
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available. Has no effect if the zone is a mode B
secure update zone.
ビット2、ユニークな名前アップデート--非零であるなら、これは、特徴という上のセクション3.1.3で説明された「ユニークな名前」がこの安全なゾーンに実装されて、可能にされるのを示します。 ゼロであるなら、この特徴は利用可能ではありません。 ゾーンがモードのB安全なアップデートゾーンであるなら、効き目がありません。
Bit 3, general - This bit has no special meeting. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and one or
more other bits on is reserved.
ビット3、一般--このビットには、臨時会議が全くありません。 ゾーンのためのダイナミックなアップデートがサポートされて、ゾーンの主要な署名している分野の他のビットがゼロであるなら、それは1つであるに違いありません。 署名している分野が一般的なビットと他の1ビット以上をオンに持っているゾーンキーの意味は予約されています。
If there are multiple dynamic update KEY RRs for a zone and zone policy is in transition, they might have different non-zero signatory fields. In that case, strong and unique name restrictions must be enforced as long as there is a non-expired zone key being advertised that indicates mode A with the strong or unique name bit on respectively. Mode B updates MUST be supported as long as there is a non-expired zone key that indicates mode B. Mode A updates may be treated as mode B updates at server option if non-expired zone keys indicate that both are supported.
彼らには、あれば、ゾーンとゾーン方針のための複数のダイナミックなアップデートKEY RRsが変遷中であり、異なった非ゼロ署名している分野があるかもしれません。 その場合、ビットという強いかユニークな名前がオンな状態でそれぞれモードAを示す広告に掲載されている非満期のゾーンキーがある限り、強くてユニークな名前制限は励行されなければなりません。 非満期のゾーンキーが、両方がサポートされるのを示すならモードB.Mode Aアップデートがサーバ選択でモードBアップデートとして扱われるかもしれないのを示す非満期のゾーンキーがある限り、モードBアップデートをサポートしなければなりません。
Eastlake Standards Track [Page 8] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[8ページ]。
A server that will be executing update operations on a zone, that is, the primary master server, MUST not advertize a zone key that will attract requests for a mode or features that it can not support.
ゾーンでアップデート操作を実行するサーバ(すなわち、プライマリマスターサーバ)はモードを求める要求を引き付けるゾーンキーかそれが支えることができない特徴をadvertizeしてはいけません。
3.3 Wildcard Key Punch Through
3.3 キーが突き抜けるのにパンチするワイルドカード
Just as a zone key is valid throughout the entire zone, update keys with wildcard names are valid throughout their extended scope, within the zone. That is, they remain valid for any name that would match them, even existing specific names within their apparent scope.
ちょうどゾーンキーが全体のゾーン中で有効であるので、ワイルドカード名があるアップデートキーはそれらの拡張範囲中で有効です、ゾーンの中で。 すなわち、彼らはそれらの見かけの範囲の中にそれらに合っているどんな名前、既存の種名にさえも有効なままで残っています。
If this were not so, then whenever a name within a wildcard scope was created by dynamic update, it would be necessary to first create a copy of the KEY RR with this name, because otherwise the existence of the more specific name would hide the authorizing KEY RR and would make later updates impossible. An updater could create such a KEY RR but could not zone sign it with their authorizing signer. They would have to sign it with the same key using the wildcard name as signer. Thus in creating, for example, one hundred type A RRs authorized by a *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 KEYs, and 200 SIGs would have to be created as opposed to merely 100 As and 100 SIGs with key punch through.
したがって、これがそうでないなら、次に、ワイルドカード範囲の中の名前がダイナミックなアップデートで作成されたときはいつも、最初にこの名前でKEY RRのコピーを作成するのが必要でしょうに、さもなければ、より特定の名前の存在で、認可しているKEY RRを隠して、後のアップデートは不可能になるでしょう、したがって。 updaterはそのようなKEY RRを作成できましたが、ゾーンは彼らが署名者を認可するのをそれと契約できませんか? 署名者としてワイルドカード名を使用することで彼らは同じキーでそれに署名しなければならないでしょう。 したがって、作成では、例えば、100は*.1.1.1.in-addr.arpaによって認可されたA RRsをタイプします。 鍵盤穿孔機が終わっていて、100As、100KEYs、および200のSIGを通した鍵盤穿孔機のないKEY RRは単に100Asと100のSIGと対照的に作成されなければならないでしょう。
4. Update Signatures
4. アップデート署名
Two kinds of signatures can appear in updates. Request signatures, which are always required, cover the entire request and authenticate the DNS header, including opcode, counts, etc., as well as the data. Data signatures, on the other hand, appear only among the RRs to be added and are only required for mode A operation. These two types of signatures are described further below.
2種類の署名はアップデートに現れることができます。 署名を要求してください、そして、全体の要求をカバーしてください、そして、DNSヘッダーを認証してください、opcode、カウントなどを含んでいて、データと同様に。署名がいつも必要です。 データ署名が、他方では、加えられるべきRRsだけの中に現れて、モードA操作に必要であるだけです。 これらの2つのタイプの署名は以下でさらに説明されます。
4.1 Update Request Signatures
4.1 更新要求署名
An update can effect multiple owner names in a zone. It may be that these different names are covered by different dynamic update keys. For every owner name effected, the updater must know a private key valid for that name (and the zone's class) and must prove this by appending request SIG RRs under each such key.
アップデートはゾーンの複数の所有者名に作用できます。 多分、これらの異なった名前は異なったダイナミックなアップデートキーでカバーされています。 作用するあらゆる所有者名のために、updaterは、その名前(そして、ゾーンのクラス)に、有効な秘密鍵を知らなければならなくて、そのような各キーの下に要求SIG RRsを追加することによって、これを立証しなければなりません。
As specified in RFC 2065, a request signature is a SIG RR occurring at the end of a request with a type covered field of zero. For an update, request signatures occur in the Additional information section. Each request SIG signs the entire request, including DNS header, but excluding any other request SIG(s) and with the ARCOUNT in the DNS header set to what it wold be without the request SIGs.
RFC2065で指定されるように、要求署名は要求の終わりにタイプで起こるSIG RRがゼロの分野をカバーしたということです。 アップデートには、署名がAdditional情報収集部門に起こるよう要求してください。 それぞれの要求SIGは全体の要求に署名します、DNSヘッダーを含んでいてヘッダーが何にそれを設定するかというSIGとARCOUNTがDNSにあるいかなる他の要求を除いて、高原は要求SIGがなければそうです。
Eastlake Standards Track [Page 9] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[9ページ]。
4.2 Update Data Signatures
4.2 アップデートデータ署名
Mode A dynamic secure zones require that the update requester provide SIG RRs that will authenticate the after update state of all RR sets that are changed by the update and are non-empty after the update. These SIG RRs appear in the request as RRs to be added and the request must delete any previous data SIG RRs that are invalidated by the request.
モードのAダイナミックな安全なゾーンは、アップデートリクエスタがすべてのアップデートで変えられた、アップデートの後に非空のRRセットの状態を後アップデートを認証するSIG RRsに供給するのを必要とします。 加えられるべきRRsと要求が要求で無効にされるどんな前のデータSIG RRsも削除しなければならないとき、これらのSIG RRsは要求に現れます。
In Mode B dynamic secure zones, all zone data is authenticated by zone key SIG RRs. In this case, data signatures need not be included with the update. A resolver can determine which mode an updatable secure zone is using by examining the signatory field bits of the zone KEY RR (see section 3.2).
ModeのBダイナミックな安全なゾーンでは、すべてのゾーンデータがゾーンの主要なSIG RRsによって認証されます。 この場合、データ署名はアップデートで含まれる必要はありません。 レゾルバは、アップデート可能安全なゾーンがゾーンKEY RRの署名している分野ビットを調べることによってどのモードを使用しているかを決心できます(セクション3.2を見てください)。
5. Security Considerations
5. セキュリティ問題
Any zone permitting dynamic updates is inherently less secure than a static secure zone maintained off line as recommended in RFC 2065. If nothing else, secure dynamic update requires on line change to and re-signing of the zone SOA resource record (RR) to increase the SOA serial number. This means that compromise of the primary server host could lead to arbitrary serial number changes.
ダイナミックなアップデートを可能にするどんなゾーンも本来静的な安全なゾーンがRFC2065で推薦されるようにオフラインを維持したほど安全ではありません。 他に何もであるなら、安全なダイナミックなアップデートは、ゾーンSOAリソース記録(RR)が変化して、再契約するとSOA通し番号が増強されるのを稼働中に必要とします。 妥協するプライマリサーバー・ホストのこの手段は任意の通し番号変化に通じるかもしれません。
Isolation of dynamic RRs to separate zones from those holding most static RRs can limit the damage that could occur from breach of a dynamic zone's security.
それらの把持の最も静的なRRsとゾーンを切り離すダイナミックなRRsの分離はダイナミックなゾーンのセキュリティの不履行から発生できた損害を制限できます。
References
参照
[RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, CyberCash, Iris, January 1997.
[RFC2065] イーストレーク、D.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、CyberCash、虹彩、1997年1月。
[RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
Vixie、P.、エディタ、トムソン、T.、Rekhter、Y.、およびJ.が縛った[RFC2136]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
Eastlake Standards Track [Page 10] RFC 2137 SDNSDU April 1997
イーストレークStandardsはSDNSDU1997年4月にRFC2137を追跡します[10ページ]。
Author's Address
作者のアドレス
Donald E. Eastlake, 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA
ドナルド・E.イーストレーク、カーライル、第3CyberCash Inc.318アクトン通りMA01741米国
Phone: +1 508-287-4877
+1 508-371-7148 (fax)
+1 703-620-4200 (main office, Reston, Virginia, USA)
EMail: dee@cybercash.com
以下に電話をしてください。 +1 +1 508-287-4877+1 508-371-7148(ファックス)703-620-4200(本社、レストン(ヴァージニア)(米国))EMail: dee@cybercash.com
Eastlake Standards Track [Page 11]
イーストレーク標準化過程[11ページ]
一覧
スポンサーリンク
