7 Network Working Group C. Farrell
8 Request for Comments: 1712 M. Schulze
9 Category: Experimental S. Pleitner
11 Curtin University of Technology
15 DNS Encoding of Geographical Location
19 This memo defines an Experimental Protocol for the Internet
20 community. This memo does not specify an Internet standard of any
21 kind. Discussion and suggestions for improvement are requested.
22 Distribution of this memo is unlimited.
26 This document defines the format of a new Resource Record (RR) for
27 the Domain Naming System (DNS), and reserves a corresponding DNS type
28 mnemonic and numerical code. This definition deals with associating
29 geographical host location mappings to host names within a domain.
30 The data shown in this document is fictitious and does not
31 necessarily reflect the real Internet.
35 It has been a long standing problem to relate IP numbers to
36 geographical locations. The availability of Geographical location
37 information has immediate applications in network management. Such
38 information can be used to supplement the data already provided by
39 utilities such as whois [Har85], traceroute [VJ89], and nslookup
40 [UCB89]. The usefulness and functionality of these already widely
41 used tools would be greatly enhanced by the provision of reliable
42 geographical location information.
44 The ideal way to manage and maintain a database of information, such
45 as geographical location of internet hosts, is to delegate
46 responsibility to local domain administrators. A large distributed
47 database could be implemented with a simple mechanism for updating
48 the local information. A query mechanism also has to be available
49 for checking local entries, as well as inquiring about data from
58 Farrell, Schulze, Pleitner & Baldoni [Page 1]
60 RFC 1712 DNS Encoding of Geographical Location November 1994
65 The Internet continues to grow at an ever increasing rate with IP
66 numbers allocated on a first-come-first-serve basis. Deciding when
67 and how to setup a database of geographical information about
68 internet hosts presented a number of options. The uumap project
69 [UU85] was the first serious attempt to collect geographical location
70 data from sites and store it centrally. This project met with
71 limited success because of the difficulty in maintaining and updating
72 a large central database. Another problem was the lack of tools for
73 the checking the data supplied, this problem resulted in some
74 erroneous data entering the database.
78 Using an SNMP get request on the sysLocation MIB (Management
79 Information Base) variable was also an option, however this would
80 require the host to be running an appropriate agent with public read
81 access. It was also felt that MIB data should reflect local
82 management data (e.g., "this" host is on level 5 room 74) rather than
83 a hosts geographical position. This view is supported in the
84 examples given in literature in this area [ROSE91].
88 The X.500 Directory service [X.500.88] defined as part of the ISO
89 standards also appears as a potential provider of geographical
90 location data. However due to the limited implementations of this
91 service it was decided to defer this until this service gains wider
92 use and acceptance within the Internet community.
96 The DNS [Mock87a][Mock87b] represents an existing system ideally
97 suited to the provision of host specific information. The DNS is a
98 widely used and well-understood mechanism for providing a distributed
99 database of such information and its extensible nature allows it to
100 be used to disseminate virtually any information. The most commonly
101 used DNS implementation is the Berkeley Internet Name Domain server
102 BIND [UCB89]. The information we wished to make available needed to
103 be updated locally but available globally; a perfect match with the
104 services provided by the DNS. Current DNS servers provide a variety
105 of useful information about hosts in their domain but lack the
106 ability to report a host's geographical location.
114 Farrell, Schulze, Pleitner & Baldoni [Page 2]
116 RFC 1712 DNS Encoding of Geographical Location November 1994
122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
124 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
126 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
132 LONGITUDE The real number describing the longitude encoded as a
133 printable string. The precision is limited by 256 charcters
134 within the range -90..90 degrees. Positive numbers
135 indicate locations north of the equator.
137 LATITUDE The real number describing the latitude encoded as a
138 printable string. The precision is limited by 256 charcters
139 within the range -180..180 degrees. Positive numbers
140 indicate locations east of the prime meridian.
142 ALTITUDE The real number describing the altitude (in meters) from
143 mean sea-level encoded as a printable string. The precision
144 is limited by 256 charcters. Positive numbers indicate
145 locations above mean sea-level.
147 Latitude/Longitude/Altitude values are encoded as strings as to avoid
148 the precision limitations imposed by encoding as unsigned integers.
149 Although this might not be considered optimal, it allows for a very
150 high degree of precision with an acceptable average encoded record
155 The geographical location is defined with the mnemonic GPOS and type
158 GPOS has the following format:
159 <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
161 A floating point format was chosen to specify geographical locations
162 for reasons of simplicity. This also guarantees a concise
163 unambiguous description of a location by enforcing three compulsory
164 numerical values to be specified.
170 Farrell, Schulze, Pleitner & Baldoni [Page 3]
172 RFC 1712 DNS Encoding of Geographical Location November 1994
175 The owner, ttl, and class fields are optional and default to the last
176 defined value if omitted. The longitude is a floating point number
177 ranging from -90 to 90 with positive values indicating locations
178 north of the equator. For example Perth, Western Australia is
179 located at 32^ 7` 19" south of the equator which would be specified
180 as -32.68820. The latitude is a number ranging from -180.0 to 180.0.
181 For example Perth, Western Australia is located at 116^ 2' 25" east
182 of the prime meridian which would be specified as 116.86520. Curtin
183 University, Perth is also 10 meters above sea-level.
185 The valid GPOS record for a host at Curtin University in Perth
186 Western Australia would therefore be:
188 GPOS -32.6882 116.8652 10.0
190 There is no limit imposed on the number of decimal places, although
191 the length of the encoded string is limited to 256 characters for
192 each field. It is also suggested that administrators limit their
193 entries to the minimum number of necessary characters in each field.
195 5. Master File Format
197 Each host requires its own GPOS field in the corresponding DNS RR to
198 explicitly specify its geographical location and altitude. If the
199 GPOS field is omitted, a DNS enquiry will return no position
200 information for that host.
202 Consider the following example:
204 ; Authoritative data for cs.curtin.edu.au.
206 @ IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
208 94070503 ; Serial (yymmddnn)
209 10800 ; Refresh (3 hours)
210 3600 ; Retry (1 hour)
211 3600000 ; Expire (1000 hours)
212 86400 ; Minimum (24 hours)
215 IN NS marsh.cs.curtin.edu.au.
219 IN HINFO SGI-Indigo IRIX-4.0.5F
220 IN GPOS -32.6882 116.8652 10.0
226 Farrell, Schulze, Pleitner & Baldoni [Page 4]
228 RFC 1712 DNS Encoding of Geographical Location November 1994
231 lillee IN A 134.7.1.2
233 IN HINFO SGI-Indigo IRIX-4.0.5F
234 IN GPOS -32.6882 116.8652 10.0
236 hinault IN A 134.7.1.23
238 IN HINFO SUN-IPC SunOS-4.1.3
239 IN GPOS -22.6882 116.8652 250.0
241 merckx IN A 134.7.1.24
243 IN HINFO SUN-IPC SunOS-4.1.1
245 ambrose IN A 134.7.1.99
247 IN HINFO SGI-CHALLENGE_L IRIX-5.2
248 IN GPOS -32.6882 116.8652 10.0
250 The hosts marsh, lillee, and ambrose are all at the same geographical
251 location, Perth Western Australia (-32.68820 116.86520). The host
252 hinault is at a different geographical location, 10 degrees north of
253 Perth in the mountains (-22.6882 116.8652 250.0). For security
254 reasons we do not wish to give the location of the host merckx.
256 Although the GPOS clause is not a standard entry within BIND
257 configuration files, most vendor implementations seem to ignore
258 whatever is not understood upon startup of the DNS. Usually this
259 will result in a number of warnings appearing in system log files,
260 but in no way alters naming information or impedes the DNS from
261 performing its normal duties.
282 Farrell, Schulze, Pleitner & Baldoni [Page 5]
284 RFC 1712 DNS Encoding of Geographical Location November 1994
289 [ROSE91] Rose M., "The Simple Book: An Introduction to
290 Management of TCP/IP-based Internets", Prentice-Hall,
291 Englewood Cliffs, New Jersey, 1991.
293 [X.500.88] CCITT: The Directory - Overview of Concepts, Models
294 and Services", Recommendations X.500 - X.521.
296 [Har82] Harrenstein K, Stahl M., and E. Feinler,
297 "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
299 [Mock87a] Mockapetris P., "Domain Names - Concepts and
300 Facilities", STD 13, RFC 1034, USC/Information
301 Sciences Institute, November 1987.
303 [Mock87b] Mockapetris P., "Domain Names - Implementation and
304 Specification", STD 13, RFC 1035, USC/Information
305 Sciences Institute, November 1987.
307 [FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving the
308 Routing and Addressing of IP", IEEE Network
309 Vol.7, No. 3, pp. 11-15, May 1993.
311 [VJ89] Jacobsen V., "The Traceroute(8) Manual Page",
312 Lawrence Berkeley Laboratory, Berkeley,
315 [UCB89] University of California, "BIND: Berkeley Internet
316 Name Domain Server", 1989.
317 [UU85] UUCP Mapping Project, Software available via
318 anonymous FTP from ftp.uu.net., 1985.
320 8. Security Considerations
322 Once information has been entered into the DNS, it is considered
338 Farrell, Schulze, Pleitner & Baldoni [Page 6]
340 RFC 1712 DNS Encoding of Geographical Location November 1994
343 9. Authors' Addresses
346 Department of Computer Science
347 Curtin University of technology
351 EMail: craig@cs.curtin.edu.au
355 Department of Computer Science
356 Curtin University of technology
360 EMail: mike@cs.curtin.edu.au
364 Department of Computer Science
365 Curtin University of technology
369 EMail: pleitner@cs.curtin.edu.au
373 Department of Computer Science
374 Curtin University of technology
378 EMail: flint@cs.curtin.edu.au
394 Farrell, Schulze, Pleitner & Baldoni [Page 7]