この文書はRFC 1712の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
地理的な場所のＤＮＳコード化
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.
この文書はドメイン名システム（ＤＮＳ）の新しい資源レコード（ＲＲ）の
フォーマットを定義し、そして対応するＤＮＳ種別の略称と数のコードを予
約します。この定義はドメイン内のホスト名とホストの地理的な場所の対応
付けを論じます。この文書に示されたデータは架空であり、実際のインター
ネットを反映しません。
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.
地理的な場所とＩＰ番号を関連づけることは、これまで（長く存続している
問題でした。ネットワーク管理のアプリケーションで、地理的な場所情報は
有効です。このような情報はすでに供給されている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.
インターネットは常に増加で成長し続け、ＩＰ番号が最初に来たのに最初に割
り当てる考えて割り当てられています。いつとのようにインターネットホスト
の地理情報データベースを設定するの決定は、いくつもの選択肢があります。
uumapプロジェクト[UU85]はサイトの地理的な場所のデータを集め、集中保存す
る最初の本気の試みでした。大きい中央データベースを維持して更新す困難さ
により、このプロジェクトの成功は限定的でした。もう１つの問題は、供給さ
れたデータを調べる道具がないことでした、この問題はいくつかの誤ったデー
タがデータベースに入力されるという結果になりました。
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(管理情報成分)変数の得る要求を使うのは選択肢の
１つですが、これはホストで公開読取の適切なエージェントが動いている事
を要求します。ＭＩＢデータがホストの地理的な位置でなくローカルな管理
データを反映していると感じられます（例えば、「この」ホストが７４号室
の５段にある）。この考察はこの分野の文献[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.
ＤＮＳ[Mock87a][Mock87b]は概念的にはホスト固有の情報の提供に適合された
既存のシステムです。ＤＮＳはこのような情報の分散データベースを提供する、
広く使われて、よく理解されているメカニズムです、そしてその拡張可能性は
事実上任意の情報を広めるために使うことが可能です。最も一般に使われたＤ
ＮＳ実装はバークレーインターネットネームドメインサーバーＢＩＮＤ[UCB89]
です。我々が提供することを望んだ情報はローカルに更新されるされる必要が
あり、グローバル利用可能なものです：ＤＮＳの供給するサービスに完全に一
致します。現在のＤＮＳサーバは、そのドメインのホストに関するいろいろな
有用な情報を提供しますが、ホストの地理的な場所を報告する能力は欠けてい
ます。
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.
経度 印刷可能文字列でコード化された経度を記述する実数。精度は
２５６文字に制限され、−９０〜９０度の範囲です。正の数が
赤道の北に場所を示します。
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.
緯度 印刷可能文字でコード化された緯度を記述する実数。精度は２５６
文字で制限され、−１８０度〜１８０度の範囲です。正の数が本初
子午線の東の場所を示します。
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.
高度 印刷可能文字でコード化された平均海面からの高度（メートル単位）
を示す実数。精度は２５６文字で制限されます。正の数が平均海面
の上の場所を示します。
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と種別コード２７で定義されます。
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.
地理的な場所を指定するのに、単純である理由で、浮動小数点形式が選ばれま
した。３つの必須の数値の指定をすることで、場所の簡潔で明確な記述を保証
します。
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は−９０〜９０の範囲の浮動小数点数で、
正の値が赤道の北に場所を示します。例えば、赤道の南の32^ 7` 19"に位置
するオーストラリア西部のパースは-32.68820で示されます。緯度は
−１８０.０から１８０.０までの数です。例えば、本初子午線の東の
116^ 2' 25"に位置するオーストラリア西部のパースは、１１６.８６５２０
で示されます。パースのカーティン大学は海面より１０メートル上にありま
す。
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.
それぞれのフィールドのコード化された文字列の長さが２５６の文字に制限
されますが、少数位の数に制限はありません。管理者がそれぞれのフィール
ドを、項目に必要な最小数文字数に制限することが示唆されます。
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.
それぞれのホストが対応するＤＮＳ資源レコードのGPOSフィールドで明示的
にその地理的な場所と高度を指定することを必要とします。もしGPOSフィー
ルドが省略されるなら、ＤＮＳ問合せはそのホストの位置情報を返さないで
しょう。
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はすべて同じ地理的な場所、オーストラリ
ア西部のパース（−３２.６８８２０ １１６.８６５２０）にあります。ホス
トhinaultは異なる地理的な場所、パースの１０度北の山中（−２２.６８８２
１１６.８６５２ ２５０.０）にあります。セキュリティの理由で我々はホス
ト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設定ファイルの標準的な項目ではないですが、たいていのベンダー
実装は、ＤＮＳ起動時に理解できないものは全て無視するように思われます。
通常これは多くの警告がシステムログファイルに現われるという結果になるで
しょうが、決して命名情報を変えたり、ＤＮＳの通常の任務を妨げたりしませ
ん。
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.
情報がＤＮＳに入力された途端に、それは公開されると思われます。
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