Geographic Location representation in DNS

RFC 1876 describes the means for which physical geographic location can be stored in a consistent manner in the existing DNS infrastructure.

The motivations for this are to provide administrators and users with information

The implementation of these geographic location extensions are done through the implementation of a single resource record (RR) type that needs to be added to the existing DNS servers for a zone or domain. The "LOC" RR can provide geographic location information that is specific to a host, a subnet, or an entire domain. It is possible to have applications accept more largely encompassing "LOC" field that can be used as a "fall-back" location record if one is not overridden at a smaller-scale range.

Suggested uses of LOC information records include backbone flow maps, "visual trace-route" 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.

LOC record searching techniques

If an application wishes to have a "fall-back" behavior, displaying a less precise or larger area when a host does not have an associated LOC RR, it may support the an optional fall-back search method. 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.)

The fall-back search method for "searches by name" is as follows:

The application MUST check for a LOC record associated with that name.
If there is no LOC record for that name, all A records associated with the name MAY be checked for network (or subnet) LOC records using the "searching by network or subnet" algorithm. If multiple A records have LOC entries, then the application may choose to use any, some, or all of them.

The fall-back search method for "searches by address" is as follows:

The application MUST first map the address to a name using the IN-ADDR.ARPA namespace and check for a LOC entry associated with that name.
If there is no LOC entry for the name, the address MAY be checked for network (or subnet) LOC records using the "searches by network or subnet" algorithm.

The fallback search method for "searches by network or subnet" is as follows:

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".
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.
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.
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.
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.)

Data Format

The format of the data stored in the RDATA section of the data packet that is returned by a DNS server in response to a query requesting the LOC record of a particular entity in the server's database is as follows:

       MSB                                           LSB
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0|        VERSION        |         SIZE          |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2|       HORIZ PRE       |       VERT PRE        |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      4|                   LATITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      6|                   LATITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      8|                   LONGITUDE                   |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     10|                   LONGITUDE                   |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     12|                   ALTITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     14|                   ALTITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The version field is defined to be "0" for the current implementation of this RR. Other values indicate that the entire record should be ignored to allow for future implementations of the RR to be later created.

The "size" field represents 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=20,000km (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.

The "horiz pre" field represents 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 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.)

The "vert pre" field holds 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.

The "Latitude", "Longitude", and "Altitude" are measured in the same units relative to the equator, prime meridian, and sea level, respectively.

The recommended format for the textual representation of this data in a DNS zone file is as follows:

        LOC ( d1 [m1 [s1]] {"N"|"S"} 
	    d2 [m2 [s2]] {"E"|"W"}
	    alt["m"] [siz["m"] [hp["m"] [vp["m"]]]] )

Applications

There are a few related links available at the RFC 1876 Resources Page

One interesting application of the LOC records is the LOC2MAP demo page that will search for the location information of a given host an generate graphical maps indicating the position of the machine.