この文書はRFC 1712の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group C. Farrell Request for Comments: 1712 M. Schulze Category: Experimental S. Pleitner D. Baldoni Curtin University of Technology November 1994 DNS Encoding of Geographical Location 地理的な場所のDNSコード化 Status of this Memo この文書の状態 This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. この文書はインターネット共同体のための実験的なプロトコルを定義します。 この文書は、インターネット標準を指定しません。改良のための論議と提案 が求められます。このメモの配布は無制限です。 Abstract 要約 This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain. The data shown in this document is fictitious and does not necessarily reflect the real Internet. この文書はドメイン名システム(DNS)の新しい資源レコード(RR)の フォーマットを定義し、そして対応するDNS種別の略称と数のコードを予 約します。この定義はドメイン内のホスト名とホストの地理的な場所の対応 付けを論じます。この文書に示されたデータは架空であり、実際のインター ネットを反映しません。 1. Introduction 1. はじめに It has been a long standing problem to relate IP numbers to geographical locations. The availability of Geographical location information has immediate applications in network management. Such information can be used to supplement the data already provided by utilities such as whois [Har85], traceroute [VJ89], and nslookup [UCB89]. The usefulness and functionality of these already widely used tools would be greatly enhanced by the provision of reliable geographical location information. 地理的な場所とIP番号を関連づけることは、これまで(長く存続している 問題でした。ネットワーク管理のアプリケーションで、地理的な場所情報は 有効です。このような情報はすでに供給されているwhois[Har85]や traceroute[VJ89]やnslookup[UCB89]のようなユーティリティーのデータを 補うために使うことができます。これらのすでに広く使われるツールの有用 性と機能性は、信頼できる地理的な場所情報の供給によって、拡張されるで しょう。 The ideal way to manage and maintain a database of information, such as geographical location of internet hosts, is to delegate responsibility to local domain administrators. A large distributed database could be implemented with a simple mechanism for updating the local information. A query mechanism also has to be available for checking local entries, as well as inquiring about data from non-local domains. インターネットホストの地理的な場所のような情報のデータベースを管理し 維持する理想的な方法は、ローカルドメイン管理者に責任を委任することで す。単純な大規模分散データベースで、ローカルな情報を更新するメカニズ ムを実装することができます。問合せメカニズムは、非ローカルドメインか らのデータと尋ねることに加えて、ローカルな項目を確認することに利用可 能でなければなりません。 2. Background 2. 背景 The Internet continues to grow at an ever increasing rate with IP numbers allocated on a first-come-first-serve basis. Deciding when and how to setup a database of geographical information about internet hosts presented a number of options. The uumap project [UU85] was the first serious attempt to collect geographical location data from sites and store it centrally. This project met with limited success because of the difficulty in maintaining and updating a large central database. Another problem was the lack of tools for the checking the data supplied, this problem resulted in some erroneous data entering the database. インターネットは常に増加で成長し続け、IP番号が最初に来たのに最初に割 り当てる考えて割り当てられています。いつとのようにインターネットホスト の地理情報データベースを設定するの決定は、いくつもの選択肢があります。 uumapプロジェクト[UU85]はサイトの地理的な場所のデータを集め、集中保存す る最初の本気の試みでした。大きい中央データベースを維持して更新す困難さ により、このプロジェクトの成功は限定的でした。もう1つの問題は、供給さ れたデータを調べる道具がないことでした、この問題はいくつかの誤ったデー タがデータベースに入力されるという結果になりました。 2.1 SNMP: 2.1 SNMP: Using an SNMP get request on the sysLocation MIB (Management Information Base) variable was also an option, however this would require the host to be running an appropriate agent with public read access. It was also felt that MIB data should reflect local management data (e.g., "this" host is on level 5 room 74) rather than a hosts geographical position. This view is supported in the examples given in literature in this area [ROSE91]. SNMPのsysLocation MIB(管理情報成分)変数の得る要求を使うのは選択肢の 1つですが、これはホストで公開読取の適切なエージェントが動いている事 を要求します。MIBデータがホストの地理的な位置でなくローカルな管理 データを反映していると感じられます(例えば、「この」ホストが74号室 の5段にある)。この考察はこの分野の文献[ROSE91]で与えられた例でも確 認できます。 2.2 X500: 2.2 X500: The X.500 Directory service [X.500.88] defined as part of the ISO standards also appears as a potential provider of geographical location data. However due to the limited implementations of this service it was decided to defer this until this service gains wider use and acceptance within the Internet community. X.500ディレクトリサービス[X.500.88]はISO標準の一部と定義され、地理的 な場所のデータの供給者になる可能性がありそうです。しかしながら、この サービスの実施が限定されているため、このサービスがインターネット共同 体の中でより広範囲に使用され受け入れられるませ、これを延期すると決め られました。 2.3 BIND: 2.3 BIND: The DNS [Mock87a][Mock87b] represents an existing system ideally suited to the provision of host specific information. The DNS is a widely used and well-understood mechanism for providing a distributed database of such information and its extensible nature allows it to be used to disseminate virtually any information. The most commonly used DNS implementation is the Berkeley Internet Name Domain server BIND [UCB89]. The information we wished to make available needed to be updated locally but available globally; a perfect match with the services provided by the DNS. Current DNS servers provide a variety of useful information about hosts in their domain but lack the ability to report a host's geographical location. DNS[Mock87a][Mock87b]は概念的にはホスト固有の情報の提供に適合された 既存のシステムです。DNSはこのような情報の分散データベースを提供する、 広く使われて、よく理解されているメカニズムです、そしてその拡張可能性は 事実上任意の情報を広めるために使うことが可能です。最も一般に使われたD NS実装はバークレーインターネットネームドメインサーバーBIND[UCB89] です。我々が提供することを望んだ情報はローカルに更新されるされる必要が あり、グローバル利用可能なものです:DNSの供給するサービスに完全に一 致します。現在のDNSサーバは、そのドメインのホストに関するいろいろな 有用な情報を提供しますが、ホストの地理的な場所を報告する能力は欠けてい ます。 3. RDATA Format 3. 資源データフォーマット MSB LSB +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / LONGITUDE / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / LATITUDE / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / ALTITUDE / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: LONGITUDE The real number describing the longitude encoded as a printable string. The precision is limited by 256 charcters within the range -90..90 degrees. Positive numbers indicate locations north of the equator. 経度 印刷可能文字列でコード化された経度を記述する実数。精度は 256文字に制限され、−90〜90度の範囲です。正の数が 赤道の北に場所を示します。 LATITUDE The real number describing the latitude encoded as a printable string. The precision is limited by 256 charcters within the range -180..180 degrees. Positive numbers indicate locations east of the prime meridian. 緯度 印刷可能文字でコード化された緯度を記述する実数。精度は256 文字で制限され、−180度〜180度の範囲です。正の数が本初 子午線の東の場所を示します。 ALTITUDE The real number describing the altitude (in meters) from mean sea-level encoded as a printable string. The precision is limited by 256 charcters. Positive numbers indicate locations above mean sea-level. 高度 印刷可能文字でコード化された平均海面からの高度(メートル単位) を示す実数。精度は256文字で制限されます。正の数が平均海面 の上の場所を示します。 Latitude/Longitude/Altitude values are encoded as strings as to avoid the precision limitations imposed by encoding as unsigned integers. Although this might not be considered optimal, it allows for a very high degree of precision with an acceptable average encoded record length. 緯度/経度/高度値が符号なし整数のコード化による精度の制限を避けるため、 文字列としてコード化されます。これが最適と思えないかもしれませんが、 これは適切な平均のコード化レコード長で非常に高い精度を可能にします。 4. The GPOS RR 4. GPOS資源レコード The geographical location is defined with the mnemonic GPOS and type code 27. 地理的な場所は略称GPOSと種別コード27で定義されます。 GPOS has the following format: GPOSは次のフォーマットです: <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude> A floating point format was chosen to specify geographical locations for reasons of simplicity. This also guarantees a concise unambiguous description of a location by enforcing three compulsory numerical values to be specified. 地理的な場所を指定するのに、単純である理由で、浮動小数点形式が選ばれま した。3つの必須の数値の指定をすることで、場所の簡潔で明確な記述を保証 します。 The owner, ttl, and class fields are optional and default to the last defined value if omitted. The longitude is a floating point number ranging from -90 to 90 with positive values indicating locations north of the equator. For example Perth, Western Australia is located at 32^ 7` 19" south of the equator which would be specified as -32.68820. The latitude is a number ranging from -180.0 to 180.0. For example Perth, Western Australia is located at 116^ 2' 25" east of the prime meridian which would be specified as 116.86520. Curtin University, Perth is also 10 meters above sea-level. ownerとttlとclassフィールドの記述は任意で、もしない場合、デフォルト は最後に定義した値です。longitudeは−90〜90の範囲の浮動小数点数で、 正の値が赤道の北に場所を示します。例えば、赤道の南の32^ 7` 19"に位置 するオーストラリア西部のパースは-32.68820で示されます。緯度は −180.0から180.0までの数です。例えば、本初子午線の東の 116^ 2' 25"に位置するオーストラリア西部のパースは、116.86520 で示されます。パースのカーティン大学は海面より10メートル上にありま す。 The valid GPOS record for a host at Curtin University in Perth Western Australia would therefore be: 従ってオーストラリア西部のパースのカーティン大学のホストの正当なGPOS レコードは以下であるでしょう: GPOS -32.6882 116.8652 10.0 There is no limit imposed on the number of decimal places, although the length of the encoded string is limited to 256 characters for each field. It is also suggested that administrators limit their entries to the minimum number of necessary characters in each field. それぞれのフィールドのコード化された文字列の長さが256の文字に制限 されますが、少数位の数に制限はありません。管理者がそれぞれのフィール ドを、項目に必要な最小数文字数に制限することが示唆されます。 5. Master File Format 5. マスターファイル形式 Each host requires its own GPOS field in the corresponding DNS RR to explicitly specify its geographical location and altitude. If the GPOS field is omitted, a DNS enquiry will return no position information for that host. それぞれのホストが対応するDNS資源レコードのGPOSフィールドで明示的 にその地理的な場所と高度を指定することを必要とします。もしGPOSフィー ルドが省略されるなら、DNS問合せはそのホストの位置情報を返さないで しょう。 Consider the following example: 次の例を考えてください: ; Authoritative data for cs.curtin.edu.au. ; @ IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au. ( 94070503 ; Serial (yymmddnn) 10800 ; Refresh (3 hours) 3600 ; Retry (1 hour) 3600000 ; Expire (1000 hours) 86400 ; Minimum (24 hours) ) IN NS marsh.cs.curtin.edu.au. marsh IN A 134.7.1.1 IN MX 0 marsh IN HINFO SGI-Indigo IRIX-4.0.5F IN GPOS -32.6882 116.8652 10.0 ftp IN CNAME marsh lillee IN A 134.7.1.2 IN MX 0 marsh IN HINFO SGI-Indigo IRIX-4.0.5F IN GPOS -32.6882 116.8652 10.0 hinault IN A 134.7.1.23 IN MX 0 marsh IN HINFO SUN-IPC SunOS-4.1.3 IN GPOS -22.6882 116.8652 250.0 merckx IN A 134.7.1.24 IN MX 0 marsh IN HINFO SUN-IPC SunOS-4.1.1 ambrose IN A 134.7.1.99 IN MX 0 marsh IN HINFO SGI-CHALLENGE_L IRIX-5.2 IN GPOS -32.6882 116.8652 10.0 The hosts marsh, lillee, and ambrose are all at the same geographical location, Perth Western Australia (-32.68820 116.86520). The host hinault is at a different geographical location, 10 degrees north of Perth in the mountains (-22.6882 116.8652 250.0). For security reasons we do not wish to give the location of the host merckx. ホストmarshとlilleeとambroseはすべて同じ地理的な場所、オーストラリ ア西部のパース(−32.68820 116.86520)にあります。ホス トhinaultは異なる地理的な場所、パースの10度北の山中(−22.6882 116.8652 250.0)にあります。セキュリティの理由で我々はホス トmerckxの場所を与えることを望みません。 Although the GPOS clause is not a standard entry within BIND configuration files, most vendor implementations seem to ignore whatever is not understood upon startup of the DNS. Usually this will result in a number of warnings appearing in system log files, but in no way alters naming information or impedes the DNS from performing its normal duties. GPOSがBIND設定ファイルの標準的な項目ではないですが、たいていのベンダー 実装は、DNS起動時に理解できないものは全て無視するように思われます。 通常これは多くの警告がシステムログファイルに現われるという結果になるで しょうが、決して命名情報を変えたり、DNSの通常の任務を妨げたりしませ ん。 7. References 7. 参考文献 [ROSE91] Rose M., "The Simple Book: An Introduction to Management of TCP/IP-based Internets", Prentice-Hall, Englewood Cliffs, New Jersey, 1991. [X.500.88] CCITT: The Directory - Overview of Concepts, Models and Services", Recommendations X.500 - X.521. [Har82] Harrenstein K, Stahl M., and E. Feinler, "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982. [Mock87a] Mockapetris P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [Mock87b] Mockapetris P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving the Routing and Addressing of IP", IEEE Network Vol.7, No. 3, pp. 11-15, May 1993. [VJ89] Jacobsen V., "The Traceroute(8) Manual Page", Lawrence Berkeley Laboratory, Berkeley, CA, February 1989. [UCB89] University of California, "BIND: Berkeley Internet Name Domain Server", 1989. [UU85] UUCP Mapping Project, Software available via anonymous FTP from ftp.uu.net., 1985. 8. Security Considerations 8. セキュリティの考察 Once information has been entered into the DNS, it is considered public. 情報がDNSに入力された途端に、それは公開されると思われます。 9. Authors' Addresses 9. 著者のアドレス Craig Farrell Department of Computer Science Curtin University of technology GPO Box U1987 Perth, Western Australia EMail: craig@cs.curtin.edu.au Mike Schulze Department of Computer Science Curtin University of technology GPO Box U1987 Perth, Western Australia EMail: mike@cs.curtin.edu.au Scott Pleitner Department of Computer Science Curtin University of technology GPO Box U1987 Perth, Western Australia EMail: pleitner@cs.curtin.edu.au Daniel Baldoni Department of Computer Science Curtin University of technology GPO Box U1987 Perth, Western Australia EMail: flint@cs.curtin.edu.au