RFC2517 日本語訳

Network Working Group                                       R. Moats
Request for Comments: 2517                                  R. Huber
Category: Informational                                         AT&T
                                                       February 1999

堀がコメントのために要求するワーキンググループR.をネットワークでつないでください: 2517年のR.ヒューバーカテゴリ: 情報のAT&T1999年2月

       Building Directories from DNS: Experiences from WWWSeeker

DNSからのビルディレクトリ: WWWSeekerからの経験

Status of this Memo

この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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   There has been much discussion and several documents written about
   the need for an Internet Directory.  Recently, this discussion has
   focused on ways to discover an organization's domain name without
   relying on use of DNS as a directory service.  This memo discusses
   lessons that were learned during InterNIC Directory and Database
   Services' development and operation of WWWSeeker, an application that
   finds a web site given information about the name and location of an
   organization.  The back end database that drives this application was
   built from information obtained from domain registries via WHOIS and
   other protocols.  We present this information to help future
   implementors avoid some of the blind alleys that we have already
   explored.  This work builds on the Netfind system that was created by
   Mike Schwartz and his team at the University of Colorado at Boulder
   [1].

インターネットディレクトリの必要性に関して書かれた多くの議論といくつかのドキュメントがありました。 最近、この議論はディレクトリサービスとしてDNSの使用に依存しないで組織のドメイン名を発見する方法に焦点を合わせました。 このメモはInterNICディレクトリとDatabase Servicesの開発とWWWSeeker(組織の名前と位置に関するウェブサイト既知情報を見つけるアプリケーション)の操作の間に学習されたレッスンについて議論します。 このアプリケーションを動かすバックエンドデータベースはドメイン登録からWHOISと他のプロトコルで得られた情報から築き上げられました。 私たちは、将来の作成者が私たちが既に調査した袋小路のいくつかを避けるのを助けるためにこの情報を提示します。 この仕事はコロラド大学ボルダー校[1]でマイク・シュワルツと彼のチームによって作成されたNetfindシステムの上に建てられます。

1. Introduction

1. 序論

   Over time, there have been several RFCs [2, 3, 4] about approaches
   for providing Internet Directories.  Many of the earlier documents
   discussed white pages directories that supply mappings from a
   person's name to their telephone number, email address, etc.

時間がたつにつれて、インターネットディレクトリを提供するためのアプローチに関して数個のRFCs[2、3、4]がありました。 以前のドキュメントの多くが人の名前からのマッピングをそれらの電話番号、Eメールアドレスなどに供給するホワイトページディレクトリについて議論しました。

   More recently, there has been discussion of directories that map from
   a company name to a domain name or web site.  Many people are using
   DNS as a directory today to find this type of information about a
   given company.  Typically when DNS is used, users guess the domain
   name of the company they are looking for and then prepend "www.".
   This makes it highly desirable for a company to have an easily

より最近、それがドメイン名か会社名からウェブサイトまで写像するディレクトリの議論がありました。 多くの人々が、今日、与えられた会社に関してこの情報の種類を見つけるのにディレクトリとしてDNSを使用しています。 DNSが使用されているとき、通常、ユーザは彼らが探している会社と次に、prepend"www"のドメイン名を推測します。 これで会社が持つのにおいて非常に望ましくなる、簡単

Moats & Huber                Informational                      [Page 1]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[1ページ]のRFC2517ビルディレクトリ

   guessable name.

推測可能名。

   There are two major problems here.  As the number of assigned names
   increases, it becomes more difficult to get an easily guessable name.
   Also, the TLD must be guessed as well as the name.  While many users
   just guess ".COM" as the "default" TLD today, there are many two-
   letter country code top-level domains in current use as well as other
   gTLDs (.NET, .ORG, and possibly .EDU) with the prospect of additional
   gTLDs in the future.  As the number of TLDs in general use increases,
   guessing gets more difficult.

