As per Relevance of the word geographical, we have this rfc below:
Network Working Group C.
Request for Comments: 1712 M.
Category: Experimental S.
D.
Curtin University of
November 1994
DNS Encoding of Geographical
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This document defines the format of a new Resource Record (RR)
the Domain Naming System (DNS), and reserves a corresponding DNS
mnemonic and numerical code. This definition deals with
geographical host location mappings to host names within a domain
The data shown in this document is fictitious and does
necessarily reflect the real Internet
1.
It has been a long standing problem to relate IP numbers
geographical locations. The availability of Geographical
information has immediate applications in network management.
information can be used to supplement the data already provided
utilities such as whois [Har85], traceroute [VJ89], and
[UCB89]. The usefulness and functionality of these already
used tools would be greatly enhanced by the provision of
geographical location information
The ideal way to manage and maintain a database of information,
as geographical location of internet hosts, is to
responsibility to local domain administrators. A large
database could be implemented with a simple mechanism for
the local information. A query mechanism also has to be
for checking local entries, as well as inquiring about data
non-local domains
Farrell, Schulze, Pleitner & Baldoni [Page 1]
RFC 1712 DNS Encoding of Geographical Location November 1994
2.
The Internet continues to grow at an ever increasing rate with
numbers allocated on a first-come-first-serve basis. Deciding
and how to setup a database of geographical information
internet hosts presented a number of options. The uumap
[UU85] was the first serious attempt to collect geographical
data from sites and store it centrally. This project met
limited success because of the difficulty in maintaining and
a large central database. Another problem was the lack of tools
the checking the data supplied, this problem resulted in
erroneous data entering the database
2.1 SNMP
Using an SNMP get request on the sysLocation MIB (
Information Base) variable was also an option, however this
require the host to be running an appropriate agent with public
access. It was also felt that MIB data should reflect
management data (e.g., "this" host is on level 5 room 74) rather
a hosts geographical position. This view is supported in
examples given in literature in this area [ROSE91].
2.2 X500:
The X.500 Directory service [X.500.88] defined as part of the
standards also appears as a potential provider of
location data. However due to the limited implementations of
service it was decided to defer this until this service gains
use and acceptance within the Internet community
2.3 BIND
The DNS [Mock87a][Mock87b] represents an existing system
suited to the provision of host specific information. The DNS is
widely used and well-understood mechanism for providing a
database of such information and its extensible nature allows it
be used to disseminate virtually any information. The most
used DNS implementation is the Berkeley Internet Name Domain
BIND [UCB89]. The information we wished to make available needed
be updated locally but available globally; a perfect match with
services provided by the DNS. Current DNS servers provide a
of useful information about hosts in their domain but lack
ability to report a host's geographical location
Farrell, Schulze, Pleitner & Baldoni [Page 2]
RFC 1712 DNS Encoding of Geographical Location November 1994
3. RDATA
MSB
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ LONGITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ LATITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ALTITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where
LONGITUDE The real number describing the longitude encoded as
printable string. The precision is limited by 256
within the range -90..90 degrees. Positive
indicate locations north of the equator
LATITUDE The real number describing the latitude encoded as
printable string. The precision is limited by 256
within the range -180..180 degrees. Positive
indicate locations east of the prime meridian
ALTITUDE The real number describing the altitude (in meters)
mean sea-level encoded as a printable string. The
is limited by 256 charcters. Positive numbers
locations above mean sea-level
Latitude/Longitude/Altitude values are encoded as strings as to
the precision limitations imposed by encoding as unsigned integers
Although this might not be considered optimal, it allows for a
high degree of precision with an acceptable average encoded
length
4. The GPOS
The geographical location is defined with the mnemonic GPOS and
code 27.
GPOS has the following format
GPOS
A floating point format was chosen to specify geographical
for reasons of simplicity. This also guarantees a
unambiguous description of a location by enforcing three
numerical values to be specified
Farrell, Schulze, Pleitner & Baldoni [Page 3]
RFC 1712 DNS Encoding of Geographical Location November 1994
The owner, ttl, and class fields are optional and default to the
defined value if omitted. The longitude is a floating point
ranging from -90 to 90 with positive values indicating
north of the equator. For example Perth, Western Australia
located at 32^ 7` 19" south of the equator which would be
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"
of the prime meridian which would be specified as 116.86520.
University, Perth is also 10 meters above sea-level
The valid GPOS record for a host at Curtin University in
Western Australia would therefore be
GPOS -32.6882 116.8652 10.0
There is no limit imposed on the number of decimal places,
the length of the encoded string is limited to 256 characters
each field. It is also suggested that administrators limit
entries to the minimum number of necessary characters in each field
5. Master File
Each host requires its own GPOS field in the corresponding DNS RR
explicitly specify its geographical location and altitude. If
GPOS field is omitted, a DNS enquiry will return no
information for that host
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
IN HINFO SGI-Indigo IRIX-4.0.5
IN GPOS -32.6882 116.8652 10.0
ftp IN CNAME
Farrell, Schulze, Pleitner & Baldoni [Page 4]
RFC 1712 DNS Encoding of Geographical Location November 1994
lillee IN A 134.7.1.2
IN MX 0
IN HINFO SGI-Indigo IRIX-4.0.5
IN GPOS -32.6882 116.8652 10.0
hinault IN A 134.7.1.23
IN MX 0
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
IN HINFO SUN-IPC SunOS-4.1.1
ambrose IN A 134.7.1.99
IN MX 0
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
location, Perth Western Australia (-32.68820 116.86520). The
hinault is at a different geographical location, 10 degrees north
Perth in the mountains (-22.6882 116.8652 250.0). For
reasons we do not wish to give the location of the host merckx
Although the GPOS clause is not a standard entry within
configuration files, most vendor implementations seem to
whatever is not understood upon startup of the DNS. Usually
will result in a number of warnings appearing in system log files
but in no way alters naming information or impedes the DNS
performing its normal duties
Farrell, Schulze, Pleitner & Baldoni [Page 5]
RFC 1712 DNS Encoding of Geographical Location November 1994
7.
[ROSE91] Rose M., "The Simple Book: An Introduction
Management of TCP/IP-based Internets", Prentice-Hall
Englewood Cliffs, New Jersey, 1991.
[X.500.88] CCITT: The Directory - Overview of Concepts,
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
Facilities", STD 13, RFC 1034, USC/
Sciences Institute, November 1987.
[Mock87b] Mockapetris P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, USC/
Sciences Institute, November 1987.
[FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving
Routing and Addressing of IP", IEEE
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
Name Domain Server", 1989.
[UU85] UUCP Mapping Project, Software available
anonymous FTP from ftp.uu.net., 1985.
8. Security
Once information has been entered into the DNS, it is
public
Farrell, Schulze, Pleitner & Baldoni [Page 6]
RFC 1712 DNS Encoding of Geographical Location November 1994
9. Authors'
Craig
Department of Computer
Curtin University of
GPO Box U1987 Perth
Western
EMail: craig@cs.curtin.edu.
Mike
Department of Computer
Curtin University of
GPO Box U1987 Perth
Western
EMail: mike@cs.curtin.edu.
Scott
Department of Computer
Curtin University of
GPO Box U1987 Perth
Western
EMail: pleitner@cs.curtin.edu.
Daniel
Department of Computer
Curtin University of
GPO Box U1987 Perth
Western
EMail: flint@cs.curtin.edu.
Farrell, Schulze, Pleitner & Baldoni [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
