RFC1535 日本語訳

Network Working Group                                          E. Gavron
Request for Comments: 1535                            ACES Research Inc.
Category: Informational                                     October 1993

Gavronがコメントのために要求するワーキンググループE.をネットワークでつないでください: 1535人のエースが株式会社カテゴリについて研究します: 情報の1993年10月

              A Security Problem and Proposed Correction
                   With Widely Deployed DNS Software

広く配布しているDNSソフトウェアとの警備上の問題と提案された修正

Status of this Memo

このMemoの状態

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

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

Abstract

要約

   This document discusses a flaw in some of the currently distributed
   name resolver clients.  The flaw exposes a security weakness related
   to the search heuristic invoked by these same resolvers when users
   provide a partial domain name, and which is easy to exploit (although
   not by the masses).  This document points out the flaw, a case in
   point, and a solution.

このドキュメントは何人かの現在分配されたネーム・リゾルバクライアントで欠点について議論します。 欠点はユーザが部分的なドメイン名を提供するときこれらの同じレゾルバによって呼び出された利用しやすい検索ヒューリスティックに関連するセキュリティ弱点を暴露します(いずれの大衆でもそうしませんが)。 このドキュメントは欠点、適切なケース、およびソリューションを指摘します。

Background

バックグラウンド

   Current Domain Name Server clients are designed to ease the burden of
   remembering IP dotted quad addresses.  As such they translate human-
   readable names into addresses and other resource records.  Part of
   the translation process includes understanding and dealing with
   hostnames that are not fully qualified domain names (FQDNs).

現在のDomain Name Serverクライアントは、IPが回路アドレスに点を打たせたのを覚えている負担をゆるめるように設計されています。 そういうものとして、彼らはアドレスと他のリソース記録に人間の読み込み可能な名を翻訳します。 翻訳プロセスの一部が、完全修飾ドメイン名(FQDNs)でないホスト名を理解して、対処するのを含んでいます。

   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
   domain name is of the format {name}

絶対「根づいている」FQDNは形式名のものです。 非「根づいている」ドメイン名は形式のものです。名前

   A domain name may have many parts and typically these include the
   host, domain, and type.  Example:  foobar.company.com or
   fooschool.university.edu.

ドメイン名で、多くの部品と通常これらはホスト、ドメイン、およびタイプを含むかもしれません。 例: foobar.company.comかfooschool.university.edu。

Flaw

欠点

   The problem with most widely distributed resolvers based on the BSD
   BIND resolver is that they attempt to resolve a partial name by
   processing a search list of partial domains to be added to portions
   of the specified host name until a DNS record is found.  This
   "feature" is disabled by default in the official BIND 4.9.2 release.

BSD BINDレゾルバに基づくほとんどの広く分配されたレゾルバに関する問題は彼らが、DNS記録が見つけられるまで指定されたホスト名の部分に加えられるために部分的なドメインの検索リストを処理することによって部分的な名前を決議するのを試みるということです。 この「特徴」はデフォルトで.2がリリースする公式のBIND4.9で無効にされます。

   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
                             to    UnivHost.University.EDU

例: UnivHost.University.EDUへの User@Machine.Tech.ACES.COM によるTELNET試み

Gavron                                                          [Page 1]

RFC 1535               DNS Software Enhancements            October 1993

Gavron[1ページ]RFC1535DNSソフトウェア機能強化1993年10月

   The resolver client will realize that since "UnivHost.University.EDU"
   does not end with a ".", it is not an absolute "rooted" FQDN.  It
   will then try the following combinations until a resource record is
   found:

「"UnivHost.University.EDU"がa」で終わらないで、レゾルバクライアントはそれがわかるでしょう。」、それ。絶対的なものが「根づかない」というFQDN。 次に、リソース記録が見つけられるまで、それは以下の組み合わせを試みるでしょう:

                UnivHost.University.EDU.Tech.ACES.COM.
                UnivHost.University.EDU.ACES.COM.
                UnivHost.University.EDU.COM.
                UnivHost.University.EDU.

UnivHost.University.EDU.Tech.ACES.COM。 UnivHost.University.EDU.ACES.COM。 UnivHost.University.EDU.COM。 UnivHost.University.EDU。