2つの大した問題がここにあります。 割り当てられた名前の数が増加するのに従って、容易に推測可能な名前を得るのは、より難しくなります。 また、名前と同様にTLDを推測しなければなりません。 多くのユーザが今日「デフォルト」TLDとしてただ".COM"を推測しますが、多くの2手紙国名略号最上位のドメインが将来、追加gTLDsの見通しがある他のgTLDs(.NET、.ORG、およびことによると.EDU)と同様に現在、使用中です。 TLDsの数が一般に増加を使用するとき、推測は、より難しくなります。

   Between July 1996 and our shutdown in March 1998, the InterNIC
   Directory and Database Services project maintained the Netfind search
   engine [1] and the associated database that maps organization
   information to domain names. This database thus acted as the type of
   Internet directory that associates company names with domain names.
   We also built WWWSeeker, a system that used the Netfind database to
   find web sites associated with a given organization.  The experienced
   gained from maintaining and growing this database provides valuable
   insight into the issues of providing a directory service.  We present
   it here to allow future implementors to avoid some of the blind
   alleys that we have already explored.

1998年3月の1996年7月、私たちの閉鎖の間では、InterNICディレクトリとDatabase Servicesプロジェクトは、Netfindがサーチエンジン[1]と組織情報をドメイン名に写像する関連データベースであることを支持しました。 その結果、このデータベースは会社名をドメイン名に関連づけるインターネットディレクトリのタイプとして機能しました。 また、私たちはWWWSeeker、ウェブサイトが与えられた組織に関連しているのがわかるのにNetfindデータベースを使用したシステムを構築しました。 経験豊富はこのデータベースがディレクトリサービスを提供する問題への貴重な見識を提供する維持と成長から得ました。 私たちは、将来の作成者が私たちが既に調査した袋小路のいくつかを避けるのを許容するためにここにそれを提示します。

2. Directory Population

2. ディレクトリ人口

2.1 What to do?

2.1 するべきこと?

   There are two issues in populating a directory: finding all the
   domain names (building the skeleton) and associating those domains
   with entities (adding the meat).  These two issues are discussed
   below.

ディレクトリに居住するのにおいて2冊があります: すべてのドメイン名を見つけて(骸骨を建てます)、それらのドメインを実体に関連づけます(肉を加えます)。 以下でこれらの2冊について議論します。

2.2 Building the skeleton

2.2 骸骨を建てること。

   In "building the skeleton", it is popular to suggest using a variant
   of a "tree walk" to determine the domains that need to be added to
   the directory.  Our experience is that this is neither a reasonable
   nor an efficient proposal for maintaining such a directory.  Except
   for some infrequent and long-standing DNS surveys [5], DNS "tree
   walks" tend to be discouraged by the Internet community, especially
   given that the frequency of DNS changes would require a new tree walk
   monthly (if not more often).  Instead, our experience has shown that
   data on allocated DNS domains can usually be retrieved in bulk
   fashion with FTP, HTTP, or Gopher (we have used each of these for
   particular TLDs).  This has the added advantage of both "building the
   skeleton" and "adding the meat" at the same time.  Our favorite
   method for finding a server that has allocated DNS domain information
   is to start with the list maintained at

「骸骨を建てます」では、ディレクトリに追加される必要があるドメインを決定するのに「木の散歩」の異形を使用するのを示すのはポピュラーです。 私たちの経験はこれがそのようなディレクトリを維持するためのどちらの妥当で効率的でない提案であるのもことです。 いくつかの珍しくて長年のDNS調査[5]を除いて、DNS「木の散歩」は、インターネットコミュニティによってがっかりされる傾向があります、DNS変化の頻度が(よりしばしば)毎月新しい木の散歩を必要とするなら。 代わりに、私たちの経験は、通常、割り当てられたDNSドメインに関するデータを大量に検索できるのを示しました。FTP、HTTP、またはゴーファー(私たちは特定のTLDsにそれぞれのこれらを使用した)があるファッション。 これには、ともに「骸骨を建て」て、同時に「肉を加えます」の加えられた利点があります。 サーバがそれであることがわかるための私たちの使い慣れた手段はドメイン情報が維持されるリストから始まることになっているDNSを割り当てました。

Moats & Huber                Informational                      [Page 2]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[2ページ]のRFC2517ビルディレクトリ

   http://www.alldomains.com/countryindex.html and go from there.
   Before this was available, it was necessary to hunt for a registry
   using trial and error.

そこからの http://www.alldomains.com/countryindex.html と碁。 これが利用可能になる前に、試行錯誤を使用する登録を探すのが必要でした。

   When maintaining the database, existing domains may be verified via
   direct DNS lookups rather than a "tree walk." "Tree walks" should
   therefore be the choice of last resort for directory population, and
   bulk retrieval should be used whenever possible.

