RFC4074 日本語訳

Network Working Group                                       Y. Morishita
Request for Comments: 4074                                          JPRS
Category: Informational                                        T. Jinmei
                                                                 Toshiba
                                                                May 2005

コメントを求めるワーキンググループY.森下の要求をネットワークでつないでください: 4074年のJPRSカテゴリ: 情報のT.Jinmei東芝2005年5月

       Common Misbehavior Against DNS Queries for IPv6 Addresses

IPv6アドレスのためのDNS質問に対する一般的な不正行為

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   There is some known misbehavior of DNS authoritative servers when
   they are queried for AAAA resource records.  Such behavior can block
   IPv4 communication that should actually be available, cause a
   significant delay in name resolution, or even make a denial of
   service attack.  This memo describes details of known cases and
   discusses their effects.

それらがAAAAリソース記録のために質問されるとき、DNSの正式のサーバの何らかの知られている不正行為があります。 そのような振舞いは、実際に利用可能であるべきIPv4コミュニケーションを妨げるか、名前解決の重要な遅れを引き起こすか、またはサービス不能攻撃をすることさえできます。 このメモは、知られているケースの細部について説明して、それらの効果について検討します。

1.  Introduction

1. 序論

   Many existing DNS clients (resolvers) that support IPv6 first search
   for AAAA Resource Records (RRs) of a target host name, and then for A
   RRs of the same name.  This fallback mechanism is based on the DNS
   specifications, which if not obeyed by authoritative servers, can
   produce unpleasant results.  In some cases, for example, a web
   browser fails to connect to a web server it could otherwise reach.
   In the following sections, this memo describes some typical cases of
   such misbehavior and its (bad) effects.

IPv6をサポートする多くの既存のDNSクライアント(レゾルバ)が最初に、目標ホスト名のAAAA Resource Records(RRs)、およびそして、同じ名前のA RRsを探します。 この後退メカニズムがDNS仕様に基づいていて、そうでなければ、正式のサーバによって従われて、どれが、不快な結果を生むことができますか? いくつかの場合、例えば、ウェブブラウザはそうでなければそれが達することができたウェブサーバーに接続しません。 以下のセクションで、このメモはそのような不正行為のいくつかの典型的なケースとその(悪い)の効果について説明します。

   Note that the misbehavior is not specific to AAAA RRs.  In fact, all
   known examples also apply to the cases of queries for MX, NS, and SOA
   RRs.  The authors believe this can be generalized for all types of
   queries other than those for A RRs.  In this memo, however, we
   concentrate on the case for AAAA queries, since the problem is
   particularly severe for resolvers that support IPv6, which thus
   affects many end users.  Resolvers at end users normally send A
   and/or AAAA queries only, so the problem for the other cases is
   relatively minor.

不正行為がAAAA RRsに特定でないことに注意してください。 事実上、また、すべての知られている例がMX、NS、およびSOA RRsのために質問に関するケースに適用されます。 作者は、A RRsのためのそれら以外のすべてのタイプの質問のためにこれを一般化できると信じています。 しかしながら、このメモでは、私たちはAAAA質問のためにケースに集中します、その結果多くのエンドユーザに影響するIPv6をサポートするレゾルバには、問題が特に厳しいので。 エンドユーザのレゾルバが通常A、そして/または、AAAAに質問だけを送るので、他のケースのための問題は比較的小さい方です。

Morishita & Jinmei           Informational                      [Page 1]

RFC 4074         Common Misbehavior Against DNS Queries         May 2005

DNSに対する森下とJinmeiの情報[1ページ]のRFC4074の一般的な不正行為は2005年5月について質問します。

2.  Network Model

2. ネットワークモデル

   In this memo, we assume a typical network model of name resolution
   environment using DNS.  It consists of three components: stub
   resolvers, caching servers, and authoritative servers.  A stub
   resolver issues a recursive query to a caching server, which then
   handles the entire name resolution procedure recursively.  The
   caching server caches the result of the query and sends the result to
   the stub resolver.  The authoritative servers respond to queries for
   names for which they have the authority, normally in a non-recursive
   manner.