Security Issue

安全保障問題

   After registering the EDU.COM domain, it was discovered that an
   unliberal application of one wildcard CNAME record would cause *all*
   connects from any .COM site to any .EDU site to terminate at one
   target machine in the private edu.com sub-domain.

EDU.COMドメインを登録した後に、すべての*がどんな.COMサイトからどんな.EDUサイトまでも接続する*が個人的なedu.comサブドメインの1個のターゲットマシンで1つのワイルドカードCNAME記録の「非-自由主義者」アプリケーションで終わると発見されました。

   Further, discussion reveals that specific hostnames registered in
   this private subdomain, or any similarly named subdomain may be used
   to spoof a host.

さらに、議論が、特定のホスト名がこの個人的なサブドメインに登録されたのを明らかにするか、またはどんな同様に命名されたサブドメインも、ホストを偽造するのに使用されるかもしれません。

        Example:        harvard.edu.com.        CNAME   targethost

例: harvard.edu.com。 CNAME targethost

   Thus all connects to Harvard.edu from all .com sites would end up at
   targthost, a machine which could provide a Harvard.edu login banner.

したがって、すべてがサイトがtargthost(Harvard.eduログインバナーを提供できたマシン)で終わらせるすべての.comからHarvard.eduに接続します。

   This is clearly unacceptable.  Further, it could only be made worse
   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.

これは明確に容認できません。 さらに、それをCOM.EDU、MIL.GOV、GOV.COMなどのようなドメインによって、より悪くすることができただけです。

Public vs. Local Name Space Administration

地方名宇宙政権に対して公共です。

   The specification of the Domain Name System and the software that
   implements it provides an undifferentiated hierarchy which permits
   delegation of administration for subordinate portions of the name
   space.  Actual administration of the name space is divided between
   "public" and "local" portions.  Public administration pertains to all
   top-level domains, such as .COM and .EDU.  For some domains, it also
   pertains to some number of sub-domain levels.  The multi-level nature
   of the public administration is most evident for top-level domains
   for countries.  For example in the Fully Qualified Domain Name,
   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
   of public administration.  Only the left-most portion is subject to
   local administration.

ドメインネームシステムの仕様とそれを実装するソフトウェアはスペースという名前の下位の部分に管理の委譲を可能にする非差別化された階層構造を提供します。 スペースという名前の実際の管理は「公共」の、そして、「地方」の部分の間で分割されます。 公務は.COMや.EDUなどのすべての最上位のドメインに関係します。 また、いくつかのドメインのために、それは何らかの数のサブドメインレベルに関係します。 最上位のドメインに、公務のマルチレベル本質は国に最も明白です。 例えば、Fully Qualified Domain Name、dbc.mtview.ca.usで代表する、部分"mtview.ca.us"は3つのレベルの公務を代表します。 最も左の部分だけが地方行政を受けることがあります。

Gavron                                                          [Page 2]

RFC 1535               DNS Software Enhancements            October 1993

Gavron[2ページ]RFC1535DNSソフトウェア機能強化1993年10月

   The danger of the heuristic search common in current practise is that
   it it is possible to "intercept" the search by matching against an
   unintended value while walking up the search list.  While this is
   potentially dangerous at any level, it is entirely unacceptable when
   the error impacts users outside of a local administration.

電流におけるコモンが練習する発見的な検索の危険は故意でない値に対して合っているのによる検索がゆったり過ごす「インタセプト」ウォーキングに検索リストを上げるというそれが可能であることです。 これはどんなレベルでも潜在的に危険ですが、誤りが地方行政の外にユーザに影響を与えるとき、それは完全に容認できません。

   When attempting to resolve a partial domain name, DNS resolvers use
   the Domain Name of the searching host for deriving the search list.
   Existing DNS resolvers do not distinguish the portion of that name
   which is in the locally administered scope from the part that is
   publically administered.

部分的なドメイン名を決議するのを試みるとき、DNSレゾルバは、検索リストを引き出すのに探すホストのDomain Nameを使用します。 既存のDNSレゾルバは局所的に管理された範囲でpublicallyに管理される部分から来ているその名前の部分を区別しません。