データベースを維持するとき、既存のドメインは「木の散歩」よりむしろダイレクトDNSルックアップで確かめられるかもしれません。 したがって、「木の散歩」はディレクトリ人口のための切り札の選択であるべきです、そして、可能であるときはいつも、大量の検索は使用されるべきです。

2.3 Adding the meat

2.3 肉を加えること。

   A possibility for populating a directory ("adding the meat") is to
   use an automated system that makes repeated queries using the WHOIS
   protocol to gather information about the organization that owns a
   domain.  The queries would be made against a WHOIS server located
   with the above method. At the conclusion of the InterNIC Directory
   and Database Services project, our backend database contained about
   2.9 million records built from data that could be retrieved via
   WHOIS.  The entire database contained 3.25 million records, with the
   additional records coming from sources other than WHOIS.

ディレクトリ(「肉を加える」)に居住するための可能性はドメインを所有している組織に関して情報を収集するのにWHOISプロトコルを使用することで繰り返された質問をする自動化されたシステムを使用することです。 上のメソッドで見つけられたWHOISサーバに対して質問をするでしょう。 InterNICディレクトリとDatabase Servicesプロジェクトの結論では、私たちのバックエンドデータベースはWHOISを通して検索できたデータから築き上げられたおよそ290万の記録を含みました。 全体のデータベースは追加記録がWHOIS以外のソースから来ている325万の記録を含みました。

   In our experience this information contains many factual and
   typographical errors and requires further examination and processing
   to improve its quality.  Further, TLD registrars that support WHOIS
   typically only support WHOIS information for second level domains
   (i.e. ne.us) as opposed to lower level domains (i.e.
   windrose.omaha.ne.us).  Also, there are TLDs without registrars, TLDs
   without WHOIS support, and still other TLDs that use other methods
   (HTTP, FTP, gopher) for providing organizational information.  Based
   on our experience, an implementor of an internet directory needs to
   support multiple protocols for directory population.  An automated
   WHOIS search tool is necessary, but isn't enough.

私たちの経験では、この情報は、多くの事実上の、そして、印刷の誤りを含んでいて、品質を改良するためにさらなる試験と処理を必要とします。 さらに、WHOISをサポートするTLD記録係は、下のレベルドメイン(すなわち、windrose.omaha.ne.us)と対照的にWHOISがセカンドレベルドメイン(すなわち、ne.us)のための情報であると通常サポートするだけです。 また、組織的な情報を提供するのに、他のメソッド(HTTP、FTP、リス)を使用する記録係のいないTLDs、WHOISサポートのないTLDs、およびまだ他のTLDsがあります。 私たちの経験に基づいて、インターネットディレクトリの作成者は、ディレクトリ人口のために複数のプロトコルをサポートする必要があります。 自動化されたWHOIS検索ツールは、必要ですが、十分ではありません。

3. Directory Updating: Full Rebuilds vs Incremental Updates

3. ディレクトリアップデート: 完全は増加に対してアップデートを再建します。

   Given the size of our database in April 1998 when it was last
   generated, a complete rebuild of the database that is available from
   WHOIS lookups would require between 134.2 to 167.8 days just for
   WHOIS lookups from a Sun SPARCstation 20. This estimate does not
   include other considerations (for example, inverting the token tree
   required about 24 hours processing time on a Sun SPARCstation 20)
   that would increase the amount of time to rebuild the entire
   database.

それが最後であった1998年4月の私たちのデータベースのサイズを発生して、a完全に与える、ルックアップがまさしくWHOISルックアップのために134.2〜167.8日間の間でSun SPARCstation20から必要とするWHOISから利用可能なデータベースの再建 この見積りは全体のデータベースを再建する時間を増強する他の問題(例えば、トークン木を逆にするのはSun SPARCstation20でおよそ24時間の処理時間を必要とした)を含んでいません。

   Whether this is feasible depends on the frequency of database updates
   provided.  Because of the rate of growth of allocated domain names
   (150K-200K new allocated domains per month in early 1998), we
   provided monthly updates of the database. To rebuild the database

