summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc1876.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1876.txt')
-rw-r--r--doc/rfc/rfc1876.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc1876.txt b/doc/rfc/rfc1876.txt
new file mode 100644
index 0000000..a289cff
--- /dev/null
+++ b/doc/rfc/rfc1876.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group C. Davis
+Request for Comments: 1876 Kapor Enterprises
+Updates: 1034, 1035 P. Vixie
+Category: Experimental Vixie Enterprises
+ T. Goodwin
+ FORE Systems
+ I. Dickinson
+ University of Warwick
+ January 1996
+
+
+ A Means for Expressing Location Information in the Domain Name System
+
+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.
+
+1. Abstract
+
+ This memo defines a new DNS RR type for experimental purposes. This
+ RFC describes a mechanism to allow the DNS to carry location
+ information about hosts, networks, and subnets. Such information for
+ a small subset of hosts is currently contained in the flat-file UUCP
+ maps. However, just as the DNS replaced the use of HOSTS.TXT to
+ carry host and network address information, it is possible to replace
+ the UUCP maps as carriers of location information.
+
+ This RFC defines the format of a new Resource Record (RR) for the
+ Domain Name System (DNS), and reserves a corresponding DNS type
+ mnemonic (LOC) and numerical code (29).
+
+ This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+ RFC 1035]. The data shown in our examples is for pedagogical use and
+ does not necessarily reflect the real Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 1]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+2. RDATA Format
+
+ MSB LSB
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 0| VERSION | SIZE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 2| HORIZ PRE | VERT PRE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 4| LATITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 6| LATITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 8| LONGITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 10| LONGITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 12| ALTITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 14| ALTITUDE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ (octet)
+
+where:
+
+VERSION Version number of the representation. This must be zero.
+ Implementations are required to check this field and make
+ no assumptions about the format of unrecognized versions.
+
+SIZE The diameter of a sphere enclosing the described entity, in
+ centimeters, expressed as a pair of four-bit unsigned
+ integers, each ranging from zero to nine, with the most
+ significant four bits representing the base and the second
+ number representing the power of ten by which to multiply
+ the base. This allows sizes from 0e0 (<1cm) to 9e9
+ (90,000km) to be expressed. This representation was chosen
+ such that the hexadecimal representation can be read by
+ eye; 0x15 = 1e5. Four-bit values greater than 9 are
+ undefined, as are values with a base of zero and a non-zero
+ exponent.
+
+ Since 20000000m (represented by the value 0x29) is greater
+ than the equatorial diameter of the WGS 84 ellipsoid
+ (12756274m), it is therefore suitable for use as a
+ "worldwide" size.
+
+HORIZ PRE The horizontal precision of the data, in centimeters,
+ expressed using the same representation as SIZE. This is
+ the diameter of the horizontal "circle of error", rather
+
+
+
+Davis, et al Experimental [Page 2]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ than a "plus or minus" value. (This was chosen to match
+ the interpretation of SIZE; to get a "plus or minus" value,
+ divide by 2.)
+
+VERT PRE The vertical precision of the data, in centimeters,
+ expressed using the sane representation as for SIZE. This
+ is the total potential vertical error, rather than a "plus
+ or minus" value. (This was chosen to match the
+ interpretation of SIZE; to get a "plus or minus" value,
+ divide by 2.) Note that if altitude above or below sea
+ level is used as an approximation for altitude relative to
+ the [WGS 84] ellipsoid, the precision value should be
+ adjusted.
+
+LATITUDE The latitude of the center of the sphere described by the
+ SIZE field, expressed as a 32-bit integer, most significant
+ octet first (network standard byte order), in thousandths
+ of a second of arc. 2^31 represents the equator; numbers
+ above that are north latitude.
+
+LONGITUDE The longitude of the center of the sphere described by the
+ SIZE field, expressed as a 32-bit integer, most significant
+ octet first (network standard byte order), in thousandths
+ of a second of arc, rounded away from the prime meridian.
+ 2^31 represents the prime meridian; numbers above that are
+ east longitude.
+
+ALTITUDE The altitude of the center of the sphere described by the
+ SIZE field, expressed as a 32-bit integer, most significant
+ octet first (network standard byte order), in centimeters,
+ from a base of 100,000m below the [WGS 84] reference
+ spheroid used by GPS (semimajor axis a=6378137.0,
+ reciprocal flattening rf=298.257223563). Altitude above
+ (or below) sea level may be used as an approximation of
+ altitude relative to the the [WGS 84] spheroid, though due
+ to the Earth's surface not being a perfect spheroid, there
+ will be differences. (For example, the geoid (which sea
+ level approximates) for the continental US ranges from 10
+ meters to 50 meters below the [WGS 84] spheroid.
+ Adjustments to ALTITUDE and/or VERT PRE will be necessary
+ in most cases. The Defense Mapping Agency publishes geoid
+ height values relative to the [WGS 84] ellipsoid.
+
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 3]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+3. Master File Format
+
+ The LOC record is expressed in a master file in the following format:
+
+ <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
+ {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
+ [vp["m"]]]] )
+
+ (The parentheses are used for multi-line data as specified in [RFC
+ 1035] section 5.1.)
+
+ where:
+
+ d1: [0 .. 90] (degrees latitude)
+ d2: [0 .. 180] (degrees longitude)
+ m1, m2: [0 .. 59] (minutes latitude/longitude)
+ s1, s2: [0 .. 59.999] (seconds latitude/longitude)
+ alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
+ siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
+
+ If omitted, minutes and seconds default to zero, size defaults to 1m,
+ horizontal precision defaults to 10000m, and vertical precision
+ defaults to 10m. These defaults are chosen to represent typical
+ ZIP/postal code area sizes, since it is often easy to find
+ approximate geographical location by ZIP/postal code.
+
+4. Example Data
+
+;;;
+;;; note that these data would not all appear in one zone file
+;;;
+
+;; network LOC RR derived from ZIP data. note use of precision defaults
+cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m
+
+;; higher-precision host LOC RR. note use of vertical precision default
+loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W
+ -24m 1m 200m
+
+pipex.net. LOC 52 14 05 N 00 08 50 E 10m
+
+curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m
+
+rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W
+ -44m 2000m
+
+
+
+
+
+
+Davis, et al Experimental [Page 4]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+5. Application use of the LOC RR
+
+5.1 Suggested Uses
+
+ Some uses for the LOC RR have already been suggested, including the
+ USENET backbone flow maps, a "visual traceroute" application showing
+ the geographical path of an IP packet, and network management
+ applications that could use LOC RRs to generate a map of hosts and
+ routers being managed.
+
+5.2 Search Algorithms
+
+ This section specifies how to use the DNS to translate domain names
+ and/or IP addresses into location information.
+
+ If an application wishes to have a "fallback" behavior, displaying a
+ less precise or larger area when a host does not have an associated
+ LOC RR, it MAY support use of the algorithm in section 5.2.3, as
+ noted in sections 5.2.1 and 5.2.2. If fallback is desired, this
+ behaviour is the RECOMMENDED default, but in some cases it may need
+ to be modified based on the specific requirements of the application
+ involved.
+
+ This search algorithm is designed to allow network administrators to
+ specify the location of a network or subnet without requiring LOC RR
+ data for each individual host. For example, a computer lab with 24
+ workstations, all of which are on the same subnet and in basically
+ the same location, would only need a LOC RR for the subnet.
+ (However, if the file server's location has been more precisely
+ measured, a separate LOC RR for it can be placed in the DNS.)
+
+5.2.1 Searching by Name
+
+ If the application is beginning with a name, rather than an IP
+ address (as the USENET backbone flow maps do), it MUST check for a
+ LOC RR associated with that name. (CNAME records should be followed
+ as for any other RR type.)
+
+ If there is no LOC RR for that name, all A records (if any)
+ associated with the name MAY be checked for network (or subnet) LOC
+ RRs using the "Searching by Network or Subnet" algorithm (5.2.3). If
+ multiple A records exist and have associated network or subnet LOC
+ RRs, the application may choose to use any, some, or all of the LOC
+ RRs found, possibly in combination. It is suggested that multi-homed
+ hosts have LOC RRs for their name in the DNS to avoid any ambiguity
+ in these cases.
+
+
+
+
+
+Davis, et al Experimental [Page 5]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ Note that domain names that do not have associated A records must
+ have a LOC RR associated with their name in order for location
+ information to be accessible.
+
+5.2.2 Searching by Address
+
+ If the application is beginning with an IP address (as a "visual
+ traceroute" application might be) it MUST first map the address to a
+ name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
+ 5.2.1), then check for a LOC RR associated with that name.
+
+ If there is no LOC RR for the name, the address MAY be checked for
+ network (or subnet) LOC RRs using the "Searching by Network or
+ Subnet" algorithm (5.2.3).
+
+5.2.3 Searching by Network or Subnet
+
+ Even if a host's name does not have any associated LOC RRs, the
+ network(s) or subnet(s) it is on may. If the application wishes to
+ search for such less specific data, the following algorithm SHOULD be
+ followed to find a network or subnet LOC RR associated with the IP
+ address. This algorithm is adapted slightly from that specified in
+ [RFC 1101], sections 4.3 and 4.4.
+
+ Since subnet LOC RRs are (if present) more specific than network LOC
+ RRs, it is best to use them if available. In order to do so, we
+ build a stack of network and subnet names found while performing the
+ [RFC 1101] search, then work our way down the stack until a LOC RR is
+ found.
+
+ 1. create a host-zero address using the network portion of the IP
+ address (one, two, or three bytes for class A, B, or C networks,
+ respectively). For example, for the host 128.9.2.17, on the class
+ B network 128.9, this would result in the address "128.9.0.0".
+
+ 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
+ records. Retrieve:
+
+ 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
+ A 255.255.255.0
+
+ Push the name "isi-net.isi.edu" onto the stack of names to be
+ searched for LOC RRs later.
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 6]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ 3. Since an A RR was found, repeat using mask from RR
+ (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
+ Retrieve:
+
+ 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
+ A 255.255.255.240
+
+ Push the name "div2-subnet.isi.edu" onto the stack of names to be
+ searched for LOC RRs later.
+
+ 4. Since another A RR was found, repeat using mask 255.255.255.240
+ (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
+ Retrieve:
+
+ 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
+
+ Push the name "inc-subsubnet.isi.edu" onto the stack of names to
+ be searched for LOC RRs later.
+
+ 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
+ more subnet levels to search. We now pop the top name from the
+ stack and check for an associated LOC RR. Repeat until a LOC RR
+ is found.
+
+ In this case, assume that inc-subsubnet.isi.edu does not have an
+ associated LOC RR, but that div2-subnet.isi.edu does. We will
+ then use div2-subnet.isi.edu's LOC RR as an approximation of this
+ host's location. (Note that even if isi-net.isi.edu has a LOC RR,
+ it will not be used if a subnet also has a LOC RR.)
+
+5.3 Applicability to non-IN Classes and non-IP Addresses
+
+ The LOC record is defined for all RR classes, and may be used with
+ non-IN classes such as HS and CH. The semantics of such use are not
+ defined by this memo.
+
+ The search algorithm in section 5.2.3 may be adapted to other
+ addressing schemes by extending [RFC 1101]'s encoding of network
+ names to cover those schemes. Such extensions are not defined by
+ this memo.
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 7]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+6. References
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ STD 13, RFC 1034, USC/Information Sciences Institute,
+ November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+ [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+ Types", RFC 1101, USC/Information Sciences Institute,
+ April 1989.
+
+ [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
+ Definition and Relationships with Local Geodetic Systems;
+ Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
+ 138-R; CV, KV;
+
+7. Security Considerations
+
+ High-precision LOC RR information could be used to plan a penetration
+ of physical security, leading to potential denial-of-machine attacks.
+ To avoid any appearance of suggesting this method to potential
+ attackers, we declined the opportunity to name this RR "ICBM".
+
+8. Authors' Addresses
+
+ The authors as a group can be reached as <loc@pipex.net>.
+
+ Christopher Davis
+ Kapor Enterprises, Inc.
+ 238 Main Street, Suite 400
+ Cambridge, MA 02142
+
+ Phone: +1 617 576 4532
+ EMail: ckd@kei.com
+
+
+ Paul Vixie
+ Vixie Enterprises
+ Star Route Box 159A
+ Woodside, CA 94062
+
+ Phone: +1 415 747 0204
+ EMail: paul@vix.com
+
+
+
+
+
+Davis, et al Experimental [Page 8]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ Tim Goodwin
+ Public IP Exchange Ltd (PIPEX)
+ 216 The Science Park
+ Cambridge CB4 4WA
+ UK
+
+ Phone: +44 1223 250250
+ EMail: tim@pipex.net
+
+
+ Ian Dickinson
+ FORE Systems
+ 2475 The Crescent
+ Solihull Parkway
+ Birmingham Business Park
+ B37 7YE
+ UK
+
+ Phone: +44 121 717 4444
+ EMail: idickins@fore.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 9]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+Appendix A: Sample Conversion Routines
+
+/*
+ * routines to convert between on-the-wire RR format and zone file
+ * format. Does not contain conversion to/from decimal degrees;
+ * divide or multiply by 60*60*1000 for that.
+ */
+
+static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
+ 1000000,10000000,100000000,1000000000};
+
+/* takes an XeY precision/size value, returns a string representation.*/
+static const char *
+precsize_ntoa(prec)
+ u_int8_t prec;
+{
+ static char retbuf[sizeof("90000000.00")];
+ unsigned long val;
+ int mantissa, exponent;
+
+ mantissa = (int)((prec >> 4) & 0x0f) % 10;
+ exponent = (int)((prec >> 0) & 0x0f) % 10;
+
+ val = mantissa * poweroften[exponent];
+
+ (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
+ return (retbuf);
+}
+
+/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
+static u_int8_t
+precsize_aton(strptr)
+ char **strptr;
+{
+ unsigned int mval = 0, cmval = 0;
+ u_int8_t retval = 0;
+ register char *cp;
+ register int exponent;
+ register int mantissa;
+
+ cp = *strptr;
+
+ while (isdigit(*cp))
+ mval = mval * 10 + (*cp++ - '0');
+
+ if (*cp == '.') { /* centimeters */
+ cp++;
+ if (isdigit(*cp)) {
+
+
+
+Davis, et al Experimental [Page 10]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ cmval = (*cp++ - '0') * 10;
+ if (isdigit(*cp)) {
+ cmval += (*cp++ - '0');
+ }
+ }
+ }
+ cmval = (mval * 100) + cmval;
+
+ for (exponent = 0; exponent < 9; exponent++)
+ if (cmval < poweroften[exponent+1])
+ break;
+
+ mantissa = cmval / poweroften[exponent];
+ if (mantissa > 9)
+ mantissa = 9;
+
+ retval = (mantissa << 4) | exponent;
+
+ *strptr = cp;
+
+ return (retval);
+}
+
+/* converts ascii lat/lon to unsigned encoded 32-bit number.
+ * moves pointer. */
+static u_int32_t
+latlon2ul(latlonstrptr,which)
+ char **latlonstrptr;
+ int *which;
+{
+ register char *cp;
+ u_int32_t retval;
+ int deg = 0, min = 0, secs = 0, secsfrac = 0;
+
+ cp = *latlonstrptr;
+
+ while (isdigit(*cp))
+ deg = deg * 10 + (*cp++ - '0');
+
+ while (isspace(*cp))
+ cp++;
+
+ if (!(isdigit(*cp)))
+ goto fndhemi;
+
+ while (isdigit(*cp))
+ min = min * 10 + (*cp++ - '0');
+
+
+
+
+Davis, et al Experimental [Page 11]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ while (isspace(*cp))
+ cp++;
+
+ if (!(isdigit(*cp)))
+ goto fndhemi;
+
+ while (isdigit(*cp))
+ secs = secs * 10 + (*cp++ - '0');
+
+ if (*cp == '.') { /* decimal seconds */
+ cp++;
+ if (isdigit(*cp)) {
+ secsfrac = (*cp++ - '0') * 100;
+ if (isdigit(*cp)) {
+ secsfrac += (*cp++ - '0') * 10;
+ if (isdigit(*cp)) {
+ secsfrac += (*cp++ - '0');
+ }
+ }
+ }
+ }
+
+ while (!isspace(*cp)) /* if any trailing garbage */
+ cp++;
+
+ while (isspace(*cp))
+ cp++;
+
+ fndhemi:
+ switch (*cp) {
+ case 'N': case 'n':
+ case 'E': case 'e':
+ retval = ((unsigned)1<<31)
+ + (((((deg * 60) + min) * 60) + secs) * 1000)
+ + secsfrac;
+ break;
+ case 'S': case 's':
+ case 'W': case 'w':
+ retval = ((unsigned)1<<31)
+ - (((((deg * 60) + min) * 60) + secs) * 1000)
+ - secsfrac;
+ break;
+ default:
+ retval = 0; /* invalid value -- indicates error */
+ break;
+ }
+
+ switch (*cp) {
+
+
+
+Davis, et al Experimental [Page 12]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ case 'N': case 'n':
+ case 'S': case 's':
+ *which = 1; /* latitude */
+ break;
+ case 'E': case 'e':
+ case 'W': case 'w':
+ *which = 2; /* longitude */
+ break;
+ default:
+ *which = 0; /* error */
+ break;
+ }
+
+ cp++; /* skip the hemisphere */
+
+ while (!isspace(*cp)) /* if any trailing garbage */
+ cp++;
+
+ while (isspace(*cp)) /* move to next field */
+ cp++;
+
+ *latlonstrptr = cp;
+
+ return (retval);
+}
+
+/* converts a zone file representation in a string to an RDATA
+ * on-the-wire representation. */
+u_int32_t
+loc_aton(ascii, binary)
+ const char *ascii;
+ u_char *binary;
+{
+ const char *cp, *maxcp;
+ u_char *bcp;
+
+ u_int32_t latit = 0, longit = 0, alt = 0;
+ u_int32_t lltemp1 = 0, lltemp2 = 0;
+ int altmeters = 0, altfrac = 0, altsign = 1;
+ u_int8_t hp = 0x16; /* default = 1e6 cm = 10000.00m = 10km */
+ u_int8_t vp = 0x13; /* default = 1e3 cm = 10.00m */
+ u_int8_t siz = 0x12; /* default = 1e2 cm = 1.00m */
+ int which1 = 0, which2 = 0;
+
+ cp = ascii;
+ maxcp = cp + strlen(ascii);
+
+ lltemp1 = latlon2ul(&cp, &which1);
+
+
+
+Davis, et al Experimental [Page 13]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ lltemp2 = latlon2ul(&cp, &which2);
+
+ switch (which1 + which2) {
+ case 3: /* 1 + 2, the only valid combination */
+ if ((which1 == 1) && (which2 == 2)) { /* normal case */
+ latit = lltemp1;
+ longit = lltemp2;
+ } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
+ longit = lltemp1;
+ latit = lltemp2;
+ } else { /* some kind of brokenness */
+ return 0;
+ }
+ break;
+ default: /* we didn't get one of each */
+ return 0;
+ }
+
+ /* altitude */
+ if (*cp == '-') {
+ altsign = -1;
+ cp++;
+ }
+
+ if (*cp == '+')
+ cp++;
+
+ while (isdigit(*cp))
+ altmeters = altmeters * 10 + (*cp++ - '0');
+
+ if (*cp == '.') { /* decimal meters */
+ cp++;
+ if (isdigit(*cp)) {
+ altfrac = (*cp++ - '0') * 10;
+ if (isdigit(*cp)) {
+ altfrac += (*cp++ - '0');
+ }
+ }
+ }
+
+ alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
+
+ while (!isspace(*cp) && (cp < maxcp))
+ /* if trailing garbage or m */
+ cp++;
+
+ while (isspace(*cp) && (cp < maxcp))
+ cp++;
+
+
+
+Davis, et al Experimental [Page 14]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ if (cp >= maxcp)
+ goto defaults;
+
+ siz = precsize_aton(&cp);
+
+ while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+ cp++;
+
+ while (isspace(*cp) && (cp < maxcp))
+ cp++;
+
+ if (cp >= maxcp)
+ goto defaults;
+
+ hp = precsize_aton(&cp);
+
+ while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+ cp++;
+
+ while (isspace(*cp) && (cp < maxcp))
+ cp++;
+
+ if (cp >= maxcp)
+ goto defaults;
+
+ vp = precsize_aton(&cp);
+
+ defaults:
+
+ bcp = binary;
+ *bcp++ = (u_int8_t) 0; /* version byte */
+ *bcp++ = siz;
+ *bcp++ = hp;
+ *bcp++ = vp;
+ PUTLONG(latit,bcp);
+ PUTLONG(longit,bcp);
+ PUTLONG(alt,bcp);
+
+ return (16); /* size of RR in octets */
+}
+
+/* takes an on-the-wire LOC RR and prints it in zone file
+ * (human readable) format. */
+char *
+loc_ntoa(binary,ascii)
+ const u_char *binary;
+ char *ascii;
+{
+
+
+
+Davis, et al Experimental [Page 15]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ static char tmpbuf[255*3];
+
+ register char *cp;
+ register const u_char *rcp;
+
+ int latdeg, latmin, latsec, latsecfrac;
+ int longdeg, longmin, longsec, longsecfrac;
+ char northsouth, eastwest;
+ int altmeters, altfrac, altsign;
+
+ const int referencealt = 100000 * 100;
+
+ int32_t latval, longval, altval;
+ u_int32_t templ;
+ u_int8_t sizeval, hpval, vpval, versionval;
+
+ char *sizestr, *hpstr, *vpstr;
+
+ rcp = binary;
+ if (ascii)
+ cp = ascii;
+ else {
+ cp = tmpbuf;
+ }
+
+ versionval = *rcp++;
+
+ if (versionval) {
+ sprintf(cp,"; error: unknown LOC RR version");
+ return (cp);
+ }
+
+ sizeval = *rcp++;
+
+ hpval = *rcp++;
+ vpval = *rcp++;
+
+ GETLONG(templ,rcp);
+ latval = (templ - ((unsigned)1<<31));
+
+ GETLONG(templ,rcp);
+ longval = (templ - ((unsigned)1<<31));
+
+ GETLONG(templ,rcp);
+ if (templ < referencealt) { /* below WGS 84 spheroid */
+ altval = referencealt - templ;
+ altsign = -1;
+ } else {
+
+
+
+Davis, et al Experimental [Page 16]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ altval = templ - referencealt;
+ altsign = 1;
+ }
+
+ if (latval < 0) {
+ northsouth = 'S';
+ latval = -latval;
+ }
+ else
+ northsouth = 'N';
+
+ latsecfrac = latval % 1000;
+ latval = latval / 1000;
+ latsec = latval % 60;
+ latval = latval / 60;
+ latmin = latval % 60;
+ latval = latval / 60;
+ latdeg = latval;
+
+ if (longval < 0) {
+ eastwest = 'W';
+ longval = -longval;
+ }
+ else
+ eastwest = 'E';
+
+ longsecfrac = longval % 1000;
+ longval = longval / 1000;
+ longsec = longval % 60;
+ longval = longval / 60;
+ longmin = longval % 60;
+ longval = longval / 60;
+ longdeg = longval;
+
+ altfrac = altval % 100;
+ altmeters = (altval / 100) * altsign;
+
+ sizestr = savestr(precsize_ntoa(sizeval));
+ hpstr = savestr(precsize_ntoa(hpval));
+ vpstr = savestr(precsize_ntoa(vpval));
+
+ sprintf(cp,
+ "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
+ %sm %sm %sm",
+ latdeg, latmin, latsec, latsecfrac, northsouth,
+ longdeg, longmin, longsec, longsecfrac, eastwest,
+ altmeters, altfrac, sizestr, hpstr, vpstr);
+
+
+
+
+Davis, et al Experimental [Page 17]
+
+RFC 1876 Location Information in the DNS January 1996
+
+
+ free(sizestr);
+ free(hpstr);
+ free(vpstr);
+
+ return (cp);
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al Experimental [Page 18]
+
generated by cgit (git 2.34.1) at 2024-04-26 12:18:37 +0000