Solution(s)

ソリューション(s)

   At a minimum, DNS resolvers must honor the BOUNDARY between local and
   public administration, by limiting any search lists to locally-
   administered portions of the Domain Name space.  This requires a
   parameter which shows the scope of the name space controlled by the
   local administrator.

最小限では、DNSレゾルバは地方の、そして、公立の管理の間のBOUNDARYを尊敬しなければなりません、どんな検索リストもDomain Nameスペースの局所的に管理された部分に制限することによって。 これはスペースが地元の管理者から制御されたのを名前の範囲に案内するパラメタを必要とします。

   This would permit progressive searches from the most qualified to
   less qualified up through the locally controlled domain, but not
   beyond.

これは、局所的に制御されたドメインを通して最も適切であるのから以下まで資格があった進歩的な検索を可能にしますが、向こうで可能にしないでしょう。

   For example, if the local user were trying to reach:

地元のユーザが例えば達しようとしていたなら:

        User@chief.admin.DESERTU.EDU from
        starburst,astro.DESERTU.EDU,

スターバーストからの User@chief.admin.DESERTU.EDU 、astro.DESERTU.EDU

   it is reasonable to permit the user to enter just chief.admin, and
   for the search to cover:

まさしくchief.adminに入るユーザを可能にして、検索がカバーするのがそれは妥当です:

        chief.admin.astro.DESERTU.EDU
        chief.admin.DESERTU.EDU

chief.admin.astro.DESERTU.EDU chief.admin.DESERTU.EDU

   but not

しかし

        chief.admin.EDU

chief.admin.EDU

   In this case, the value of "search" should be set to "DESERTU.EDU"
   because that's the scope of the name space controlled by the local
   DNS administrator.

それが地元のDNS管理者によって制御された名前スペースの範囲であるので、この場合、「検索」の値は"DESERTU.EDU"に設定されるべきです。

   This is more than a mere optimization hack.  The local administrator
   has control over the assignment of names within the locally
   administered domain, so the administrator can make sure that
   abbreviations result in the right thing.  Outside of the local
   control, users are necessarily at risk.

これは単なる最適化ハッキングより多いです。 地元の管理者が局所的に管理されたドメインの中で名前の課題を管理するので、管理者は、略語が正しいものをもたらすのを確実にすることができます。 現場制御の外では、ユーザが必ず危険です。

Gavron                                                          [Page 3]

RFC 1535               DNS Software Enhancements            October 1993

Gavron[3ページ]RFC1535DNSソフトウェア機能強化1993年10月

   A more stringent mechanism is implemented in BIND 4.9.2, to respond
   to this problem:

より厳しいメカニズムはこの問題に応じるためにBIND4.9.2で実装されます:

   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
   to only try the first and the last of the examples shown.

IMPLICITが捜すDNS Nameレゾルバクライアント海峽は示された例の1番目と最終を試みるだけであるいずれかであるなら記載します。

   Any additional search alternatives must be configured into the
   resolver EXPLICITLY.

どんな追加検索選択肢もレゾルバEXPLICITLYに構成しなければなりません。

   DNS Name resolver software SHOULD NOT use implicit search lists in
   attempts to resolve partial names into absolute FQDNs other than the
   hosts's immediate parent domain.

DNS NameレゾルバソフトウェアSHOULD NOTはホストsの即座の親ドメイン以外の絶対FQDNsに部分的な名前に変える試みに内在している検索リストを使用します。

   Resolvers which continue to use implicit search lists MUST limit
   their scope to locally administered sub-domains.

内在している検索リストを使用し続けているレゾルバはそれらの範囲を局所的に管理されたサブドメインに制限しなければなりません。

   DNS Name resolver software SHOULD NOT come pre-configured with
   explicit search lists that perpetuate this problem.

DNS NameレゾルバソフトウェアSHOULD NOTはこの問題を永続させる明白な検索リストであらかじめ設定されていた状態で来ます。

   Further, in any event where a "." exists in a specified name it
   should be assumed to be a fully qualified domain name (FQDN) and
   SHOULD be tried as a rooted name first.