これが可能であるかどうかが提供されたデータベース更新の頻度に依存します。 割り当てられたドメイン名(早めの1998のカ月あたりの150K-200のKの新しい割り当てられたドメイン)の成長率のために、私たちはデータベースの毎月のアップデートを提供しました。 データベースを再建するために

Moats & Huber                Informational                      [Page 3]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[3ページ]のRFC2517ビルディレクトリ

   each month (based on the above time estimate) would require between 3
   and 5 machines to be dedicated full time (independent of machine
   architecture).  Instead, we checkpointed the allocated domain list
   and rebuild on an incremental basis during one weekend of the month.
   This allowed us to complete the update on between 1 and 4 machines (3
   Sun SPARCstation 20s and a dual-processor Sparcserver 690) without
   full dedication over a couple of days.  Further, by coupling
   incremental updates with periodic refresh of existing data (which can
   be done during another part of the month and doesn't require full
   dedication of machine hardware), older records would be periodically
   updated when the underlying information changes.  The tradeoff is
   timeliness and accuracy of data (some data in the database may be
   old) against hardware and processing costs.

毎月(上の時間見積りに基づいている)は、3〜5台のマシンがひたむきなフルタイム(マシンアーキテクチャの如何にかかわらず)であることを必要とするでしょう。 代わりに、私たちは月のある週末の間ドメインが増加ベースで記載して、再建する割り当てをcheckpointedしました。 これで、私たちは2、3日間、完全な奉納なしで1〜4台のマシン(3Sun SPARCstation20年代とデュアル・プロセッサSparcserver690)に関する最新情報を完成できました。 基本的な情報が変化するとき、さらに、周期的であるのがあるアップデート増加がリフレッシュする既存のデータ(月の別の部分の間、することができて、マシンハードウェアの完全な奉納を必要としない)のカップリングで、より古い記録を定期的にアップデートするでしょう。 見返りは、ハードウェアと処理コストに対するデータ(データベースのいくつかのデータが古いかもしれない)のタイムリーと精度です。

4. Directory Presentation: Distributed vs Monolithic

4. ディレクトリプレゼンテーション: 一枚岩的に対して分配されます。

   While a distributed directory is a desirable goal, we maintained our
   database as a monolithic structure.  Given past growth, it is not
   clear at what point migrating to a distributed directory becomes
   actually necessary to support customer queries.  Our last database
   contained over 3.25 million records in a flat ASCII file.  Searching
   was done via a PERL script of an inverted tree (also produced by a
   PERL script).  While admittedly primitive, this configuration
   supported over 200,000 database queries per month from our production
   servers.

分配されたディレクトリは望ましい目標ですが、私たちは一枚岩的な構造としてデータベースを維持しました。 過去の成長を考えて、分配されたディレクトリにわたるのが実際にサポート顧客質問に必要になるのは、どんなポイントで明確でないか。 私たちの最後のデータベースは平坦なASCIIファイルでの325万以上の記録を含みました。 逆ツリー(また、Perlスクリプトで、生産される)のPerlスクリプトで探すことをしました。 明白に原始的ですが、この構成は、私たちのプロダクションサーバーから1カ月あたり20万以上データベースが質問であるとサポートしました。

   Increasing the database size only requires more disk space to hold
   the database and inverted tree. Of course, using database technology
   would probably improve performance and scalability, but we had not
   reached the point where this technology was required.

データベースサイズを増強するのが、データベースと逆ツリーを保持するために、より多くの椎間腔を必要とするだけです。 もちろん、データベース技術を使用すると、性能とスケーラビリティはたぶん向上するでしょうが、私たちはこの技術が必要であったポイントに達していませんでした。

5. Security Considerations

5. セキュリティ問題

   The underlying data for the type of directory discussed in this
   document is already generally available through WHOIS, DNS, and other
   standard interfaces.  No new information is made available by using
   these techniques though many types of search become much easier.  To
   the extent that easier access to this data makes it easier to find
   specific sites or machines to attack, security may be decreased.

