contrib/bind9/doc/rfc/rfc1712.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         C. Farrell
   8 Request for Comments: 1712                                    M. Schulze
   9 Category: Experimental                                       S. Pleitner
  10                                                               D. Baldoni
  11                                          Curtin University of Technology
  12                                                            November 1994
  13
  14
  15                  DNS Encoding of Geographical Location
  16
  17 Status of this Memo
  18
  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.
  23
  24 Abstract
  25
  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.
  32
  33 1. Introduction
  34
  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.
  43
  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
  50    non-local domains.
  51
  52
  53
  54
  55
  56
  57
  58 Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
  59 \f
  60 RFC 1712         DNS Encoding of Geographical Location     November 1994
  61
  62
  63 2. Background
  64
  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.
  75
  76 2.1 SNMP:
  77
  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].
  85
  86 2.2 X500:
  87
  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.
  93
  94 2.3 BIND:
  95
  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.
 107
 108
 109
 110
 111
 112
 113
 114 Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
 115 \f
 116 RFC 1712         DNS Encoding of Geographical Location     November 1994
 117
 118
 119 3. RDATA Format
 120
 121         MSB                                        LSB
 122         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 123         /                 LONGITUDE                  /
 124         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 125         /                  LATITUDE                  /
 126         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 127         /                  ALTITUDE                  /
 128         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 129
 130    where:
 131
 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.
 136
 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.
 141
 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.
 146
 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
 151    length.
 152
 153 4. The GPOS RR
 154
 155    The geographical location is defined with the mnemonic GPOS and type
 156    code 27.
 157
 158    GPOS has the following format:
 159            <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
 160
 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.
 165
 166
 167
 168
 169
 170 Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
 171 \f
 172 RFC 1712         DNS Encoding of Geographical Location     November 1994
 173
 174
 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.
 184
 185    The valid GPOS record for a host at Curtin University in  Perth
 186    Western Australia would therefore be:
 187
 188                 GPOS -32.6882 116.8652 10.0
 189
 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.
 194
 195 5. Master File Format
 196
 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.
 201
 202    Consider the following example:
 203
 204 ; Authoritative data for cs.curtin.edu.au.
 205 ;
 206 @     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
 207                 (
 208                         94070503        ; Serial (yymmddnn)
 209                         10800           ; Refresh (3 hours)
 210                         3600            ; Retry (1 hour)
 211                         3600000         ; Expire (1000 hours)
 212                         86400           ; Minimum (24 hours)
 213                 )
 214
 215                 IN      NS      marsh.cs.curtin.edu.au.
 216
 217 marsh           IN      A       134.7.1.1
 218                 IN      MX      0       marsh
 219                 IN      HINFO   SGI-Indigo IRIX-4.0.5F
 220                 IN      GPOS    -32.6882 116.8652 10.0
 221 ftp             IN      CNAME   marsh
 222
 223
 224
 225
 226 Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
 227 \f
 228 RFC 1712         DNS Encoding of Geographical Location     November 1994
 229
 230
 231 lillee          IN      A       134.7.1.2
 232                 IN      MX      0       marsh
 233                 IN      HINFO   SGI-Indigo IRIX-4.0.5F
 234                 IN      GPOS    -32.6882 116.8652 10.0
 235
 236 hinault         IN      A       134.7.1.23
 237                 IN      MX      0       marsh
 238                 IN      HINFO   SUN-IPC SunOS-4.1.3
 239                 IN      GPOS    -22.6882 116.8652 250.0
 240
 241 merckx          IN      A       134.7.1.24
 242                 IN      MX      0       marsh
 243                 IN      HINFO   SUN-IPC SunOS-4.1.1
 244
 245 ambrose         IN      A       134.7.1.99
 246                 IN      MX      0       marsh
 247                 IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
 248                 IN      GPOS    -32.6882 116.8652 10.0
 249
 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.
 255
 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.
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
 283 \f
 284 RFC 1712         DNS Encoding of Geographical Location     November 1994
 285
 286
 287 7. References
 288
 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.
 292
 293    [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
 294                    and Services", Recommendations X.500 - X.521.
 295
 296    [Har82]         Harrenstein K, Stahl M., and E. Feinler,
 297                    "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
 298
 299    [Mock87a]       Mockapetris P., "Domain Names - Concepts and
 300                    Facilities", STD 13, RFC 1034, USC/Information
 301                    Sciences Institute, November 1987.
 302
 303    [Mock87b]       Mockapetris P., "Domain Names - Implementation and
 304                    Specification", STD 13, RFC 1035, USC/Information
 305                    Sciences Institute, November 1987.
 306
 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.
 310
 311    [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
 312                    Lawrence Berkeley Laboratory, Berkeley,
 313                    CA, February 1989.
 314
 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.
 319
 320 8. Security Considerations
 321
 322    Once information has been entered into the DNS, it is considered
 323    public.
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
 339 \f
 340 RFC 1712         DNS Encoding of Geographical Location     November 1994
 341
 342
 343 9. Authors' Addresses
 344
 345    Craig Farrell
 346    Department of Computer Science
 347    Curtin University of technology
 348    GPO Box U1987 Perth,
 349    Western Australia
 350
 351    EMail: craig@cs.curtin.edu.au
 352
 353
 354    Mike Schulze
 355    Department of Computer Science
 356    Curtin University of technology
 357    GPO Box U1987 Perth,
 358    Western Australia
 359
 360    EMail: mike@cs.curtin.edu.au
 361
 362
 363    Scott Pleitner
 364    Department of Computer Science
 365    Curtin University of technology
 366    GPO Box U1987 Perth,
 367    Western Australia
 368
 369    EMail: pleitner@cs.curtin.edu.au
 370
 371
 372    Daniel Baldoni
 373    Department of Computer Science
 374    Curtin University of technology
 375    GPO Box U1987 Perth,
 376    Western Australia
 377
 378    EMail: flint@cs.curtin.edu.au
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
 395 \f