「さらに、そして、とにかく、どこ、a」 」 それが完全修飾ドメイン名(FQDN)であると思われるべきである指定された名前で存在していて、aが名義の1番目を根づかせたので、試験済みであるべきであるか。

   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
             should be attempted as a result of using an implicit
             search list:

例: 内在している検索リストを使用することの結果、e.f.g.hに2つのトライだけを接続する与えられた user@a.b.c.d は試みられるべきです:

                e.f.g.h.  and e.f.g.h.b.c.d.

e. f. g. h.とe.f.g.h.b.c.d。

             Given user@a.b.c.d. connecting to host those same two
             tries would appear as:

与えられた user@a.b.c.d それらの同じ2つのトライを主催するために接続するのは以下として現れるでしょう。

                x.b.c.d.  and x.

x. b. c. d.とx。

   Some organizations make regular use of multi-part, partially
   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
   might be used to making references to bar.loc2, or mumble.loc3, all
   of which refer to whatever.locN.org.city.state.us

複合の、そして、部分的に適切なDomain Namesの定期的な使用をする組織もあります。 例えば、ホストfoo.loc1.org.city.state.usはbar.loc2、またはmumble.loc3について言及するのに使用されるかもしれません。そのすべてがwhatever.locN.org.city.state.usについて言及します。

   The stringent implicit search rules for BIND 4.9.2 will now cause
   these searches to fail.  To return the ability for them to succeed,
   configuration of the client resolvers must be changed to include an
   explicit search rule for org.city.state.us.  That is, it must contain
   an explicit rule for any -- and each -- portion of the locally-
   administered sub-domain that it wishes to have as part of the search
   list.

BIND4.9.2のための厳しい暗黙の検索規則は現在、これらの検索に失敗されるでしょう。 彼らが成功する能力を返すなら、org.city.state.usのための明白な検索規則を含むようにクライアントレゾルバの構成を変えなければなりません。 いずれ、およびそれぞれのための明白な規則を含まなければなりません--それが検索リストの一部として持ちたがっている局所的に管理されたサブドメインの部分。

Gavron                                                          [Page 4]

RFC 1535               DNS Software Enhancements            October 1993

Gavron[4ページ]RFC1535DNSソフトウェア機能強化1993年10月

References

参照

   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
       RFC 1034, USC/Information Sciences Institute, November 1987.

[1]Mockapetrisと、P.と、「ドメイン名概念と施設」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日

   [2] Mockapetris, P., "Domain Names Implementation and Specification",
       STD 13, RFC 1035, USC/Information Sciences Institute, November
       1987.

[2]Mockapetrisと、P.と、「ドメイン名実装と仕様」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日

   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, CSNET CIC BBN, January 1986.

[3] ヤマウズラと、C.と、「メールルート設定とドメインシステム」、STD14、RFC974、CSNET CIC BBN、1月1986日

   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
       USC/Information Sciences Institute, USC, October 1993.

[4] クマー、A.、ポステル、J.、ヌーマン、C.、ダンツィグ、P.、およびS.ミラー、「一般的なDNS実装誤りの、そして、提案されたフィックス」、RFC1536、科学が設けるUSC/情報、USC、1993年10月。

   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
       1537, CWI, October 1993.

[5]Beertema、P.、「一般的なDNSデータファイル構成誤り」、RFC1537、CWI、1993年10月。

Security Considerations

セキュリティ問題

   This memo indicates vulnerabilities with all too-forgiving DNS
   clients.  It points out a correction that would eliminate the future
   potential of the problem.

このメモはすべてのまた、許しているDNSクライアントと共に脆弱性を示します。 それは問題の将来の可能性を排除する修正を指摘します。

Author's Address

作者のアドレス

   Ehud Gavron
   ACES Research Inc.
   PO Box 14546
   Tucson, AZ 85711

エフードGavron ACESはアリゾナ 株式会社私書箱14546ツーソン、85711について研究します。

   Phone: (602) 743-9841
   EMail: gavron@aces.com

以下に電話をしてください。 (602) 743-9841 メールしてください: gavron@aces.com

Gavron                                                          [Page 5]

Gavron[5ページ]