7 Network Working Group C. Davis
8 Request for Comments: 1876 Kapor Enterprises
9 Updates: 1034, 1035 P. Vixie
10 Category: Experimental Vixie Enterprises
18 A Means for Expressing Location Information in the Domain Name System
22 This memo defines an Experimental Protocol for the Internet
23 community. This memo does not specify an Internet standard of any
24 kind. Discussion and suggestions for improvement are requested.
25 Distribution of this memo is unlimited.
29 This memo defines a new DNS RR type for experimental purposes. This
30 RFC describes a mechanism to allow the DNS to carry location
31 information about hosts, networks, and subnets. Such information for
32 a small subset of hosts is currently contained in the flat-file UUCP
33 maps. However, just as the DNS replaced the use of HOSTS.TXT to
34 carry host and network address information, it is possible to replace
35 the UUCP maps as carriers of location information.
37 This RFC defines the format of a new Resource Record (RR) for the
38 Domain Name System (DNS), and reserves a corresponding DNS type
39 mnemonic (LOC) and numerical code (29).
41 This RFC assumes that the reader is familiar with the DNS [RFC 1034,
42 RFC 1035]. The data shown in our examples is for pedagogical use and
43 does not necessarily reflect the real Internet.
58 Davis, et al Experimental [Page 1]
60 RFC 1876 Location Information in the DNS January 1996
66 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
68 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
69 2| HORIZ PRE | VERT PRE |
70 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
72 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
74 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
76 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
78 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
80 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
82 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
87 VERSION Version number of the representation. This must be zero.
88 Implementations are required to check this field and make
89 no assumptions about the format of unrecognized versions.
91 SIZE The diameter of a sphere enclosing the described entity, in
92 centimeters, expressed as a pair of four-bit unsigned
93 integers, each ranging from zero to nine, with the most
94 significant four bits representing the base and the second
95 number representing the power of ten by which to multiply
96 the base. This allows sizes from 0e0 (<1cm) to 9e9
97 (90,000km) to be expressed. This representation was chosen
98 such that the hexadecimal representation can be read by
99 eye; 0x15 = 1e5. Four-bit values greater than 9 are
100 undefined, as are values with a base of zero and a non-zero
103 Since 20000000m (represented by the value 0x29) is greater
104 than the equatorial diameter of the WGS 84 ellipsoid
105 (12756274m), it is therefore suitable for use as a
108 HORIZ PRE The horizontal precision of the data, in centimeters,
109 expressed using the same representation as SIZE. This is
110 the diameter of the horizontal "circle of error", rather
114 Davis, et al Experimental [Page 2]
116 RFC 1876 Location Information in the DNS January 1996
119 than a "plus or minus" value. (This was chosen to match
120 the interpretation of SIZE; to get a "plus or minus" value,
123 VERT PRE The vertical precision of the data, in centimeters,
124 expressed using the sane representation as for SIZE. This
125 is the total potential vertical error, rather than a "plus
126 or minus" value. (This was chosen to match the
127 interpretation of SIZE; to get a "plus or minus" value,
128 divide by 2.) Note that if altitude above or below sea
129 level is used as an approximation for altitude relative to
130 the [WGS 84] ellipsoid, the precision value should be
133 LATITUDE The latitude of the center of the sphere described by the
134 SIZE field, expressed as a 32-bit integer, most significant
135 octet first (network standard byte order), in thousandths
136 of a second of arc. 2^31 represents the equator; numbers
137 above that are north latitude.
139 LONGITUDE The longitude of the center of the sphere described by the
140 SIZE field, expressed as a 32-bit integer, most significant
141 octet first (network standard byte order), in thousandths
142 of a second of arc, rounded away from the prime meridian.
143 2^31 represents the prime meridian; numbers above that are
146 ALTITUDE The altitude of the center of the sphere described by the
147 SIZE field, expressed as a 32-bit integer, most significant
148 octet first (network standard byte order), in centimeters,
149 from a base of 100,000m below the [WGS 84] reference
150 spheroid used by GPS (semimajor axis a=6378137.0,
151 reciprocal flattening rf=298.257223563). Altitude above
152 (or below) sea level may be used as an approximation of
153 altitude relative to the the [WGS 84] spheroid, though due
154 to the Earth's surface not being a perfect spheroid, there
155 will be differences. (For example, the geoid (which sea
156 level approximates) for the continental US ranges from 10
157 meters to 50 meters below the [WGS 84] spheroid.
158 Adjustments to ALTITUDE and/or VERT PRE will be necessary
159 in most cases. The Defense Mapping Agency publishes geoid
160 height values relative to the [WGS 84] ellipsoid.
170 Davis, et al Experimental [Page 3]
172 RFC 1876 Location Information in the DNS January 1996
175 3. Master File Format
177 The LOC record is expressed in a master file in the following format:
179 <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
180 {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
183 (The parentheses are used for multi-line data as specified in [RFC
188 d1: [0 .. 90] (degrees latitude)
189 d2: [0 .. 180] (degrees longitude)
190 m1, m2: [0 .. 59] (minutes latitude/longitude)
191 s1, s2: [0 .. 59.999] (seconds latitude/longitude)
192 alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
193 siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
195 If omitted, minutes and seconds default to zero, size defaults to 1m,
196 horizontal precision defaults to 10000m, and vertical precision
197 defaults to 10m. These defaults are chosen to represent typical
198 ZIP/postal code area sizes, since it is often easy to find
199 approximate geographical location by ZIP/postal code.
204 ;;; note that these data would not all appear in one zone file
207 ;; network LOC RR derived from ZIP data. note use of precision defaults
208 cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m
210 ;; higher-precision host LOC RR. note use of vertical precision default
211 loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W
214 pipex.net. LOC 52 14 05 N 00 08 50 E 10m
216 curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m
218 rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W
226 Davis, et al Experimental [Page 4]
228 RFC 1876 Location Information in the DNS January 1996
231 5. Application use of the LOC RR
235 Some uses for the LOC RR have already been suggested, including the
236 USENET backbone flow maps, a "visual traceroute" application showing
237 the geographical path of an IP packet, and network management
238 applications that could use LOC RRs to generate a map of hosts and
239 routers being managed.
241 5.2 Search Algorithms
243 This section specifies how to use the DNS to translate domain names
244 and/or IP addresses into location information.
246 If an application wishes to have a "fallback" behavior, displaying a
247 less precise or larger area when a host does not have an associated
248 LOC RR, it MAY support use of the algorithm in section 5.2.3, as
249 noted in sections 5.2.1 and 5.2.2. If fallback is desired, this
250 behaviour is the RECOMMENDED default, but in some cases it may need
251 to be modified based on the specific requirements of the application
254 This search algorithm is designed to allow network administrators to
255 specify the location of a network or subnet without requiring LOC RR
256 data for each individual host. For example, a computer lab with 24
257 workstations, all of which are on the same subnet and in basically
258 the same location, would only need a LOC RR for the subnet.
259 (However, if the file server's location has been more precisely
260 measured, a separate LOC RR for it can be placed in the DNS.)
262 5.2.1 Searching by Name
264 If the application is beginning with a name, rather than an IP
265 address (as the USENET backbone flow maps do), it MUST check for a
266 LOC RR associated with that name. (CNAME records should be followed
267 as for any other RR type.)
269 If there is no LOC RR for that name, all A records (if any)
270 associated with the name MAY be checked for network (or subnet) LOC
271 RRs using the "Searching by Network or Subnet" algorithm (5.2.3). If
272 multiple A records exist and have associated network or subnet LOC
273 RRs, the application may choose to use any, some, or all of the LOC
274 RRs found, possibly in combination. It is suggested that multi-homed
275 hosts have LOC RRs for their name in the DNS to avoid any ambiguity
282 Davis, et al Experimental [Page 5]
284 RFC 1876 Location Information in the DNS January 1996
287 Note that domain names that do not have associated A records must
288 have a LOC RR associated with their name in order for location
289 information to be accessible.
291 5.2.2 Searching by Address
293 If the application is beginning with an IP address (as a "visual
294 traceroute" application might be) it MUST first map the address to a
295 name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
296 5.2.1), then check for a LOC RR associated with that name.
298 If there is no LOC RR for the name, the address MAY be checked for
299 network (or subnet) LOC RRs using the "Searching by Network or
300 Subnet" algorithm (5.2.3).
302 5.2.3 Searching by Network or Subnet
304 Even if a host's name does not have any associated LOC RRs, the
305 network(s) or subnet(s) it is on may. If the application wishes to
306 search for such less specific data, the following algorithm SHOULD be
307 followed to find a network or subnet LOC RR associated with the IP
308 address. This algorithm is adapted slightly from that specified in
309 [RFC 1101], sections 4.3 and 4.4.
311 Since subnet LOC RRs are (if present) more specific than network LOC
312 RRs, it is best to use them if available. In order to do so, we
313 build a stack of network and subnet names found while performing the
314 [RFC 1101] search, then work our way down the stack until a LOC RR is
317 1. create a host-zero address using the network portion of the IP
318 address (one, two, or three bytes for class A, B, or C networks,
319 respectively). For example, for the host 128.9.2.17, on the class
320 B network 128.9, this would result in the address "128.9.0.0".
322 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
325 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
328 Push the name "isi-net.isi.edu" onto the stack of names to be
329 searched for LOC RRs later.
338 Davis, et al Experimental [Page 6]
340 RFC 1876 Location Information in the DNS January 1996
343 3. Since an A RR was found, repeat using mask from RR
344 (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
347 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
350 Push the name "div2-subnet.isi.edu" onto the stack of names to be
351 searched for LOC RRs later.
353 4. Since another A RR was found, repeat using mask 255.255.255.240
354 (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
357 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
359 Push the name "inc-subsubnet.isi.edu" onto the stack of names to
360 be searched for LOC RRs later.
362 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
363 more subnet levels to search. We now pop the top name from the
364 stack and check for an associated LOC RR. Repeat until a LOC RR
367 In this case, assume that inc-subsubnet.isi.edu does not have an
368 associated LOC RR, but that div2-subnet.isi.edu does. We will
369 then use div2-subnet.isi.edu's LOC RR as an approximation of this
370 host's location. (Note that even if isi-net.isi.edu has a LOC RR,
371 it will not be used if a subnet also has a LOC RR.)
373 5.3 Applicability to non-IN Classes and non-IP Addresses
375 The LOC record is defined for all RR classes, and may be used with
376 non-IN classes such as HS and CH. The semantics of such use are not
377 defined by this memo.
379 The search algorithm in section 5.2.3 may be adapted to other
380 addressing schemes by extending [RFC 1101]'s encoding of network
381 names to cover those schemes. Such extensions are not defined by
394 Davis, et al Experimental [Page 7]
396 RFC 1876 Location Information in the DNS January 1996
401 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
402 STD 13, RFC 1034, USC/Information Sciences Institute,
405 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
406 Specification", STD 13, RFC 1035, USC/Information Sciences
407 Institute, November 1987.
409 [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
410 Types", RFC 1101, USC/Information Sciences Institute,
413 [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
414 Definition and Relationships with Local Geodetic Systems;
415 Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
418 7. Security Considerations
420 High-precision LOC RR information could be used to plan a penetration
421 of physical security, leading to potential denial-of-machine attacks.
422 To avoid any appearance of suggesting this method to potential
423 attackers, we declined the opportunity to name this RR "ICBM".
425 8. Authors' Addresses
427 The authors as a group can be reached as <loc@pipex.net>.
430 Kapor Enterprises, Inc.
431 238 Main Street, Suite 400
434 Phone: +1 617 576 4532
443 Phone: +1 415 747 0204
450 Davis, et al Experimental [Page 8]
452 RFC 1876 Location Information in the DNS January 1996
456 Public IP Exchange Ltd (PIPEX)
461 Phone: +44 1223 250250
469 Birmingham Business Park
473 Phone: +44 121 717 4444
474 EMail: idickins@fore.co.uk
506 Davis, et al Experimental [Page 9]
508 RFC 1876 Location Information in the DNS January 1996
511 Appendix A: Sample Conversion Routines
514 * routines to convert between on-the-wire RR format and zone file
515 * format. Does not contain conversion to/from decimal degrees;
516 * divide or multiply by 60*60*1000 for that.
519 static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
520 1000000,10000000,100000000,1000000000};
522 /* takes an XeY precision/size value, returns a string representation.*/
527 static char retbuf[sizeof("90000000.00")];
529 int mantissa, exponent;
531 mantissa = (int)((prec >> 4) & 0x0f) % 10;
532 exponent = (int)((prec >> 0) & 0x0f) % 10;
534 val = mantissa * poweroften[exponent];
536 (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
540 /* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
542 precsize_aton(strptr)
545 unsigned int mval = 0, cmval = 0;
548 register int exponent;
549 register int mantissa;
554 mval = mval * 10 + (*cp++ - '0');
556 if (*cp == '.') { /* centimeters */
562 Davis, et al Experimental [Page 10]
564 RFC 1876 Location Information in the DNS January 1996
567 cmval = (*cp++ - '0') * 10;
569 cmval += (*cp++ - '0');
573 cmval = (mval * 100) + cmval;
575 for (exponent = 0; exponent < 9; exponent++)
576 if (cmval < poweroften[exponent+1])
579 mantissa = cmval / poweroften[exponent];
583 retval = (mantissa << 4) | exponent;
590 /* converts ascii lat/lon to unsigned encoded 32-bit number.
593 latlon2ul(latlonstrptr,which)
599 int deg = 0, min = 0, secs = 0, secsfrac = 0;
604 deg = deg * 10 + (*cp++ - '0');
613 min = min * 10 + (*cp++ - '0');
618 Davis, et al Experimental [Page 11]
620 RFC 1876 Location Information in the DNS January 1996
630 secs = secs * 10 + (*cp++ - '0');
632 if (*cp == '.') { /* decimal seconds */
635 secsfrac = (*cp++ - '0') * 100;
637 secsfrac += (*cp++ - '0') * 10;
639 secsfrac += (*cp++ - '0');
645 while (!isspace(*cp)) /* if any trailing garbage */
655 retval = ((unsigned)1<<31)
656 + (((((deg * 60) + min) * 60) + secs) * 1000)
661 retval = ((unsigned)1<<31)
662 - (((((deg * 60) + min) * 60) + secs) * 1000)
666 retval = 0; /* invalid value -- indicates error */
674 Davis, et al Experimental [Page 12]
676 RFC 1876 Location Information in the DNS January 1996
681 *which = 1; /* latitude */
685 *which = 2; /* longitude */
688 *which = 0; /* error */
692 cp++; /* skip the hemisphere */
694 while (!isspace(*cp)) /* if any trailing garbage */
697 while (isspace(*cp)) /* move to next field */
705 /* converts a zone file representation in a string to an RDATA
706 * on-the-wire representation. */
708 loc_aton(ascii, binary)
712 const char *cp, *maxcp;
715 u_int32_t latit = 0, longit = 0, alt = 0;
716 u_int32_t lltemp1 = 0, lltemp2 = 0;
717 int altmeters = 0, altfrac = 0, altsign = 1;
718 u_int8_t hp = 0x16; /* default = 1e6 cm = 10000.00m = 10km */
719 u_int8_t vp = 0x13; /* default = 1e3 cm = 10.00m */
720 u_int8_t siz = 0x12; /* default = 1e2 cm = 1.00m */
721 int which1 = 0, which2 = 0;
724 maxcp = cp + strlen(ascii);
726 lltemp1 = latlon2ul(&cp, &which1);
730 Davis, et al Experimental [Page 13]
732 RFC 1876 Location Information in the DNS January 1996
735 lltemp2 = latlon2ul(&cp, &which2);
737 switch (which1 + which2) {
738 case 3: /* 1 + 2, the only valid combination */
739 if ((which1 == 1) && (which2 == 2)) { /* normal case */
742 } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
745 } else { /* some kind of brokenness */
749 default: /* we didn't get one of each */
763 altmeters = altmeters * 10 + (*cp++ - '0');
765 if (*cp == '.') { /* decimal meters */
768 altfrac = (*cp++ - '0') * 10;
770 altfrac += (*cp++ - '0');
775 alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
777 while (!isspace(*cp) && (cp < maxcp))
778 /* if trailing garbage or m */
781 while (isspace(*cp) && (cp < maxcp))
786 Davis, et al Experimental [Page 14]
788 RFC 1876 Location Information in the DNS January 1996
794 siz = precsize_aton(&cp);
796 while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
799 while (isspace(*cp) && (cp < maxcp))
805 hp = precsize_aton(&cp);
807 while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
810 while (isspace(*cp) && (cp < maxcp))
816 vp = precsize_aton(&cp);
821 *bcp++ = (u_int8_t) 0; /* version byte */
829 return (16); /* size of RR in octets */
832 /* takes an on-the-wire LOC RR and prints it in zone file
833 * (human readable) format. */
835 loc_ntoa(binary,ascii)
836 const u_char *binary;
842 Davis, et al Experimental [Page 15]
844 RFC 1876 Location Information in the DNS January 1996
847 static char tmpbuf[255*3];
850 register const u_char *rcp;
852 int latdeg, latmin, latsec, latsecfrac;
853 int longdeg, longmin, longsec, longsecfrac;
854 char northsouth, eastwest;
855 int altmeters, altfrac, altsign;
857 const int referencealt = 100000 * 100;
859 int32_t latval, longval, altval;
861 u_int8_t sizeval, hpval, vpval, versionval;
863 char *sizestr, *hpstr, *vpstr;
875 sprintf(cp,"; error: unknown LOC RR version");
885 latval = (templ - ((unsigned)1<<31));
888 longval = (templ - ((unsigned)1<<31));
891 if (templ < referencealt) { /* below WGS 84 spheroid */
892 altval = referencealt - templ;
898 Davis, et al Experimental [Page 16]
900 RFC 1876 Location Information in the DNS January 1996
903 altval = templ - referencealt;
914 latsecfrac = latval % 1000;
915 latval = latval / 1000;
916 latsec = latval % 60;
917 latval = latval / 60;
918 latmin = latval % 60;
919 latval = latval / 60;
929 longsecfrac = longval % 1000;
930 longval = longval / 1000;
931 longsec = longval % 60;
932 longval = longval / 60;
933 longmin = longval % 60;
934 longval = longval / 60;
937 altfrac = altval % 100;
938 altmeters = (altval / 100) * altsign;
940 sizestr = savestr(precsize_ntoa(sizeval));
941 hpstr = savestr(precsize_ntoa(hpval));
942 vpstr = savestr(precsize_ntoa(vpval));
945 "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
947 latdeg, latmin, latsec, latsecfrac, northsouth,
948 longdeg, longmin, longsec, longsecfrac, eastwest,
949 altmeters, altfrac, sizestr, hpstr, vpstr);
954 Davis, et al Experimental [Page 17]
956 RFC 1876 Location Information in the DNS January 1996
1010 Davis, et al Experimental [Page 18]