[要約] RFC 6168は、DNSの名前サーバーの管理に関する要件を定義しています。このRFCの目的は、効果的で信頼性の高い名前サーバーの管理を促進することです。
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
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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自体を通じて提供されるゾーンコンテンツのデータは含まれません。ソリューションは、時間の経過とともに静的に構成されたままのサーバーと、1時間以内に多数のゾーンが追加および削除されているサーバーをサポートする必要があります。両方の展開シナリオが一般的です。
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を参照）。このドキュメントに記載されている要件のすべてのニーズを理想的には誰もいないため、完全に機能的な管理システムを生成するために複数のプロトコルが必要になる可能性があります。複数のプロトコルを使用して完全な管理ソリューションを作成する場合がありますが、ソリューションには1つだけが必要です。
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サーバーであるかのように機器を正常に管理できるようにする必要があります。この共通のデータモデルは、セクション3の操作ディスカッションに必要です。これは、セクション5.1でさらに説明するように、基本管理仕様を超えて追加の管理インフラストラクチャを提供する可能性があるという事実を排除しないことに注意してください。
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 コントロール
o Configuration o Health and Monitoring
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（権限の開始）レコードを作成できる管理操作かもしれません。
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リソースレコード（RRS）自体のデータを使用して、または委任署名者（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で後述します。Name Serverで使用される許可設定が多数あります。ソリューションがカバーする必要がある場合の承認設定の例は次のとおりです。
o Access to operations on zone data (e.g., DDNS)
o ゾーンデータの操作へのアクセス（例：DDN）
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)
o 特定のDNSプロトコルサービスへのアクセス（例：再帰サービス）
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).
o 名前サーバーと対話するクライアントに関する詳細な統計（たとえば、データを要求するトップ10のクライアント）。
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リクエストや通知など）を受信していません（別名「孤独な警告」）。この条件は、サーバーの展開に問題を示している可能性があります。
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.
カナダのバンクーバーで開催された2007年12月のIETF会議で要件収集の議論が開催され、2008年3月のフィラデルフィアでのIETF会議でフォローアップ会議が開催されました。このドキュメントは、これらの議論の結果とDOMAメーリングリストに関する議論の編集です。
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.
このドキュメントは、Jaap Akkerhuisが議長を務めるDoma Designチーム内での議論の結果です。このチームは多数の人々で構成されており、全員がName Server管理を取り巻く議論に貴重な洞察と意見を提供しました。このドキュメントのテキストは、会議中に撮影されたメモとDOMAメーリングリストに送信された寄付から書かれました。この作業は、DOMA設計チームのコンセンサスを文書化しています。
In particular, the following team members contributed significantly to the text in the document:
特に、次のチームメンバーは、ドキュメントのテキストに大きく貢献しました。
Stephane Bortzmeyer Stephen Morris Phil Regnauld
Stephane Bortzmeyer Stephen Morris Phil Regnauld
Further editing contributions and wording suggestions were made by Alfred Hoenes and Doug Barton.
さらに編集の貢献と言葉遣いの提案は、Alfred HoenesとDoug Bartonによって行われました。
[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] OHTA、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（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.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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。、「DNSSEC Delogation Signer（DS）Resource Records（RRS）でのSHA-256の使用」、RFC 4509、2006年5月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.
[RFC5011] Stjohns、M。、「DNS Security（DNSSEC）Trust Anchorsの自動更新」、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] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）は認証された存在拒否」、RFC 5155、2008年3月。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010.
[RFC5936] Lewis、E。and A. Hoenes、ed。、「DNS Zone Transfer Protocol（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 Server MIB Extensions」、RFC 1611、1994年5月。
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", RFC 1612, May 1994.
[RFC1612] Austein、R。およびJ. Saperia、「DNS Resolver MIB Extensions」、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] Elz、R.、Bush、R.、Bradner、S。、およびM. Patton、「セカンダリ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月。
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.
この付録には、伝統的に管理が困難であった追加の展開シナリオを文書化しています。これらは、実際の名前のサーバー管理の問題のデータポイントとして、プロトコル開発者へのガイダンスとして提供されています。
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.
通常、「転送」ゾーンを使用して実装されます。しかし、すべてのリゾルバーがいつでも転送するゾーンのセットを持っていることを自動的に確保する方法はありません。たとえば、展開された転送サーバーの残りを変更することなく、ニューヨークがローカル転送の再帰サーバーに追加される可能性があります。ゾーン転送の構成を処理できる管理ソリューションにより、最終的にこの方法で展開されたサーバーの管理が可能になることが期待されています。
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の信頼性の向上から恩恵を受けます。これは、協力しているが無関係なエンティティ（2つの異なる企業間など）と関連組織間（単一の会社内の支店間など）の間で頻繁に発生します。
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で説明したように、選択的な承認を提供する能力を備えた管理プロトコルは、協力組織間の多くの管理上の困難を解決します。
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キーイング情報が2番目の組織によって制御および運用されています。
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.
1つの組織によって制御および運用されたゾーンコンテンツ、ゾーン署名キー（ZSK）は2番目の組織によって制御および運用され、3番目の組織によって制御および運用されているキー署名キー（KSK）が運用されます。
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
Wes Hardaker Sparta、Inc。P.O.Box 382 Davis、CA 95617 US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net