Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 6168 Sparta, Inc.
Category: Informational May 2011
ISSN: 2070-1721
Requirements for Management of Name Servers for the DNS
Abstract
抽象
Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
ドメインネームシステム（DNS）のネームサーバの管理は、伝統的に、ベンダー固有の監視、構成、および制御方法を用いて行われてきました。いくつかのサービス監視プラットフォームは、DNS自体の機能をテストすることができますが、（監視、制御、および設定します）ネームサーバ自体の内部側面を管理するための相互運用可能な方法はありません。
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system.
この文書では、ネームサーバの管理システムの要件を説明し、このようなシステムのために必要な機能の買い物リストとして使用することができます。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション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/rfc6168.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6168で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Document Layout and Requirements . . . . . . . . . . . . . 5
2. Management Architecture Requirements . . . . . . . . . . . . . 5
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 6
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
3.2.5. DNS Protocol Authorization Management . . . . . . . . 10
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 11
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 16
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 17
Management of name servers for the Domain Name System (DNS) [RFC1034] [RFC1035] has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
ドメインネームシステム（DNS）[RFC1034] [RFC1035]のためのネームサーバの管理は、伝統的に、ベンダー固有の監視、構成、および制御方法を用いて行われてきました。いくつかのサービス監視プラットフォームは、DNS自体の機能をテストすることができますが、（監視、制御、および設定します）ネームサーバ自体の内部側面を管理するための相互運用可能な方法はありません。
Previous standardization work within the IETF resulted in the creation of two SNMP MIB modules [RFC1611] [RFC1612], but they failed to achieve significant implementation and deployment. The perceived reasons behind the failure for the two MIB modules are documented in [RFC3197].
IETF内の前の標準化作業は、2つのSNMP MIBモジュール[RFC1611] [RFC1612]の作成になったが、彼らは重要な実装と展開を達成するために失敗しました。 2つのMIBモジュールの障害の背後にある知覚理由は[RFC3197]に記載されています。
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document only discusses requirements for managing the name server component of a system -- not other elements of the system itself.
この文書では、ネームサーバの管理システムの要件を説明し、このようなシステムのために必要な機能の買い物リストとして使用することができます。システム自体のではない他の要素 - このドキュメントには、システムのネームサーバコンポーネントを管理するための要件について説明します。
Specifically out of scope for this document are requirements associated with the management of stub resolvers. It is not the intent of this document to document stub resolver requirements, although some of the requirements listed are applicable to stub resolvers as well.
具体的にはこの文書の範囲外スタブリゾルバの管理に関連する要件です。記載されている要件の一部が同様にスタブリゾルバに適用されるが、スタブリゾルバの要件を文書化するには、このドキュメントの意図ではありません。
The task of creating a management system for managing DNS servers is not expected to be a small one. It is likely that components of the solution will need to be designed in parts over time; these requirements take this into consideration. In particular, Section 5.1 discusses the need for future extensibility of the base management solution. This document is intended to be a roadmap towards a desired outcome and is not intended to define an "all-or-nothing" system. Successful interoperable management of name servers, even in part, is expected to be beneficial to network operators compared to the entirely custom solutions that are used at the time of this writing.
DNSサーバーを管理するための管理システムを作成するタスクは、小さな一つとして期待されていません。ソリューションのコンポーネントは、時間をかけて部品で設計する場合が多くなります。これらの要件は、これを考慮する。具体的には、5.1節では、ベース管理ソリューションの将来の拡張の必要性を論じています。この文書では、望ましい結果に向けたロードマップであることを意図していると、「オール・オア・ナッシング」システムを定義するものではありません。ネームサーバーの成功した相互運用可能な管理は、一部でも、この記事の執筆時点で使用されている、完全にカスタムソリューションに比べてネットワークオペレータに有益であることが期待されています。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document is consistent with the terminology defined in Section 2 of [RFC4033]. Additional terminology needed for this document is described below:
このドキュメントは[RFC4033]のセクション2で定義された用語と一致しています。このドキュメントのために必要な追加の用語は、以下に説明されています。
Name Server: When we are discussing servers that don't fall into a more specific type of server category defined in other documents, this document will refer to them generically as "name servers". In particular, "name servers" can be considered to be any valid combination of authoritative, recursive, validating, or security-aware. The more specific name server labels will be used when this document refers only to a specific type of server. However, the term "name server", in this document, will not include stub resolvers.
ネームサーバ：我々は他のドキュメントで定義されたサーバーカテゴリのより具体的な種類に分類されないサーバを議論している場合は、この文書は、「ネームサーバ」として包括的にそれらを参照します。具体的には、「ネームサーバは」権威、再帰的、有効、またはセキュリティ対応の任意の有効な組み合わせであると考えることができます。この文書は唯一のサーバーの特定のタイプを指したときに、より具体的なネームサーバのラベルが使用されます。しかし、用語「ネームサーバー」には、この文書では、スタブリゾルバは含まれません。
This document is written so that each numbered section will contain only a single requirement if it contains one at all. Each requirement will contain needed wording from the terminology described in Section 1.1. Subsections, however, might exist with additional related requirements. The document is laid out in this way so that a specific requirement can be uniquely referred to using the section number itself and the document version from which it came.
それがすべてで1が含まれている場合は、それぞれの番号のセクションは、単一の要件が含まれていますように、本書は書かれています。各要件は、セクション1.1で説明した用語から必要な文言が含まれています。サブセクションは、しかし、追加の関連要件に存在することがあります。特定の要件を一意セクション番号自体、それが来た文書のバージョンを使用して参照できるように、ドキュメントは、このようにレイアウトされます。
This section discusses requirements that reflect the needs of the expected deployment environments.
このセクションでは、予想されるデプロイメント環境のニーズを反映した要件について説明します。
DNS zones vary greatly in the type of content published within them. Name servers, too, are deployed with a wide variety of configurations to support the diversity of the deployed content. It is important that a management solution trying to meet the criteria specified in this document consider supporting the largest number of potential deployment cases as possible. Further deployment scenarios that are not used as direct examples of specific requirements are listed in Appendix A.
DNSゾーンは、その中に公開されたコンテンツの種類に大きく異なります。ネームサーバは、あまりにも、展開されたコンテンツの多様性をサポートするために、多種多様な構成で展開されています。この文書で指定された基準を満たすためにしようとする管理ソリューションは、可能な潜在的な展開例の最大数をサポートする検討することが重要です。特定の要件の直接例として使用されていない他の展開シナリオは、付録Aに記載されています
The management solution MUST support both name servers that are serving a small number of potentially very large zones (e.g., Top Level Domains (TLDs)) as well as name servers that are serving a very large number of small zones. Both deployment scenarios are common.
管理ソリューションは、潜在的に非常に大きなゾーン（例えば、トップレベルドメイン（TLDの））だけでなく、小さな区域の非常に多くを提供しているネームサーバの数が少ないにサービスを提供している、両方のネームサーバをサポートしなければなりません。どちらの展開シナリオが一般的です。
Large enterprise network deployments may contain multiple name servers operating within the boundaries of the enterprise network. These name servers may each be serving multiple zones both in and out of the parent enterprise's zone. Finding and managing large numbers of name servers would be a useful feature of the resulting management solution. The management solution MAY support the ability to discover previously unknown instances of name servers operating within a deployed network.
大規模な企業ネットワークの展開は、企業ネットワークの境界内で動作する複数のネームサーバが含まれていてもよいです。これらのネームサーバは、各親企業のゾーンのうちの両方の複数のゾーンにサービスを提供することができます。ネームサーバを大量に発見し、管理することは、結果として管理ソリューションの便利な機能だろう。管理ソリューションを展開し、ネットワーク内で動作するネームサーバの以前に未知のインスタンスを検出する機能をサポートするかもしれません。
Configuration data is defined as data that relates only to the configuration of a server and the zones it serves. It specifically does not include data from the zone contents that is served through DNS itself. The solution MUST support servers that remain statically configured over time as well as servers that have numerous zones being added and removed within an hour. Both deployment scenarios are common.
コンフィギュレーションデータのみが機能するサーバーとゾーンの構成に関するデータとして定義されます。これは、特にDNS自体を介して提供されるゾーンの内容からデータが含まれていません。解決策は、静的に、時間だけでなく、時間以内に追加および削除された多数のゾーンを持つサーバー上で構成されたままのサーバをサポートしなければなりません。どちらの展開シナリオが一般的です。
There are many requirements in this document for many different types of management operations (see Section 3 for further details). It is possible that no one protocol will ideally fill all the needs of the requirements listed in this document, and thus multiple protocols might be needed to produce a completely functional management system. Multiple protocols might be used to create the complete management solution, but the solution SHOULD require only one.
管理操作の多くの異なる種類（詳細については、セクション3を参照）については、この文書には多くの要件があります。誰のプロトコルは、理想的には、この文書に記載されている要件のすべてのニーズを満たしていないだろうことは可能であるため、複数のプロトコルは、完全に機能的な管理システムを生産するために必要になる場合があります。複数のプロトコルは、完全な管理ソリューションを作成するために使用されるかもしれませんが、解決策は一つだけを要求する必要があります。
Defining a standardized protocol (or set of protocols) to use for managing name servers would be a step forward in achieving an interoperable management solution. However, just defining a protocol to use by itself would not achieve the entire end goal of a complete interoperable management solution. Devices also need to represent their internal management interface using a common management data model. The solution MUST create a common data model that management stations can make use of when sending or collecting data from a managed device so it can successfully manage equipment from vendors as if they were generic DNS servers. This common data model is needed for the operations discussion in Section 3. Note that this does not preclude the fact that name server vendors might provide additional management infrastructure beyond a base management specification, as discussed further in Section 5.1.
ネームサーバの管理に使用する標準化されたプロトコル（またはプロトコルのセット）を定義することは、相互運用可能な管理ソリューションを達成する上で一歩前進だろう。しかし、単にそれ自体で使用するプロトコルを定義することは、完全な相互運用可能な管理ソリューションの全体の最終目標を達成できないでしょう。デバイスはまた、共通の管理データモデルを使用して、内部管理インターフェイスを表現する必要があります。ソリューションは、管理ステーションが送信または、彼らは汎用的なDNSサーバであるかのように、それが正常にベンダーから機器を管理できるように、管理対象デバイスからデータを収集する際に利用することができ、共通のデータモデルを作成する必要があります。この共通データモデルは、これはセクション5.1でさらに説明したように、ネームサーバのベンダーは、ベースの管理仕様を超えて追加の管理インフラストラクチャを提供するかもしれないという事実を排除するものではないことを第3節注操作の議論のために必要とされています。
It is impossible to add new features to an existing server (such as the inclusion of a management infrastructure) and not impact the existing service and/or server in some fashion. At a minimum, for example, more memory, disk, and/or CPU resources will be required to implement a new management system. However, the impact to the existing DNS service MUST be minimized since the DNS service itself is still the primary service to be offered by the modified name server. The management solution MUST NOT result in an increase of the number of unhandled DNS requests.
（例えば、管理インフラストラクチャを含めるように）既存のサーバに新しい機能を追加し、いくつかの方法で既存のサービス及び/又はサーバに影響を与えないことは不可能です。最低でも、例えば、より多くのメモリ、ディスク、および/またはCPUリソースが新しい管理システムを実装する必要があります。 DNSサービス自体はまだ修正さネームサーバによって提供される主なサービスですので、既存のDNSサービスへの影響は最小限に抑えなければなりません。管理ソリューションは、未処理のDNS要求の数の増加をもたらすならありません。
There are multiple ways in which name servers can be deployed. Name servers can take on any of the following roles:
ネームサーバを展開することができる複数の方法があります。ネームサーバは、次の役割のいずれかを取ることができます。
o Master Servers
Oマスタサーバ
o Slave Servers
Oスレーブサーバ
o Recursive Servers
再帰的なサーバO
The management solution SHOULD support all of these types of name servers as they are all equally important. Note that "Recursive Servers" can be further broken down by the security sub-roles they might implement, as defined in section 2 of [RFC4033]. These sub-roles are also important to support within any management solution.
彼らはすべて等しく重要であるとして管理ソリューションは、ネームサーバのこれらのタイプのすべてをサポートする必要があります。 [RFC4033]のセクション2で定義されるように「再帰的サーバ」はさらに、それらは実装かもしれないセキュリティサブロールによって破壊することができることに留意されたいです。これらのサブの役割はまた、任意の管理ソリューションの中にサポートすることが重要です。
As stated earlier, the management of stub resolvers is considered out of scope for this document.
先に述べたように、スタブリゾルバの管理は、このドキュメントの範囲外と考えられています。
Management operations can traditionally be broken into four categories:
管理操作は、伝統的に4つのカテゴリに分けることができます。
o Control
コントロール
o Configuration o Health and Monitoring
健康とモニタリングO O構成
o Alarms and Events
Oアラームおよびイベント
This section discusses detailed requirements for each of these four management categories.
このセクションでは、これらの4つの管理各カテゴリの詳細な要件について説明します。
The management solution MUST be capable of performing basic service control operations.
管理ソリューションは、基本的なサービス制御動作を行うことができなければなりません。
These operations SHOULD include, at a minimum, the following operations:
これらの操作は、最低限、以下の操作を含める必要があります。
o Starting the name server
Oネームサーバの起動
o Reloading the service configuration
サービスコンフィギュレーションをリロードO
o Reloading all of the zone data
ゾーンデータのすべてをリロードO
o Reloading individual zone data sets
個々のゾーンのデータセットをリロードO
o Restarting the name server
ネームサーバーを再起動O
o Stopping the name server
ネームサーバーを停止するO
Note that no restriction is placed on how the management system implements these operations. In particular, at least "starting the name server" will require a minimal management system component to exist independently of the name server itself.
制限は、管理システムは、これらの操作を実装する方法に配置されていないことに注意してください。具体的には、少なくとも「ネームサーバを起動する」独立ネームサーバ自体の存在する最小管理システムコンポーネントを必要とします。
Some control operations might take a long time to complete. As an example, some name servers take a long time to perform reloads of large zones. Because of these timing issues, the management solution SHOULD take this into consideration and offer a mechanism to ease the burden associated with awaiting the status of a long-running command. This could, for example, result in the use of asynchronous notifications for returning the status of a long-running task, or it might require the management station to poll for the status of a given task using monitoring commands. These and other potential solutions need to be evaluated carefully to select one that balances the result delivery needs with the perceived implementation costs.
いくつかの制御操作が完了するまでに長い時間がかかる場合があります。例として、いくつかのネームサーバは、大ゾーンのリロードを実行するのに長い時間がかかります。そのためこれらのタイミングの問題により、管理ソリューションは、これを考慮すると長時間実行コマンドのステータスを待っているに関連付けられている負担を軽減するためのメカニズムを提供する必要があります。これは、例えば、長時間実行タスクのステータスを返すための非同期通知の使用につながる可能性、またはそれが監視コマンドを使用して、指定されたタスクのステータスをポーリングする管理ステーションが必要になることがあります。これらおよびその他の潜在的な解決策は、知覚実装コストと結果の配信ニーズのバランスをとるものを選択するように慎重に評価する必要があります。
Also, see the related discussion in Section 3.4 on notification messages for supporting delivery of alarm and event messages.
また、アラームおよびイベントメッセージの配信をサポートするための通知メッセージに3.4節で関連する説明を参照してください。
Many features of name servers need to be configured before the server can be considered functional. The management solution MUST be able to provide name servers with configuration data. The most important data to be configured, for example, is the served zone data itself.
ネームサーバの多くの機能は、サーバーが機能して考えることができる前に設定する必要があります。管理ソリューションは、構成データとネームサーバを提供できなければなりません。設定するための最も重要なデータは、例えば、役立ったゾーンデータそのものです。
The ability to add, modify, and delete zones being served by name servers is needed. Although there are already solutions for zone content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], full zone transfer (AXFR) [RFC5936], and incremental zone transfer (IXFR) [RFC1995]) that might be used as part of the final management solution, the management system SHOULD still be able to create a new zone (with enough minimal data to allow the other mechanisms to function as well) and to delete a zone. This might be, for example, a management operation that allows for the creation of at least the initial SOA (Start of Authority) record for a new zone, since that is the minimum amount of zone data needed for the other operations to function.
ネームサーバーが提供してゾーンを追加、変更、および削除する機能が必要とされています。使用されてもよい（例えば、ダイナミックDNS（DDNS）[RFC2136]、[RFC3007]、完全ゾーン転送（AXFR）[RFC5936]、および増分ゾーン転送（IXFR）[RFC1995]など）ゾーンコンテンツ変更のための解決策が既に存在するが最終的な管理ソリューションの一部は、管理システムは、依然として、ゾーンを削除する（他の機構も同様に機能させるのに十分な最小限のデータを含む）は、新しいゾーンを作成することができるべきです。これは、それが機能するために、他の操作に必要なゾーンデータの最小量であることから、新しいゾーンの少なくとも最初のSOA（Start of Authority）レコードを作成できます、例えば、管理操作かもしれません。
The solution SHOULD support the ability to add, modify, and delete trust anchors that are used by DNS Security (DNSSEC) [RFC4033] [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust anchors might be configured using the data from the DNSKEY Resource Records (RRs) themselves or by using Delegation Signer (DS) fingerprints.
解決策は、DNSセキュリティ（DNSSEC）[RFC4033] [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]で使用されているトラストアンカーを追加、変更、および削除する機能をサポートする必要があります。これらの信頼アンカーはDNSKEYリソースレコード（RR）自身からか、委任署名者（DS）指紋を使用してデータを使用して構成されることがあります。
DNSSEC validating resolvers need to make policy decisions about the requests being processed. For example, they need to be configured with a list of zones expected to be secured by DNSSEC. The management solution SHOULD be able to add, modify, and delete attributes of DNSSEC security policies.
DNSSECの検証リゾルバが処理されている要求に関する政策決定を行う必要があります。例えば、彼らはDNSSECで保護されることが予想ゾーンのリストを使用して設定する必要があります。管理ソリューションは、DNSSECのセキュリティポリシーの属性を追加、変更、および削除することができるべきです。
TSIG [RFC2845] allows transaction-level authentication of DNS traffic. The management solution SHOULD be able to add, modify, and delete TSIG keys known to the name server.
TSIG [RFC2845]はDNSトラフィックのトランザクション・レベルの認証を行うことができます。管理ソリューションは、ネームサーバに知られているTSIGキーを追加、変更、および削除することができるべきです。
The management solution SHOULD have the ability to add, modify, and delete authorization settings for the DNS protocols itself. Do not confuse this with the ability to manage the authorization associated with the management protocol itself, which is discussed later in Section 4.4. There are a number of authorization settings that are used by a name server. Example authorization settings that the solution might need to cover are:
管理ソリューションは、DNSプロトコル自体の認可の設定を追加、変更、および削除する能力を有するべきです。 4.4節の後半で説明されている管理プロトコル自体、関連付けられた許可を管理する能力とこれを混同しないでください。ネームサーバによって使用されている認証の設定がいくつかあります。解決策がカバーする必要があるかもしれません例権限設定は次のとおりです。
o Access to operations on zone data (e.g., DDNS)
ゾーンデータの操作に対するOのアクセス（例えば、DDNS）
o Access to certain zone data from certain sources (e.g., from particular network subnets)
（特定のネットワークサブネットから例えば、）特定のソースからの特定のゾーンデータにOアクセス
o Access to specific DNS protocol services (e.g., recursive service)
特定のDNSプロトコルのサービス（例えば、再帰的なサービス）に対するOアクセス
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
注意：上記のリストは例のコレクションとして使用されることを期待し、必要な承認の保護の完全なリストではありません。
Monitoring is the process of collecting aspects of the internal state of a name server at a given moment in time. The solution MUST be able to monitor the health of a name server to determine its operational status, load, and other internal attributes. Example parameters that the solution might need to collect and analyze are:
モニタリングは、時間内に与えられた瞬間に、ネームサーバの内部状態の側面を収集するプロセスです。解決策は、その動作状態、負荷、およびその他の内部属性を決定するために、ネームサーバの状態を監視することができなければなりません。解決策は、収集して分析する必要があるかもしれません例のパラメータは次のとおりです。
o Number of requests sent, responses sent, number of errors, average response latency, and other performance counters
送信された要求のO数、送信された応答、エラー、平均応答遅延、およびその他のパフォーマンスカウンタの数
o Server status (e.g., "serving data", "starting up", "shutting down", etc.)
Oサーバのステータス（例えば、等、「シャットダウン」、「起動」、「データを配信」）
o Access control violations
Oアクセス制御違反
o List of zones being served
サービスを受けているゾーンのO一覧
o Detailed statistics about clients interacting with the name server (e.g., top 10 clients requesting data).
ネームサーバ（例えば、トップ10のクライアントが要求するデータ）と相互作用するクライアントに関するO詳細統計。
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed monitoring operations. In particular, some monitoring statistics are expected to be computationally or resource expensive and are considered to be "nice to have" as opposed to "necessary to have".
注：上記のリストは、例のコレクションとして使用されることを期待して必要な監視操作の完全なリストではありません。特に、いくつかのモニタリング統計情報は、高価な、計算またはリソースであることが予想されると「持っていることが必要」とは対照的に「あると便利」と考えられています。
Events occurring at the name server that trigger alarm notifications can quickly inform a management station about critical issues. A management solution SHOULD include support for delivery of alarm conditions.
アラーム通知をトリガーするネームサーバで発生するイベントは、すぐに重要な問題については、管理ステーションに知らせることができます。管理ソリューションは、アラーム条件を送達するためのサポートを含むべきです。
Example alarm conditions might include:
例アラーム条件が含まれる場合があります。
o The server's status is changing (e.g., it is starting up, reloading configuration, restarting or shutting down).
サーバーのステータスが変化しているO（例えば、それは、コンフィギュレーションをリロード再起動やシャットダウン、起動しています）。
o A needed resource (e.g., memory or disk space) is exhausted or nearing exhaustion.
必要なリソース（例えば、メモリまたはディスク空間）O枯渇または枯渇に近づいています。
o An authorization violation was detected.
Oの許可違反が検出されました。
o The server has not received any data traffic (e.g., DNS requests or NOTIFYs) recently (aka the "lonely warning"). This condition might indicate a problem with the server's deployment.
Oサーバは、（「孤独の警告」別名）最近、任意のデータトラフィック（例えば、DNS要求またはNOTIFYを）を受信していません。この状態は、サーバーの配備に問題があることを示している可能性があります。
o The number of errors has exceeded a configured threshold.
Oエラーの数が設定されたしきい値を超えています。
The management solution will need to be appropriately secured against attacks on the management infrastructure.
管理ソリューションは、適切に管理インフラストラクチャへの攻撃から保護する必要があります。
The solution MUST support mutual authentication. The management client needs to be assured that the management operations are being transferred to and from the correct name server. The managed name server needs to authenticate the system that is accessing the management infrastructure within itself.
解決策は、相互認証をサポートしなければなりません。管理クライアントは、管理操作をすると、正しいネームサーバから転送されていることを保証する必要があります。管理ネームサーバは、自身の内部管理インフラストラクチャにアクセスしているシステムを認証する必要があります。
Management operations MUST be protected from modification while in transit from the management client to the server.
管理操作は、しばらく、サーバーへの管理クライアントからのトランジットで変更から保護されなければなりません。
The management solution MUST support message confidentiality. The potential transfer of sensitive configuration is expected (such as TSIG keys or security policies). The solution does not, however, necessarily need to provide confidentiality to data that would normally be carried without confidentiality by the DNS system itself.
管理ソリューションは、メッセージの機密性をサポートしなければなりません。敏感な構成の電位転送は（例えばTSIGキーやセキュリティポリシーなど）が期待されます。解決策は、しかし、必ずしも通常はDNSシステム自体で機密性なしに運ばれることになるデータに機密性を提供する必要はありません。
The solution SHOULD provide an authorization model capable of selectively authorizing individual management requests for any management protocols it introduces to the completed system. This authorization differs from the authorization previously discussed in Section 3.2.5 in that this requirement is concerned solely with authorization of the management system itself.
解決策は、選択的に、それが完成したシステムに紹介するすべての管理プロトコルのための個別の管理要求を承認できる承認モデルを提供する必要があります。この権限は、以前、この要件は、単に管理システム自体の権限を持つ関係しているという点で、3.2.5項で述べた認証とは異なります。
There are a number of authorization settings that might be used by a managed system to determine whether the managing entity has authorization to perform the given management task. Example authorization settings that the solution might need to cover are:
管理エンティティは、与えられた管理タスクを実行する権限を持っているかどうかを判断するために、管理システムによって使用される可能性のある認証の設定がいくつかあります。解決策がカバーする必要があるかもしれません例権限設定は次のとおりです。
o Access to the configuration that specifies which zones are to be served
提供されるべき区域指定する構成にOアクセス
o Access to the management system infrastructure
管理システムインフラストラクチャへのOアクセス
o Access to other control operations
他の制御操作へのOアクセス
o Access to other configuration operations
他の構成操作にOアクセス
o Access to monitoring operations
監視業務へのOアクセス
Note: the above list is expected to be used as a collection of examples and is not a complete list of needed authorization protections.
注意：上記のリストは例のコレクションとして使用されることを期待し、必要な承認の保護の完全なリストではありません。
The solution MUST minimize the security risks introduced to the complete name server system. It is impossible to add new infrastructure to a server and not impact the security in some fashion as the introduction of a management protocol alone will provide a new avenue for potential attack. Although the added management benefits will be worth the increased risks, the solution still needs to minimize this impact as much as possible.
ソリューションは、完全な名前のサーバー・システムへの導入、セキュリティ上のリスクを最小限に抑える必要があります。サーバーへの新しいインフラストラクチャを追加して、潜在的な攻撃のための新しい道を提供しますのみ管理プロトコルの導入として、いくつかの方法でセキュリティに影響を与えないようにすることは不可能です。追加した管理上の利点がリスク増加価値があるだろうが、解決策は可能な限り、この影響を最小限にする必要があります。
The management solution is expected to change and expand over time as lessons are learned and new DNS features are deployed. Thus, the solution MUST be flexible and able to accommodate new future management operations. The solution might, for example, make use of protocol versioning or capability description exchanges to ensure that management stations and name servers that weren't written to the same specification version can still interoperate to the best of their combined ability.
管理ソリューションは、教訓を学んでいると、新しいDNS機能が展開されているように時間とともに変化し、拡大することが予想されます。したがって、溶液は、柔軟で新しい将来の管理操作に対応できなければなりません。解決策は、例えば、同じ仕様のバージョンに書き込まれていなかった管理ステーションとネームサーバは、まだ彼らの組み合わせの能力を最大限に相互運用できることを保証するために、プロトコルのバージョン管理や機能説明の交換を利用するかもしれません。
It MUST be possible for vendors to extend the standardized management model with vendor-specific extensions to support additional features offered by their products.
ベンダーが自社製品で提供される追加機能をサポートするために、ベンダー固有の拡張子を持つ標準化された管理モデルを拡張することが可能でなければなりません。
It MUST be possible for a management station to understand which parts of returned data are specific to a given vendor or other standardized extension. The data returned needs to be appropriately marked, through the use of name spaces or similar mechanisms, to ensure that the base management model data can be logically separated from the extension data without needing to understand the extension data itself.
管理ステーションは、返されたデータの部分は、所与のベンダー又は他の標準化された伸長に対して特異的であるかを理解することが可能でなければなりません。データは、データベース管理モデルデータは、論理的に拡張データそのものを理解することなく、拡張データから分離することができることを確実にするために、名前空間、または同様の機構を使用することによって、適切にマークされる必要が返されます。
It MUST be possible to protect against multiple extensions conflicting with each other. The use of name-space protection mechanisms for communicated management variables is common practice to protect against such problems. Name-space identification techniques also frequently solve the "Extension Identification" requirement discussed in Section 5.1.2.
お互いに矛盾する複数の内線番号に対して保護することが可能でなければなりません。通信管理変数の名前空間の保護メカニズムの使用は、このような問題から保護するのが一般的です。名前空間識別技術はまた、しばしば、セクション5.1.2で説明した「拡張識別」要件を解決します。
Any management protocol for which conformance to this document is claimed needs to fully support the criteria discussed in Section 4 in order to protect the management infrastructure itself. The DNS is a core Internet service, and management traffic that protects it could be the target of attacks designed to subvert that service. Because the management infrastructure will be adding additional interfaces to that service, it is critical that the management infrastructure support adequate protections against network attacks.
この文書への適合が主張されている任意の管理プロトコルは、完全に管理インフラストラクチャ自体を保護するために、第4節で述べた基準をサポートする必要があります。 DNSは、コアインターネットサービス、それがそのサービスを破壊するために設計された攻撃の標的となりうる保護管理トラフィックです。管理インフラストラクチャは、そのサービスに追加のインタフェースを追加していく予定ですので、それはネットワーク攻撃に対する管理インフラストラクチャのサポートに十分な保護することが重要です。
A requirement-gathering discussion was held at the December 2007 IETF meeting in Vancouver, BC, Canada, and a follow-up meeting was held at the March 2008 IETF meeting in Philadelphia. This document is a compilation of the results of those discussions as well as discussions on the DCOMA mailing list.
要件収集の議論は、バンクーバー、BC、カナダで2007年12月IETFミーティングで開催された、とフォローアップ会議がフィラデルフィア2008年3月IETF会議で開催されました。この文書では、それらの議論の結果をまとめただけでなく、DCOMAのメーリングリストでの議論です。
This document is the result of discussions within the DCOMA design team chaired by Jaap Akkerhuis. This team consisted of a large number of people, all of whom provided valuable insight and input into the discussions surrounding name server management. The text of this document was written from notes taken during meetings as well as from contributions sent to the DCOMA mailing list. This work documents the consensus of the DCOMA design team.
この文書では、ヤープAkkerhuisが議長を務めるDCOMAデザインチーム内での議論の結果です。このチームは、ネームサーバの管理を取り巻く議論に貴重な洞察や入力を提供し、すべての人の人々の数が多い、で構成されていました。この文書のテキストは、会議中などDCOMAメーリングリストに送られた寄付から取られたノートから書かれていました。この作品はDCOMAデザインチームの合意を文書化します。
In particular, the following team members contributed significantly to the text in the document:
具体的には、以下のチームのメンバーは、文書内のテキストに大きく貢献しました。
Stephane Bortzmeyer Stephen Morris Phil Regnauld
ステファンBortzmeyerスティーブン・モリスフィルRegnauld
Further editing contributions and wording suggestions were made by Alfred Hoenes and Doug Barton.
また、編集の貢献と文言の提案はアルフレッドHoenesとダグ・バートンによって作られました。
[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月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田、M.、 "DNSにおける増分ゾーン転送"、RFC 1995、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.バウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509] Hardaker、W.、RFC 4509、2006年5月 "DNSSEC委任署名者（DS）リソースレコード（RR）でSHA-256の使用"。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.
[RFC5011] StJohns、M.、 "DNSセキュリティ（DNSSEC）トラストアンカーの自動更新"、RFC 5011、2007年9月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]ローリー、B.、シッソン、G.、アレンズ、R.、およびD. Blacka、 "DNSセキュリティ（DNSSEC）存在のハッシュ認証拒否"、RFC 5155、2008年3月。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010.
[RFC5936]ルイス、E.およびA. Hoenes、エド。、 "DNSゾーン転送プロトコル（AXFR）"、RFC 5936、2010年6月。
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", RFC 1611, May 1994.
[RFC1611] Austeinと、R.とJ. Saperia、 "DNSサーバーのMIB拡張機能"、RFC 1611、1994年5月。
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994.
[RFC1612] Austeinと、R.とJ. Saperia、 "DNSリゾルバMIB拡張機能"、RFC 1612、1994年5月。
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[RFC2182]エルツ、R.、ブッシュ、R.、ブラドナーの、S.、およびM.パットン、 "選択とセカンダリDNSサーバーの運用"、BCP 16、RFC 2182、1997年7月。
[RFC3197] Austein, R., "Applicability Statement for DNS MIB Extensions", RFC 3197, November 2001.
[RFC3197] Austeinと、R.、 "DNS MIB拡張のための適用性に関する声明"、RFC 3197、2001年11月。
Appendix A. Deployment Scenarios
付録A.展開シナリオ
This appendix documents some additional deployment scenarios that have been traditionally difficult to manage. They are provided as guidance to protocol developers as data points of real-world name server management problems.
この付録では、管理が伝統的に困難であったいくつかの追加の展開シナリオについて説明します。彼らは現実世界のネームサーバ管理の問題のデータポイントなどのプロトコルの開発者への手引きとして提供されています。
A.1. Non-Standard Zones
A.1。非標準ゾーン
If an organization uses non-standard zones (for example a purely local TLD), synchronizing all the name servers for these zones is usually a time-consuming task. It is made worse when two organizations with conflicting zones merge. This situation is not a recommended deployment scenario (and is even heavily discouraged), but it is, unfortunately, seen in the wild.
組織は非標準ゾーン（例えば、純粋にローカルTLD）を使用している場合、これらのゾーンのすべてのネームサーバを同期することは、通常、時間のかかる作業です。競合のゾーンを持つ2つの組織が合併するときには悪化しています。この状況は、推奨の展開シナリオではありません（とさえ大きく落胆される）が、それは、残念ながら、野生で見られています。
It is typically implemented using "forwarding" zones. But there is no way to ensure automatically that all the resolvers have the same set of zones to forward at any given time. New zones might be added to a local forwarding recursive server, for example, without modifying the rest of the deployed forwarding servers. It is hoped that a management solution that could handle the configuration of zone forwarding would finally allow management of servers deployed in this fashion.
それは、典型的には、「転送」ゾーンを使用して実装されます。しかし、すべてのリゾルバは、任意の時点で転送するためのゾーンの同じセットを持っていることを自動的に確保するための方法はありません。新しいゾーンが展開され、転送サーバの残りの部分を修正することなく、例えば、ローカルフォワーディング再帰的なサーバーに追加される可能性があります。ゾーン転送の設定を処理できる管理ソリューションは、最終的には、このように展開されたサーバーの管理を可能にすることが期待されています。
A.2. Redundancy Sharing
A.2。冗長性の共有
For reliability reasons, it is recommended that zone operators follow the guidelines documented in [RFC2182], which recommends that multiple name servers be configured for each zone and that the name servers be separated both physically and via connectivity routes. A common solution is to establish DNS-serving partnerships: "I'll host your zones and you'll host mine". Both entities benefit from increased DNS reliability via the wider service distribution. This frequently occurs between cooperating but otherwise unrelated entities (such as between two distinct companies) as well as between affiliated organizations (such as between branch offices within a single company).
信頼性の理由から、そのゾーンオペレータが複数のネームサーバがゾーンごとに、ネームサーバが物理的にも接続経路を介して分離するように構成することをお勧めします[RFC2182]に記載のガイドラインに従うことをお勧めします。一般的な解決策はDNSサービングパートナーシップを確立することである：「私はあなたのゾーンをホストするだろうし、あなたは私をホストしますよ」。両方のエンティティは、より広いサービス配信を経由して増加したDNSの信頼性の恩恵を受ける。これは、頻繁に協力するが、それ以外（例えば二つの異なる企業間など）無関係な実体としてだけでなく、（例えば、単一企業内の支店間など）傘下団体の間に発生します。
The configuration of these relationships are currently required to be manually configured and maintained. Changes to the list of zones that are cross-hosted are manually negotiated between the cooperating network administrators and configured by hand. A management protocol with the ability to provide selective authorization, as discussed in Section 4.4, would solve many of the management difficulties between cooperating organizations.
これらの関係の設定は、現在手動で設定し、維持する必要があります。クロスホストされているゾーンのリストへの変更を手動で協働するネットワーク管理者との間でネゴシエートされ、手で構成されています。選択的認証を提供する能力を持つ管理プロトコルは、4.4節で述べたように、協力組織間管理の困難の多くを解決するだろう。
A.3. DNSSEC Management
A.3。 DNSSECの管理
There are many different DNSSEC deployment strategies that may be used for mission-critical zones. The following list describes some example deployment scenarios that might warrant different management strategies.
ミッションクリティカルゾーンのために使用することができる多くの異なったDNSSECの展開戦略があります。以下のリストは、さまざまな経営戦略を正当かもしれないいくつかの例の展開シナリオについて説明します。
All contents and DNSSEC keying information controlled and operated by a single organization
単一の組織によって制御され、運営のすべての内容やDNSSECキーイング情報
Zone contents controlled and operated by one organization, all DNSSEC keying information controlled and operated by a second organization.
ゾーン内容制御と1つの団体が運営には、すべてのDNSSEC鍵の情報が制御され、第二の組織が運営します。
Zone contents controlled and operated by one organization, zone signing keys (ZSKs) controlled and operated by a second organization, and key signing keys (KSKs) controlled and operated by a third organization.
ゾーンの内容は、一の組織、ゾーン署名鍵（ZSKs）第二の組織によって制御され、操作、及び鍵署名鍵（KSKs）第三の組織によって制御され、操作によって制御され、操作します。
Although this list is not exhaustive in the potential ways that zone data can be divided up, it should be sufficient to illustrate the potential ways in which zone data can be controlled by multiple entities.
このリストは、ゾーンデータを分割することができます潜在的な方法で網羅しているわけではないが、ゾーンデータは、複数のエンティティによって制御することができる潜在的な方法を説明するのに十分であるべきです。
The end result of all of these strategies, however, will be the same: a live zone containing DNSSEC-related resource records. Many of the above strategies are merely different ways of preparing a zone for serving. A management solution that includes support for managing DNSSEC zone data may wish to take into account these potential management scenarios.
DNSSEC関連のリソースレコードを含むライブゾーン：これらの戦略のすべての最終結果は、しかし、同じになります。上記の戦略の多くは、サービス提供のためのゾーンを準備するだけで、さまざまな方法があります。 DNSSECゾーンデータを管理するためのサポートが含ま管理ソリューションは、アカウントにこれらの潜在的な管理シナリオを取ることを望むかもしれません。
Author's Address
著者のアドレス
Wes Hardaker Sparta, Inc. P.O. Box 382 Davis, CA 95617 US
ウェスHardakerスパルタ、株式会社私書箱382デイビス、CA 95617米国箱
Phone: +1 530 792 1913 EMail: ietf@hardakers.net
電話：+1 530 792 1913 Eメール：ietf@hardakers.net