[要約] 要約：RFC 2517は、WWWSeekerプロジェクトの経験に基づいて、DNSからディレクトリを構築する方法について説明しています。 目的：DNSを使用して効果的なディレクトリ構築を実現するための手法とベストプラクティスを提供すること。
Network Working Group R. Moats
Request for Comments: 2517 R. Huber
Category: Informational AT&T
February 1999
Building Directories from DNS: Experiences from WWWSeeker
DNSからの建設ディレクトリ：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.
Copyright（c）The Internet Society（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の使用に依存することなく、組織のドメイン名を発見する方法に焦点を当てています。このメモでは、組織の名前と場所に関する情報が与えられたWebサイトを見つけるアプリケーションであるWwwseekerの内部ディレクトリおよびデータベースサービスの開発と運用中に学習されたレッスンについて説明します。このアプリケーションを駆動するバックエンドデータベースは、WHOISおよびその他のプロトコルを介してドメインレジストリから取得した情報から構築されました。この情報を提示して、将来の実装者がすでに調査した盲目の路地を避けるのを支援します。この作業は、マイク・シュワルツ校とコロラド大学ボルダー校の彼のチームによって作成されたNetFindシステムに基づいています[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.
時間が経つにつれて、インターネットディレクトリを提供するためのアプローチについては、いくつかの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
最近では、会社名からドメイン名またはWebサイトにマッピングされるディレクトリの議論があります。多くの人々が今日のディレクトリとしてDNSを使用して、特定の会社に関するこの種の情報を見つけています。通常、DNSを使用すると、ユーザーは探している会社のドメイン名を推測し、「www」をプレイします。これにより、企業が簡単に持っていることが非常に望ましいものになります
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文字のカントリーコードトップレベルドメインや、他の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月のシャットダウンの間に、Innollic Directory and Database Services Projectは、NetFind Search Engine [1]と、組織情報をドメイン名にマップする関連データベースを維持しました。したがって、このデータベースは、会社名をドメイン名と関連付けるインターネットディレクトリのタイプとして機能しました。また、NetFindデータベースを使用して特定の組織に関連付けられたWebサイトを見つけるシステムであるwwwseekerも構築しました。このデータベースの維持と成長から得られた経験豊富な人々は、ディレクトリサービスを提供する問題について貴重な洞察を提供します。ここでは、将来の実装者がすでに調査した盲目の路地を避けることができるようにします。
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
「Building the Skeleton」では、「ツリーウォーク」のバリアントを使用して、ディレクトリに追加する必要があるドメインを決定することを提案することが人気があります。私たちの経験は、これがそのようなディレクトリを維持するための合理的でも効率的な提案でもないということです。頻繁で長年の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.
ディレクトリ（「肉の追加」）に登録する可能性は、WOHISプロトコルを使用して繰り返しクエリを作成してドメインを所有する組織に関する情報を収集する自動化されたシステムを使用することです。クエリは、上記の方法で配置されたWHOISサーバーに対して行われます。Innollic Directory and Database Servicesプロジェクトの終わりに、バックエンドデータベースには、WHOISを介して取得できるデータから作成された約290万のレコードが含まれていました。データベース全体には325万のレコードが含まれており、追加の記録はWhois以外の情報源から届きました。
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）とは対照的に、第2レベルのドメイン（つまり、ne.us）の情報のみをサポートします。また、レジストラのないTLD、WHOISサポートのない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ルックアップから利用可能なデータベースの完全な再構築は、Sun Sparcstation 20からのWHOISルックアップのために134.2から167.8日間が必要になります。考慮事項（たとえば、トークンツリーを反転すると、Sun 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
これが実現可能かどうかは、提供されるデータベースの更新の頻度によって異なります。割り当てられたドメイン名の成長率（1998年初頭に1か月あたり150K-200K新しい割り当てられたドメイン）のため、データベースの毎月の更新を提供しました。データベースを再構築します
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個のマシンがフルタイム（マシンアーキテクチャとは無関係）を専用にする必要があります。代わりに、割り当てられたドメインリストをチェックポイントし、月の1つの週末に増分ベースで再構築しました。これにより、数日間にわたって完全な献身なく、1〜4台のマシン（3 Sun Sparcstation 20sとデュアルプロセッサ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ファイルに325万件以上の記録が含まれていました。検索は、逆ツリーのPerlスクリプト（Perlスクリプトによっても生成されます）を介して行われました。確かに原始的ですが、この構成は、生産サーバーから1か月あたり200,000を超えるデータベースクエリをサポートしていました。
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.
ここで説明するプロトコルには、セキュリティ機能が組み込まれていません。ディレクトリデータの収集中に1つのソースマシンがスプーフィングされている場合、かなりの量の誤った誤解を招くデータをディレクトリに引き込み、より多くの聴衆に広めることができます。
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。Pu。「情報収集アーキテクチャをNetFindに適用する：インターネットの変化と成長のためのホワイトページツール」、コロラド大学テクニカルレポートCU-CS-656-93。1993年12月、1994年7月改訂。
URL:ftp://ftp.cs.colorado.edu/pub/cs/techreports/schwartz/Netfind
[2] Sollins, K., "Plan for Internet Directory Services", RFC 1107, July 1989.
[2] Sollins、K。、「インターネットディレクトリサービスの計画」、RFC 1107、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.、Cerf、V.、Hobby、R。and S. Kent、「インターネットX.500ディレクトリサービスを展開するための戦略計画」、RFC 1430、1993年2月。
[4] Postel, J. and C. Anderson, "White Pages Meeting Report", RFC 1588, February 1994.
[4] Postel、J。およびC. Anderson、「ホワイトページ会議レポート」、RFC 1588、1994年2月。
[5] M. Lottor, "Network Wizards Internet Domain Survey", available
from http://www.nw.com/zone/WWW/top.html
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
ライアン・モートAT＆T 15621ドレクセルサークルオマハ、NE 68135-2358 USA
EMail: jayhawk@att.com
Rick Huber AT&T Room C3-3B30, 200 Laurel Ave. South Middletown, NJ 07748 USA
リック・フーバーAT＆TルームC3-3B30、200ローレルアベニューサウスミドルタウン、ニュージャージー07748 USA
EMail: rvh@att.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。