RFC 3425 - Obsoleting IQUERY 日本語訳

URL : https://tools.ietf.org/html/rfc3425
タイトル : RFC 3425 - IQUERYを時代遅れ
翻訳編集 : 自動生成

Network Working Group                                        D. Lawrence
Request for Comments: 3425                                       Nominum
Updates: 1035                                              November 2002
Category: Standards Track

                           Obsoleting IQUERY

Status of this Memo

このメモの位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2002）。全著作権所有。

Abstract

抽象

The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035.

RFC 1035で指定された逆DNSルックアップを実行するIQUERY方法は、一般的に実装されていない、それが実装されている場所を通常運用無効になっています。両方の概念が賢明であったコミュニティの一般的な見解を反映し、ポインタ（PTR）クエリと逆マッピング・レコードを使用しての広く使用されている代替的なアプローチが好ましいこと。したがって、この文書は、それが完全に廃止された宣言し、IQUERY操作を非難します。この文書は、RFC 1035に更新します。

1 - Introduction

1 - はじめに

As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS queries is used to look up the name(s) which are associated with the given value. The value being sought is provided in the query's answer section and the response fills in the question section with one or more 3-tuples of type, name and class.

RFC 1035（セクション6.4）で指定されるように、DNSクエリのIQUERY操作が所定の値に関連付けられている名前をルックアップするために使用されます。求められている値は、クエリの回答セクションで提供されており、応答はタイプ、名前とクラスの一つ以上の3つのタプルで質問セクションに記入します。

As noted in [RFC1035], section 6.4.3, inverse query processing can put quite an arduous burden on a server. A server would need to perform either an exhaustive search of its database or maintain a separate database that is keyed by the values of the primary database. Both of these approaches could strain system resource use, particularly for servers that are authoritative for millions of names.

[RFC1035]、セクション6.4.3で述べたように、逆クエリ処理はサーバー上で、非常に困難な負担をかけることができます。サーバは、そのデータベースの徹底的な検索のいずれかを実行するか、プライマリ・データベースの値によってキーイングされた別個のデータベースを維持する必要があります。これらのアプローチの両方が、特に名前の何百万人に対して権限のあるサーバーに対して、システムリソースの使用を痛めことができます。

Response packets from these megaservers could be exceptionally large, and easily run into megabyte sizes. For example, using IQUERY to find every domain that is delegated to one of the nameservers of a large ISP could return tens of thousands of 3-tuples in the question section. This could easily be used to launch denial of service attacks.

これらmegaserversからの応答パケットが非常に大きくなり、かつ、容易メガバイトのサイズに実行することができます。たとえば、大規模なISPのネームサーバの一つに委任されているすべてのドメインを検索するためにIQUERYを使用すると、数十質問セクションでの3タプルの何千ものを返すことができます。これは、簡単にサービス拒否攻撃を起動するために使用することができます。

Operators of servers that do support IQUERY in some form (such as very old BIND 4 servers) generally opt to disable it. This is largely due to bugs in insufficiently-exercised code, or concerns about exposure of large blocks of names in their zones by probes such as inverse MX queries.

（そのような非常に古いBIND 4台のサーバなど）何らかの形でIQUERYをサポートしていないサーバーのオペレータは、一般的に、それを無効にすることを選びます。これは、不十分な行使コードのバグ、または、そのような逆MXクエリなどのプローブによるそのゾーン内の名前の大きなブロックの暴露の懸念によるところが大きいです。

IQUERY is also somewhat inherently crippled by being unable to tell a requester where it needs to go to get the information that was requested. The answer is very specific to the single server that was queried. This is sometimes a handy diagnostic tool, but apparently not enough so that server operators like to enable it, or request implementation where it is lacking.

IQUERYもやや本質的に、それは要求された情報を得るために行く必要が依頼者に伝えることができないということで不自由されます。答えは、照会された単一のサーバーに非常に具体的です。これは、サーバーオペレータがそれを可能にするようなので、時には便利な診断ツールが、どうやら十分ではありませんか、それが欠けている要求の実装。

No known clients use IQUERY to provide any meaningful service. The only common reverse mapping support on the Internet, mapping address records to names, is provided through the use of pointer (PTR) records in the in-addr.arpa tree and has served the community well for many years.

既知のクライアントは、意味のあるサービスを提供するためにIQUERYを使用していません。インターネット上の唯一の共通逆マッピングのサポートに、マッピングアドレスレコード名に、in-addr.arpaツリー内のポインタ（PTR）レコードを使用して提供されており、長年にわたってうまくコミュニティを務めています。

