As per Relevance of the word represent, we have this rfc below:
Network Working Group C.
Request for Comments: 1876 Kapor
Updates: 1034, 1035 P.
Category: Experimental Vixie
T.
FORE
I.
University of
January 1996
A Means for Expressing Location Information in the Domain Name
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
1.
This memo defines a new DNS RR type for experimental purposes.
RFC describes a mechanism to allow the DNS to carry
information about hosts, networks, and subnets. Such information
a small subset of hosts is currently contained in the flat-file
maps. However, just as the DNS replaced the use of HOSTS.TXT
carry host and network address information, it is possible to
the UUCP maps as carriers of location information
This RFC defines the format of a new Resource Record (RR) for
Domain Name System (DNS), and reserves a corresponding DNS
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
does not necessarily reflect the real Internet
Davis, et al Experimental [Page 1]
RFC 1876 Location Information in the DNS January 1996
2. RDATA
MSB
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
no assumptions about the format of unrecognized versions
SIZE The diameter of a sphere enclosing the described entity,
centimeters, expressed as a pair of four-bit
integers, each ranging from zero to nine, with the
significant four bits representing the base and the
number representing the power of ten by which to
the base. This allows sizes from 0e0 (<1cm) to 9e
(90,000km) to be expressed. This representation was
such that the hexadecimal representation can be read
eye; 0x15 = 1e5. Four-bit values greater than 9
undefined, as are values with a base of zero and a non-
exponent
Since 20000000m (represented by the value 0x29) is
than the equatorial diameter of the WGS 84
(12756274m), it is therefore suitable for use as
"worldwide" size
HORIZ PRE The horizontal precision of the data, in centimeters
expressed using the same representation as SIZE. This
the diameter of the horizontal "circle of error",
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
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.
is the total potential vertical error, rather than a "
or minus" value. (This was chosen to match
interpretation of SIZE; to get a "plus or minus" value
divide by 2.) Note that if altitude above or below
level is used as an approximation for altitude relative
the [WGS 84] ellipsoid, the precision value should
adjusted
LATITUDE The latitude of the center of the sphere described by
SIZE field, expressed as a 32-bit integer, most
octet first (network standard byte order), in
of a second of arc. 2^31 represents the equator;
above that are north latitude
LONGITUDE The longitude of the center of the sphere described by
SIZE field, expressed as a 32-bit integer, most
octet first (network standard byte order), in
of a second of arc, rounded away from the prime meridian
2^31 represents the prime meridian; numbers above that
east longitude
ALTITUDE The altitude of the center of the sphere described by
SIZE field, expressed as a 32-bit integer, most
octet first (network standard byte order), in centimeters
from a base of 100,000m below the [WGS 84]
spheroid used by GPS (semimajor axis a=6378137.0,
reciprocal flattening rf=298.257223563). Altitude
(or below) sea level may be used as an approximation
altitude relative to the the [WGS 84] spheroid, though
to the Earth's surface not being a perfect spheroid,
will be differences. (For example, the geoid (which
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
in most cases. The Defense Mapping Agency publishes
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
The LOC record is expressed in a master file in the following format
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 [
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
defaults to 10m. These defaults are chosen to represent
ZIP/postal code area sizes, since it is often easy to
approximate geographical location by ZIP/postal code
4. Example
;;;
;;; note that these data would not all appear in one zone
;;;
;; network LOC RR derived from ZIP data. note use of precision
cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30
;; higher-precision host LOC RR. note use of vertical precision
loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344
-24m 1m 200
pipex.net. LOC 52 14 05 N 00 08 50 E 10
curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10
rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617
-44m 2000
Davis, et al Experimental [Page 4]
RFC 1876 Location Information in the DNS January 1996
5. Application use of the LOC
5.1 Suggested
Some uses for the LOC RR have already been suggested, including
USENET backbone flow maps, a "visual traceroute" application
the geographical path of an IP packet, and network
applications that could use LOC RRs to generate a map of hosts
routers being managed
5.2 Search
This section specifies how to use the DNS to translate domain
and/or IP addresses into location information
If an application wishes to have a "fallback" behavior, displaying
less precise or larger area when a host does not have an
LOC RR, it MAY support use of the algorithm in section 5.2.3,
noted in sections 5.2.1 and 5.2.2. If fallback is desired,
behaviour is the RECOMMENDED default, but in some cases it may
to be modified based on the specific requirements of the
involved
This search algorithm is designed to allow network administrators
specify the location of a network or subnet without requiring LOC
data for each individual host. For example, a computer lab with 24
workstations, all of which are on the same subnet and in
the same location, would only need a LOC RR for the subnet
(However, if the file server's location has been more
measured, a separate LOC RR for it can be placed in the DNS.)
5.2.1 Searching by
If the application is beginning with a name, rather than an
address (as the USENET backbone flow maps do), it MUST check for
LOC RR associated with that name. (CNAME records should be
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)
RRs using the "Searching by Network or Subnet" algorithm (5.2.3).
multiple A records exist and have associated network or subnet
RRs, the application may choose to use any, some, or all of the
RRs found, possibly in combination. It is suggested that multi-
hosts have LOC RRs for their name in the DNS to avoid any
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
have a LOC RR associated with their name in order for
information to be accessible
5.2.2 Searching by
If the application is beginning with an IP address (as a "
traceroute" application might be) it MUST first map the address to
name using the IN-ADDR.ARPA namespace (see [RFC 1034],
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
network (or subnet) LOC RRs using the "Searching by Network
Subnet" algorithm (5.2.3).
5.2.3 Searching by Network or
Even if a host's name does not have any associated LOC RRs,
network(s) or subnet(s) it is on may. If the application wishes
search for such less specific data, the following algorithm SHOULD
followed to find a network or subnet LOC RR associated with the
address. This algorithm is adapted slightly from that specified
[RFC 1101], sections 4.3 and 4.4.
Since subnet LOC RRs are (if present) more specific than network
RRs, it is best to use them if available. In order to do so,
build a stack of network and subnet names found while performing
[RFC 1101] search, then work our way down the stack until a LOC RR
found
1. create a host-zero address using the network portion of the
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
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
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
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
(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
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
be searched for LOC RRs later
5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are
more subnet levels to search. We now pop the top name from
stack and check for an associated LOC RR. Repeat until a LOC
is found
In this case, assume that inc-subsubnet.isi.edu does not have
associated LOC RR, but that div2-subnet.isi.edu does. We
then use div2-subnet.isi.edu's LOC RR as an approximation of
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
The LOC record is defined for all RR classes, and may be used
non-IN classes such as HS and CH. The semantics of such use are
defined by this memo
The search algorithm in section 5.2.3 may be adapted to
addressing schemes by extending [RFC 1101]'s encoding of
names to cover those schemes. Such extensions are not defined
this memo
Davis, et al Experimental [Page 7]
RFC 1876 Location Information in the DNS January 1996
6.
[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
Specification", STD 13, RFC 1035, USC/Information
Institute, November 1987.
[RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and
Types", RFC 1101, USC/Information Sciences Institute
April 1989.
[WGS 84] United States Department of Defense; DoD WGS-1984 -
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
High-precision LOC RR information could be used to plan a
of physical security, leading to potential denial-of-machine attacks
To avoid any appearance of suggesting this method to
attackers, we declined the opportunity to name this RR "ICBM".
8. Authors'
The authors as a group can be reached as .
Christopher
Kapor Enterprises, Inc
238 Main Street, Suite 400
Cambridge, MA 02142
Phone: +1 617 576 4532
EMail: ckd@kei.
Paul
Vixie
Star Route Box 159
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.
Davis, et al Experimental [Page 8]
RFC 1876 Location Information in the DNS January 1996
Tim
Public IP Exchange Ltd (PIPEX
216 The Science
Cambridge CB4 4
Phone: +44 1223 250250
EMail: tim@pipex.
Ian
FORE
2475 The
Solihull
Birmingham Business
B37 7
Phone: +44 121 717 4444
EMail: idickins@fore.co.
Davis, et al Experimental [Page 9]
RFC 1876 Location Information in the DNS January 1996
Appendix A: Sample Conversion
/*
* routines to convert between on-the-wire RR format and zone
* 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_
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_
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
* on-the-wire representation. */
u_int32_
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
* (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
}
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
}
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.%.2
%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]
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