このメモでは、私たちは、DNSを使用することで名前解決環境の典型的なネットワークモデルを思います。 それは3つのコンポーネントから成ります: サーバ、および正式のサーバをキャッシュして、レゾルバを引き抜いてください。 スタッブレゾルバはキャッシュサーバに反復クエリーを発行します。(次に、それは、全体の名前解決手順を再帰的に扱います)。 キャッシュサーバは、質問の結果をキャッシュして、スタッブレゾルバに結果を送ります。正式のサーバはそれらには権威がある名前のための質問に反応します、通常非再帰的な方法で。

3.  Expected Behavior

3. 予想された振舞い

   Suppose that an authoritative server has an A RR but has no AAAA RR
   for a host name.  Then, the server should return a response to a
   query for an AAAA RR of the name with the response code (RCODE) being
   0 (indicating no error) and with an empty answer section (see
   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
   there is at least one RR of a different type than AAAA for the
   queried name, and the stub resolver can then look for A RRs.

正式のサーバには、A RRを持っていますが、ホスト名のためのAAAA RRは全くないと仮定してください。 セクション4.3.2と6.2を見てください。次に、サーバが0(誤りを全く示さない)である応答コード(RCODE)と空の答え部の名前のAAAA RRのために質問への応答を返すべきである、(.4 [1])について。 そのような応答は、異なったタイプの少なくとも1RRが質問された名前のためのAAAAよりあるのを示します、そして、次に、スタッブレゾルバはA RRsを探すことができます。

   This way, the caching server can cache the fact that the queried name
   has no AAAA RR (but may have other types of RRs), and thus improve
   the response time to further queries for an AAAA RR of the name.

この道、キャッシュサーバは質問された名前にはAAAA RR(しかし、RRsの他のタイプがあるかもしれない)が全くないという事実をキャッシュして、その結果、名前のAAAA RRのために質問を促進するために応答時間を改良できます。

4.  Problematic Behaviors

4. 問題行動

   There are some known cases at authoritative servers that do not
   conform to the expected behavior.  This section describes those
   problematic cases.

予想された振舞いに従わない正式のサーバにはいくつかの知られているケースがあります。 このセクションはそれらの問題の多いケースについて説明します。

4.1.  Ignore Queries for AAAA

4.1. AAAAのために質問を無視してください。

   Some authoritative servers seem to ignore queries for an AAAA RR,
   causing a delay at the stub resolver to fall back to a query for an A
   RR.  This behavior may cause a fatal timeout at the resolver or at
   the application that calls the resolver.  Even if the resolver
   eventually falls back, the result can be an unacceptable delay for
   the application user, especially with interactive applications like
   web browsing.

いくつかの正式のサーバがAAAA RRのために質問を無視するように思えます、スタッブレゾルバの遅れがA RRのために質問へ後ろへ下がることを引き起こして。 この振舞いはレゾルバにおける、または、アプリケーションにおける呼ぶ致命的なタイムアウトにレゾルバを引き起こすかもしれません。レゾルバが結局後ろへ下がっても、結果はアプリケーションユーザにとって、容認できない遅れであるかもしれません、特にウェブ閲覧のような対話型アプリケーションで。

4.2.  Return "Name Error"

4.2. リターン「名前誤り」

   This type of server returns a response with RCODE 3 ("Name Error") to
   a query for an AAAA RR, indicating that it does not have any RRs of
   any type for the queried name.

このタイプのサーバはAAAA RRのためにRCODE3(「名前誤り」)との応答を質問に返します、質問された名前のためのどんなタイプの少しのRRsも持っていないのを示して。

Morishita & Jinmei           Informational                      [Page 2]

RFC 4074         Common Misbehavior Against DNS Queries         May 2005

DNSに対する森下とJinmeiの情報[2ページ]のRFC4074の一般的な不正行為は2005年5月について質問します。

   With this response, the stub resolver may immediately give up and
   never fall back.  Even if the resolver retries with a query for an A
   RR, the negative response for the name has been cached in the caching
   server, and the caching server will simply return the negative
   response.  As a result, the stub resolver considers this to be a
   fatal error in name resolution.

スタッブレゾルバは、この応答と共に、すぐに、あきらめて、決して後ろへ下がらないかもしれません。 レゾルバがA RRのために質問で再試行しても、名前のための否定応答はキャッシュサーバでキャッシュされました、そして、キャッシュサーバは単に否定応答を返すでしょう。 その結果、スタッブレゾルバは、これが名前解決で致命的な誤りであると考えます。

   Several examples of this behavior are known to the authors.  As of
   this writing, all have been fixed.

この振舞いに関するいくつかの例が作者にとって知られています。 この書くこと現在、すべてが修理されました。

4.3.  Return Other Erroneous Codes

4.3. 他の誤ったコードを返してください。

   Other authoritative servers return a response with erroneous response
   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
   Implemented"), indicating that the servers do not support the
   requested type of query.

他の正式のサーバはRCODE3(「名前誤り」)以外の誤った応答コードによる応答を返します。 サーバが要求されたタイプの質問をサポートしないのを示して、そのようなRCODEの1つは4(「実装されない」)です。

   These cases are less harmful than the previous one; if the stub
   resolver falls back to querying for an A RR, the caching server will
   process the query correctly and return an appropriate response.

これらのケースは前のものほど有害ではありません。 スタッブレゾルバがAのためにRRについて質問することへ後ろへ下がると、キャッシュサーバは、正しく質問を処理して、適切な応答を返すでしょう。

   However, these can still cause a serious effect.  There was an
   authoritative server implementation that returned RCODE 2 ("Server
   failure") to queries for AAAA RRs.  One widely deployed mail server
   implementation with a certain type of resolver library interpreted
   this result as an indication of retry and did not fall back to
   queries for A RRs, causing message delivery failure.

しかしながら、これらはまだ重大な効果を引き起こしている場合があります。 AAAA RRsのために、RCODE2(「サーバ失敗」)を質問に返した正式のサーバ実装がありました。 あるタイプのレゾルバライブラリがある1つの広く配布しているメールサーバ実装は、再試行のしるしとしてこの結果を解釈して、A RRsのために質問へ後ろへ下がりませんでした、メッセージ配信障害を引き起こして。

   If the caching server receives a response with these response codes,
   it does not cache the fact that the queried name has no AAAA RR,
   resulting in redundant queries for AAAA RRs in the future.  The
   behavior will waste network bandwidth and increase the load of the
   authoritative server.

キャッシュサーバがこれらの応答コードで応答を受けるなら、質問された名前にはAAAA RRが全くないという事実をキャッシュしません、将来AAAA RRsのための余分な質問をもたらして。 振舞いは、ネットワーク回線容量を浪費して、正式のサーバの負荷を増強するでしょう。

   Using RCODE 1 ("Format error") would cause a similar effect, though
   the authors have not seen such implementations yet.

RCODE1(「形式誤り」)を使用すると、そのような実装は作者によってまだ見られていませんが、同様の効果は引き起こされるでしょう。

4.4.  Return a Broken Response

4.4. 中断した応答を返してください。

   Another type of authoritative servers returns broken responses to
   AAAA queries.  Returning a response whose RR type is AAAA with the
   length of the RDATA being 4 bytes is a known behavior of this
   category.  The 4-byte data looks like the IPv4 address of the queried
   host name.

別のタイプの正式のサーバはAAAA質問への中断した応答を返します。 4バイトであるRDATAの長さでRRタイプがAAAAである応答を返すのは、このカテゴリの知られている振舞いです。 4バイトのデータは質問されたホスト名のIPv4アドレスに似ています。

Morishita & Jinmei           Informational                      [Page 3]

RFC 4074         Common Misbehavior Against DNS Queries         May 2005

DNSに対する森下とJinmeiの情報[3ページ]のRFC4074の一般的な不正行為は2005年5月について質問します。

   That is, the RR in the answer section would be described as follows:

すなわち、答え部のRRは以下の通り説明されるでしょう:

     www.bad.example. 600 IN AAAA 192.0.2.1

www.bad.example。 AAAA192.0.2における600、.1

   which is, of course, bogus (or at least meaningless).

もちろんにせ、そして、(少なくとも無意味。)です。

   A widely deployed caching server implementation transparently returns
   the broken response (and caches it) to the stub resolver.  Another
   known server implementation parses the response by itself, and sends
   a separate response with RCODE 2 ("Server failure").

広く配布しているキャッシュサーバ実装は透過的に中断した応答をスタッブレゾルバに返します(そして、それをキャッシュします)。別の知られているサーバ実装は、RCODE2(「サーバ失敗」)と共にそれ自体で応答を分析して、別々の応答を送ります。

   In either case, the broken response does not affect queries for an A
   RR of the same name.  If the stub resolver falls back to A queries,
   it will get an appropriate response.

どちらの場合ではも、中断した応答は同じ名前のA RRのための質問に影響しません。 スタッブレゾルバがA質問へ後ろへ下がると、それは適切な応答を得るでしょう。

   The latter case, however, causes the same bad effect as that
   described in the previous section: redundant queries for AAAA RRs.

しかしながら、後者のケースは前項のそんなに説明されるのと同じ悪い効果を引き起こします: AAAA RRsのための余分な質問。

4.5.  Make Lame Delegation

4.5. 不十分な委譲を作ってください。

   Some authoritative servers respond to AAAA queries in a way that
   causes lame delegation.  In this case, the parent zone specifies that
   the authoritative server should have the authority of a zone, but the
   server should not return an authoritative response for AAAA queries
   within the zone (i.e., the AA bit in the response is not set).  On
   the other hand, the authoritative server returns an authoritative
   response for A queries.

いくつかの正式のサーバが、原因が委譲を不完全にすると方法でAAAA質問に応答します。 この場合、親ゾーンは、正式のサーバにはゾーンの権威があるべきですが、サーバがゾーンの中のAAAA質問のための正式の応答を返すべきでないと指定します(すなわち、応答におけるAAビットは設定されません)。 他方では、正式のサーバはA質問のための正式の応答を返します。

   When a caching server asks the server for AAAA RRs in the zone, it
   recognizes the delegation is lame, and returns a response with RCODE
   2 ("Server failure") to the stub resolver.

キャッシュサーバがゾーンでサーバにAAAA RRsを求めるとき、それは、RCODE2(「サーバ失敗」)と共にスタッブレゾルバに委譲が不十分であると認めて、応答を返します。

   Furthermore, some caching servers record the authoritative server as
   lame for the zone and will not use it for a certain period of time.
   With this type of caching server, even if the stub resolver falls
   back to querying for an A RR, the caching server will simply return a
   response with RCODE 2, since all the servers are known to be "lame."

その上、いくつかのキャッシュサーバは、ゾーンに、同じくらい不十分な正式のサーバを記録して、ある期間の間、それを使用しないでしょう。 スタッブレゾルバがAのためにRRについて質問することへ後ろへ下がっても、このタイプのキャッシュサーバと共に、キャッシュサーバはRCODE2との応答を単に返すでしょう、すべてのサーバが「不十分であること」が知られているので。

   There is also an implementation that relaxes the behavior a little
   bit.  It tries to avoid using the lame server, but continues to try
   it as a last resort.  With this type of caching server, the stub
   resolver will get a correct response if it falls back after Server
   failure.  However, this still causes redundant AAAA queries, as
   explained in the previous sections.

また、振舞いをほんの少し弛緩する実装があります。 それは、不十分なサーバを使用するのを避けようとしますが、最後の手段としてそれを試み続けています。 このタイプのキャッシュサーバで、Serverの故障の後に後ろへ下がると、スタッブレゾルバは正しい応答を得るでしょう。 しかしながら、これは前項で説明されるようにまだ余分なAAAA質問を引き起こしています。

Morishita & Jinmei           Informational                      [Page 4]

RFC 4074         Common Misbehavior Against DNS Queries         May 2005

DNSに対する森下とJinmeiの情報[4ページ]のRFC4074の一般的な不正行為は2005年5月について質問します。

5.  Security Considerations

5. セキュリティ問題

   The CERT/CC pointed out that the response with RCODE 3 ("Name
   Error"), described in Section 4.2, can be used for a denial of
   service attack [2].  The same argument applies to the case of "lame
   delegation", described in Section 4.5, with a certain type of caching
   server.

CERT/CCは、サービス不能攻撃[2]にセクション4.2で説明されたRCODE3(「名前誤り」)との応答を使用できると指摘しました。 同じ議論はあるタイプのキャッシュサーバでセクション4.5で説明された「不十分な委譲」に関するケースに適用されます。

6.  Acknowledgements

6. 承認

   Erik Nordmark encouraged the authors to publish this document as an
   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
   this document.  Pekka Savola carefully reviewed a previous version
   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
   Thomas Narten, and Alex Zinin reviewed and helped improve the
   document at the last stage for publication.

エリックNordmarkは、作者がRFCとしてこのドキュメントを発表するよう奨励しました。 Akira加藤とポールVixieはこのドキュメントの準備段階を見直しました。 ペッカSavolaは慎重に旧バージョンを見直して、詳細なコメントを提供しました。 ビル・フェナー、スコットHollenbeck、トーマスNarten、およびアレックス・ジニンは、論評して、公表のために最後の段階でドキュメントを改良するのを助けました。

7.  Informative References

7. 有益な参照

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
        AAAA queries could cause denial-of-service conditions",
        March 2003, <http://www.kb.cert.org/vuls/id/714121>.

[2] 「AAAA質問からの不正確なNXDOMAIN応答は運転条件の否定を引き起こす場合があった」CERTコーディネートセンター、2003年3月、<http://www.kb.cert.org/vuls/イド/714121>。

Authors' Addresses

作者のアドレス

   MORISHITA Orange Yasuhiro
   Research and Development Department, Japan Registry Services Co.,Ltd.
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065
   Japan

森下のオレンジのYasuhiro研究開発部、日本登録は株式会社千代田最初のビルディングを調整します。 3-8-1 13Fの東洋、千代田区西-神田、日本東京101-0065

   EMail: yasuhiro@jprs.co.jp

メール: yasuhiro@jprs.co.jp

   JINMEI Tatuya
   Corporate Research & Development Center, Toshiba Corporation
   1 Komukai Toshiba-cho, Saiwai-ku
   Kawasaki-shi, Kanagawa  212-8582
   Japan

JINMEI Tatuyaの法人の研究開発センター、東芝1Komukai東芝町、幸区川崎市、日本神奈川212-8582

   EMail: jinmei@isl.rdc.toshiba.co.jp

メール: jinmei@isl.rdc.toshiba.co.jp

Morishita & Jinmei           Informational                      [Page 5]

RFC 4074         Common Misbehavior Against DNS Queries         May 2005

DNSに対する森下とJinmeiの情報[5ページ]のRFC4074の一般的な不正行為は2005年5月について質問します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

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

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

Morishita & Jinmei           Informational                      [Page 6]

森下とJinmei情報です。[6ページ]