Network Working Group R. Moats
Request for Comments: 2517 R. Huber
Category: Informational AT&T
February 1999
Building Directories from DNS: Experiences from WWWSeeker
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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のディレクトリとWWWSeekerのデータベースサービスの開発・運用、組織の名前と場所についての情報を与えられたウェブサイトを発見したアプリケーションの間に学んだ教訓について説明します。このアプリケーションを駆動するバックエンドデータベースは、WHOISおよびその他のプロトコルを経由して、ドメイン登録から得られた情報から構築されました。私たちは、将来の実装者は、我々はすでに調査してきた袋小路のいくつかを避けるために、この情報を提示します。この作品は、コロラド大学ボールダー校[1]でマイク・シュワルツと彼のチームによって作成されたNetfindシステム上に構築します。
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.
時間が経つにつれて、インターネットディレクトリを提供するためのアプローチについて、いくつかのRFC [2、3、4]が行われています。以前の文書の多くは、など自分の電話番号、電子メールアドレス、に人の名前からのマッピングを提供するホワイトページディレクトリを議論します
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 guessable name.
さらに最近では、ドメイン名やWebサイトに会社名からマップディレクトリの議論がありました。多くの人は、与えられた会社に関するこの種の情報を見つけるために、今日のディレクトリとしてDNSを使用しています。 DNSを使用する場合は通常、ユーザーが先頭に追加、彼らが探している会社のドメイン名を推測し、「WWWを。」。これは、非常に望ましい企業が簡単に推測可能な名前を持ってできるようになります。
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文字の国コードトップレベルドメインだけでなく、他のgTLD（.NET、.ORG、およびおそらく.EDUが）であります将来的に追加のgTLDの見通し。一般的な使用が増大するのTLDの数として、推測はより困難になります。
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.
1996年7月と1998年3月における当社のシャットダウンの間、InterNICのディレクトリやデータベース・サービス事業は、Netfind検索エンジン[1]とドメイン名に組織情報をマッピングし、関連するデータベースを維持しました。このデータベースは、このように、ドメイン名と会社名を関連付けインターネットディレクトリのタイプを務めました。我々はまたWWWSeeker、特定の組織に関連するウェブサイトを見つけるために、Netfindデータベースを使用したシステムを構築しました。経験を積んだが、このデータベースを維持し、成長から得られたディレクトリサービスを提供するという課題に貴重な洞察を提供します。私たちは、将来の実装者は、我々はすでに調査してきた袋小路のいくつかを回避できるようにするために、ここでそれを提示します。
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つの問題は、以下に説明されています。
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、またはGopherのバルク形式で取得することができることを示している（私たちは、特定のTLDのためにこれらのそれぞれを使用しています）。これは、「スケルトンを構築する」と同時に、「肉を追加する」の両方の付加的な利点を有しています。 DNSドメインの情報を割り当てられたサーバーを見つけるための私たちのお気に入りの方法はで維持リストを開始することです
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ルックアップではなく経由で確認することができる「ツリーウォーク。」したがって、ディレクトリの人口のための最後の選択肢でなければなりません「木の散歩」、および一括検索が可能な限り使用すべきです。
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のディレクトリやデータベースサービスプロジェクトの終了時に、私たちのバックエンドデータベースは、WHOIS経由で取得することができたデータから構築された約2.9万レコードを含んでいました。データベース全体では、追加のレコードが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）とは対照的に（すなわちne.us）は、第2レベルドメインのWHOIS情報をサポートします。また、WHOISのサポートなしで、レジストラなしのTLD、TLDの、および組織の情報を提供するための他の方法（HTTP、FTP、Gopherの）を使用し、まだ他のTLDがあります。私たちの経験に基づいて、インターネットディレクトリの実装は、ディレクトリの人口のための複数のプロトコルをサポートする必要があります。自動化されたWHOIS検索ツールは必要であるが、十分ではありません。
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月における当社のデータベースのサイズを考えると、完全にはWHOIS検索から入手可能であるデータベースの再構築この推定値は、他の含まれていないだけで日のSPARCstation 20からWHOIS検索に134.2 167.8日の間で必要となります考慮事項は、データベース全体を再構築する時間の量を増加させるであろう（例えば、太陽のSPARCstation 20に処理時間を約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 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.
これが実行可能であるかどうかは、提供されたデータベースの更新の頻度に依存します。そのために割り当てられたドメイン名（初期の1998年には月産150K-200K新しい割り当てられたドメイン）の成長率を、我々はデータベースの毎月の更新を提供しました。データベースを再構築する（上記の時間推定値に基づいて）各月のフルタイム（マシン・アーキテクチャとは無関係に）専用である3〜5のマシンを必要とするであろう。代わりに、私たちは、割り当てられたドメインリストをチェックポイントと月の1回の週末の増分基づいて再構築します。これは、私たちは数日を完全に献身することなく、1〜4のマシン（3日のSPARCstation 20代とデュアルプロセッサのSPARCserver 690）の更新を完了することができました。基となる情報の変更さらに、（月の別の部分の間に行うことができ、マシンのハードウェアの完全な献身を必要としない）既存のデータの定期的な更新と増分更新を連結することによって、古いレコードは、定期的に更新されます。トレードオフは、ハードウェア及び処理費用に対するデータの適時性及び精度（データベース内の一部のデータが古い可能性がある）です。
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ファイルで億3.25以上のレコードを含んでいました。検索は、（また、PERLスクリプトによって生成される）逆ツリーのPERLスクリプトを介して行われました。確かに原始的ながら、この構成は、当社の本番サーバーから月額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.
データベースのサイズを大きくするだけで、データベースと逆ツリーを保持するために、より多くのディスク容量が必要です。もちろん、データベース技術を使用すると、おそらく、パフォーマンスとスケーラビリティを向上させるだろうが、我々はこの技術が必要とされた点に達していませんでした。
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.
ここで説明するプロトコルは、組み込みのセキュリティ機能を持っていません。ディレクトリデータが収集されている間に一つのソースマシンが詐称されている場合は、正しくないと誤解を招くようなデータのかなりの量は、ディレクトリに引っ張られることができ、より多くの人に広めること。
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.
データが既に公衆に利用可能であるため、一般的には、レジストリデータからディレクトリを構築しても、新しいセキュリティホールを開くことができません。データソースと既存のセキュリティと精度の問題が増幅される可能性があります。
This work described in this document was partially supported by the National Science Foundation under Cooperative Agreement NCR-9218179.
この文書に記載されているこの作品は、部分的協力協定NCR-9218179の下で国立科学財団によってサポートされていました。
[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.プルトニウム。 「Netfindに情報収集アーキテクチャの適用：変更し、成長のためのインターネットホワイトページツール」、コロラド大学技術報告書のCU-CS-656から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.
[2]、RFC 1107、1989年7月Sollins、K.、 "インターネットディレクトリサービスの計画を"。
[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.ケント、RFC 1430、1993年2月 "インターネットX.500ディレクトリサービスを展開するための戦略計画"。
[4] Postel, J. and C. Anderson, "White Pages Meeting Report", RFC 1588, February 1994.
[4]ポステル、J.とC.アンダーソン、 "ホワイトページ会議報告書"、RFC 1588、1994年2月。
[5] M. Lottor, "Network Wizards Internet Domain Survey", available from http://www.nw.com/zone/WWW/top.html
[5] http://www.nw.com/zone/WWW/top.htmlから入手可能M. Lottor、 "ネットワークウィザーズインターネットドメイン調査" を、
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
ライアン・モーツAT＆T 15621ドレクセルサークルオマハ、ネブラスカ68135から2358 USA
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ローレルアベニュー南ミドルタウン、NJ 07748 USA
EMail: rvh@att.com
メールアドレス：rvh@att.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。