一般に、本書では議論したディレクトリのタイプへの基本的なデータはWHOIS、DNS、および他の標準インターフェースを通して既に利用可能です。 検索の多くのタイプがはるかに簡単になりますが、これらのテクニックを使用することによって、新情報を全く利用可能にしません。 このデータへの、より簡単なアクセスで特定のサイトか攻撃するマシンを見つけるのが、より簡単になるという範囲まで、セキュリティは下がるかもしれません。

   The protocols discussed here do not have built-in security features.
   If one source machine is spoofed while the directory data is being
   gathered, substantial amounts of incorrect and misleading data could
   be pulled in to the directory and be spread to a wider audience.

ここで議論したプロトコルは内蔵のセキュリティー機能を持っていません。 ディレクトリデータが集められている間、1台のソースマシンが偽造されるなら、かなりの量の不正確で紛らわしいデータが、ディレクトリに引きつけられていて、より広い聴衆に広げられるかもしれません。

Moats & Huber                Informational                      [Page 4]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[4ページ]のRFC2517ビルディレクトリ

   In general, building a directory from registry data will not open any
   new security holes since the data is already available to the public.
   Existing security and accuracy problems with the data sources are
   likely to be amplified.

一般に、登録データからのディレクトリを造る場合、公衆には、データが既に利用可能であるので、どんな新しいセキュリティーホールも開かないでしょう。 データ送信端末に関する既存のセキュリティと精度問題は増幅されそうです。

6. Acknowledgments

6. 承認

   This work described in this document was partially supported by the
   National Science Foundation under Cooperative Agreement NCR-9218179.

本書では説明されたこの仕事はCooperative Agreement NCR-9218179の下で国立科学財団によって部分的にサポートされました。

7. References

7. 参照

   [1] M. F. Schwartz, C. Pu.  "Applying an Information
       Gathering Architecture to Netfind: A White Pages Tool for a
       Changing and Growing Internet", University of Colorado Technical
       Report CU-CS-656-93.  December 1993, revised July 1994.

[1] M.F.シュワルツ、C.Pu。 「情報収集アーキテクチャをNetfindに適用します:」 「変えていて増加しているインターネットへのホワイトページツール」、コロラド大学技術報告書Cu Cs656-93。 1993年12月、改訂された1994年7月。

       URL:ftp://ftp.cs.colorado.edu/pub/cs/techreports/schwartz/Netfind

URL: ftp://ftp.cs.colorado.edu/pub/cs/techreports/schwartz/Netfind

   [2] Sollins, K., "Plan for Internet Directory Services", RFC 1107,
       July 1989.

Sollins(K.)が「インターネットディレクトリサービスのために計画している」[2]、RFC1107、1989年7月。

   [3] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R. and S.
       Kent, "A Strategic Plan for Deploying an Internet X.500 Directory
       Service", RFC 1430, February 1993.

[3]Hardcastle-KilleとS.とHuizerとE.とサーフとV.と趣味とR.とS.ケント、「インターネットX.500ディレクトリサービスを配布するための長期計画」、RFC1430、1993年2月。

   [4] Postel, J. and  C. Anderson, "White Pages Meeting Report", RFC
       1588, February 1994.

[4] ポステルとJ.とC.アンダーソン、「ホワイトページミーティングレポート」、RFC1588、1994年2月。

   [5] M. Lottor, "Network Wizards Internet Domain Survey", available
       from http://www.nw.com/zone/WWW/top.html

[5]M.Lottor、 http://www.nw.com/zone/WWW/top.html から利用可能な「ネットワークウィザーズインターネットドメイン調査」

Moats & Huber                Informational                      [Page 5]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[5ページ]のRFC2517ビルディレクトリ

8. Authors' Addresses

8. 作者のアドレス

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

ライアン・モウツAT&T15621ドレクセル・円のNE68135-2358オマハ(米国)

   EMail:  jayhawk@att.com

メール: jayhawk@att.com

   Rick Huber
   AT&T
   Room C3-3B30, 200 Laurel Ave. South
   Middletown, NJ 07748
   USA

リックヒューバーAT&T余地のC3-3B30、200ローレルAve。 南ミドルタウン、ニュージャージー07748米国

   EMail: rvh@att.com

メール: rvh@att.com

Moats & Huber                Informational                      [Page 6]

RFC 2517             Building Directories from DNS         February 1999

DNS1999年2月からの堀とヒューバー情報[6ページ]のRFC2517ビルディレクトリ

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Moats & Huber                Informational                      [Page 7]

モウツとヒューバーInformationalです。[7ページ]