Based on all of these factors, this document recommends that the IQUERY operation for DNS servers be officially obsoleted.

これらの要因のすべてに基づいて、この文書は、DNSサーバーのIQUERY操作が正式に廃止されることをお勧めします。

2 - Requirements

2 - 要求事項

The key word "SHOULD" in this document is to be interpreted as described in BCP 14, RFC 2119, namely that there may exist valid reasons to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

キーワードは「SHOULD」本書でBCP 14、RFC 2119に記載されるように、すなわち、特定の項目を無視する正当な理由が存在し得ることが、完全な意味合いが異なるコースを選択する前に理解し、慎重に検討しなければならないと解釈されるべきです。

3 - Effect on

3 - への影響

The effect of this document is to change the definition of opcode 1 from that originally defined in section 4.1.1 of RFC 1035, and to entirely supersede section 6.4 (including subsections) of RFC 1035.

この文書の効果は、もともとRFC 1035のセクション4.1.1で定義されたものからオペコード1の定義を変更すること、及び完全（サブセクションを含む）のセクション6.4に取って代わるためにRFC 1035です。

The definition of opcode 1 is hereby changed to:

オペコード1の定義は、ここに変更されます。

"1 an inverse query (IQUERY) (obsolete)"

"1逆クエリ（IQUERY）（廃止）"

The text in section 6.4 of RFC 1035 is now considered obsolete. The following is an applicability statement regarding the IQUERY opcode:

RFC 1035のセクション6.4のテキストは、現在時代遅れと考えられています。以下は、IQUERYオペコードに関する適用性の文です：

Inverse queries using the IQUERY opcode were originally described as the ability to look up the names that are associated with a particular Resource Record (RR). Their implementation was optional and never achieved widespread use. Therefore IQUERY is now obsolete, and name servers SHOULD return a "Not Implemented" error when an IQUERY request is received.

IQUERYオペコードを使用して逆問合せは、もともと特定のリソースレコード（RR）に関連付けられている名前を検索する機能として説明しました。彼らの実装はオプションだったと広範な使用を達成したことがありません。したがって、IQUERYは廃止され、IQUERY要求を受信したときに、ネームサーバは「実装されていません」エラーを返すべきです。

4 - Security Considerations

4 - セキュリティの考慮事項

Since this document obsoletes an operation that was once available, it is conceivable that someone was using it as the basis of a security policy. However, since the most logical course for such a policy to take in the face of a lack of positive response from a server is to deny authentication/authorization, it is highly unlikely that removing support for IQUERY will open any new security holes.

この文書は一度利用可能であった操作を廃止するので、誰かがセキュリティポリシーの基礎としてそれを使用していたと考えられます。ただし、サーバーからの肯定応答の欠如の顔に取るために、このような政策のための最も論理的なコースは、認証/認可を拒否することであるから、IQUERYのサポートを削除すると、新しいセキュリティホールをオープンする可能性はほとんどありません。

Note that if IQUERY is not obsoleted, securing the responses with DNS Security (DNSSEC) is extremely difficult without out-on-the-fly digital signing.

IQUERYが廃止されていない場合は、DNSセキュリティ（DNSSEC）での応答を確保することがアウト・オン・ザ・フライデジタル署名なしでは極めて困難であることに注意してください。

5 - IANA Considerations

5 - IANAの考慮事項

The IQUERY opcode of 1 should be permanently retired, not to be assigned to any future opcode.

1のIQUERYオペコードは、恒久的に任意の将来のオペコードに割り当てることはしない、引退しなければなりません。

6 - Acknowledgments

6 - 謝辞

Olafur Gudmundsson instigated this action. Matt Crawford, John Klensin, Erik Nordmark and Keith Moore contributed some improved wording in how to handle obsoleting functionality described by an Internet Standard.

オラフルグドムンソンは、このアクションを扇動しました。マット・クロフォード、ジョン・クレンシン、エリックNordmarkとキース・ムーアは、インターネット標準で説明した機能を時代遅れに処理する方法でいくつかの改善文言を貢献しました。

7 - References

7 - 参考文献

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。

[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月。

8 - Author's Address

8 - 著者のアドレス

David C Lawrence Nominum, Inc. 2385 Bay Rd Redwood City CA 94063 USA

デビッド・C・ローレンスノミナム社2385ベイRdのレッドウッドシティーCA 94063 USA

Phone: +1.650.779.6042 EMail: tale@nominum.com

電話：+1.650.779.6042電子メール：tale@nominum.com

9 - Full Copyright Statement

9 - 完全な著作権声明

著作権（C）インターネット協会（2002）。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。