この文書はRFC3425の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
逆ＤＮＳ検索を行うIQUERY方法は、ＲＦＣ１０３５で指定されているが、一
般に実装されず、そして通常実装されていても運用上使用不能でした。これ
は概念が浅はかであるという事と、ポインタ（ＰＴＲ）問合せと逆対応レコー
ドを使う広く使われた代わりの方法が望ましい、という共同体での一般的な
意見を反映します。従って、この文書は、ＩＱＵＥＲＹオペレーションを廃
止し、これが完全に時代遅れであると宣言します。この文書はＲＦＣ１０３５
を更新します。
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.
ＲＦＣ１０３５（６.４章）で指定されるように、ＤＮＳ問合せのＩＱＵＥＲ
Ｙオペレーションは所定の値と結び付けられる名前を検索するために使われ
ます。探されている値は質問の解答部分で供給され、回答は１つ以上のタイ
プと名前とクラスの３項組みで質問部分を記入します。
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]６.４.３章で述べたように、逆質問処理はサーバにまったく困難な
負担を強います。サーバがデータベースの徹底的な探索実行か、主要なデー
タベースの値を鍵にした別のデータベースを保守する必要があるでしょう。
これらのアプローチの両方ともは、特に何百万という名前の正式なサーバで、
システム資源の使用の負担をかけます。
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.
これらのマスターサーバの回答パケットは非常に大きく、そして容易にメガ
バイトサイズになります。例えば、大きいＩＳＰのネームサーバの１つに委
任されるすべてのドメインを見いだすためにＩＱＵＥＲＹを使うことは質問
章は何万という３項組みを返すことができます。これはサービス妨害攻撃に
着手するために容易に使うことができます。
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.
（非常に古いＢＩＮＤ４サーバのような）ある形式でＩＱＵＥＲＹをサポー
トするサーバのオペレータが一般にそれに障害を与えることに決めます。こ
れは、十分検証されていないコードのバグや、そのゾーンでの逆ＭＸ問合せ
のような名前の大きいブロックの危険性の懸念のためです。
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.
ＩＱＵＥＲＹは要求者に求める情報をどこで得られるかを言うことが不可能
であるので、幾分本来的に問題があります。答えは問い合わせられたサーバ
に非常に特有です。これは時々有用な診断の道具ではあるが、サーバーオペ
レータがこれを使えるようにしたり、機能のない実装に導入を求めるには見
たところでは十分です。
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.
既知のクライアントが有意義なサービスを供給するためにＩＱＵＥＲＹを使
いません。唯一のインターネットの上の共通の逆翻訳サポートは、アドレス
レコードを名前に翻訳し、in-addr.arpa木のポインタ（ＰＴＲ）レコードの
使用を通して供給されて、そして何年もの間上手に共同体をサポートしまし
た。
Based on all of these factors, this document recommends that the
IQUERY operation for DNS servers be officially obsoleted.
これらすべての要因に基づいて、この文書はＤＮＳサーバのＩＱＵＥＲＹオ
ペレーションが公式に時代遅れにされることを勧めます。
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」が、ＢＣＰ１４、ＲＦＣ２１１９、すなわ
ち特定の項目を無視する正当な理由が存在するかもしれないが完全な意味が
理解されなくてはならず異なった道を選択する前に慎重に熟慮する、と解釈
されるはずです。
3 - Effect on RFC 1035
3 - RFC １０３５に対する効果
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.
この文書の効果はＲＦＣ１０３５の４.１.１章で定義されて元のオペコード
１の定義を変え、ＲＦＣ１０３５の６.４章を（細別を含めて）完全に置き
換えます。
The definition of opcode 1 is hereby changed to:
オペコード１の定義は以下に変わります：
"1 an inverse query (IQUERY) (obsolete)"
"1 逆質問（ＩＱＵＥＲＹ）（時代遅れ）"
The text in section 6.4 of RFC 1035 is now considered obsolete. The
following is an applicability statement regarding the IQUERY opcode:
ＲＦＣ１０３５の６.４章のテキスト、は今、時代遅れであると思われます。
次のことがＩＱＵＥＲＹオペコードを見つめる適用性宣言です：。
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.
ＩＱＵＥＲＹオペコードを使っている逆質問は、元来、特定の資源レコード
（ＲＲ）と結び付けられる名前を調べる能力だと描写されました。それらの
実装は任意であり、そして決して広範囲にわたる使用を成し遂げませんでし
た。それ故にＩＱＵＥＲＹは今時代遅れで、ネームサーバがＩＱＵＥＲＹ要
求を受信した時、「未実装」エラーを返すべきです(SHOULD)。
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.
この文書がかつて利用可能であったオペレーションを時代遅れにするので、
誰かがそれをセキュリティポリシーの基礎として用いていたことは想像可能
です。しかしながら、サーバーから積極的な回答の欠如に直面た、このよう
なポリシーがとるべき最も論理的な進路は、認証／認可を否定するはずであ
るので、ＩＱＵＥＲＹに対する支持を取り去ることが新しいセキュリティホー
ルを開けることは大いにありそうもありません。
Note that if IQUERY is not obsoleted, securing the responses with DNS
Security (DNSSEC) is extremely difficult without out-on-the-fly
digital signing.
もしＩＱＵＥＲＹが時代遅れにされないなら、ＤＮＳセキュリティ（ＤＮＳ
ＳＥＣ）で回答を確保することは、その場その場でのデジタル署名無しでは
非常に難しいことに注意してください。
5 - IANA Considerations
5 - ＩＡＮＡの考慮
The IQUERY opcode of 1 should be permanently retired, not to be
assigned to any future opcode.
ＩＱＵＥＲＹオペコード１は、将来のオペコードに割当てずに、永久に引退
すべきです。
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.
Olafur Gudmundssonはこの行動を起こさせました。Matt CrawfordとJohn
KlensinとErik NordmarkとKeith Moore はインターネット標準に記述された
機能を時代遅れにすることをそつなくこなす方法でいずれかの改善された言
葉遣いを提供しました。
7 - References
7 - 参考文献
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8 - Author's Address
8 - 著者のアドレス
David C Lawrence
Nominum, Inc.
2385 Bay Rd
Redwood City CA 94063
USA
Phone: +1.650.779.6042
EMail: tale@nominum.com
9 - Full Copyright Statement
9 - 著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。