Summary

  • LOC kept entity size, horizontal uncertainty and vertical uncertainty separate from the coordinate itself. A small object could have a poorly known position.
  • Its default horizontal precision was a circle with a diameter of 10,000 metres, not a radius of that length. Fine coordinate encoding did not override that qualification.
  • A network-location fallback could answer a host query approximately without locating the host itself. Cache freshness and DNSSEC signatures supplied no missing survey date.

The circle outside the pin

The coordinate has many digits. The marker has a sharp tip. Neither tells the reader how well the place is known.

The experimental RFC 1876, published in January 1996, provided room for that less convenient information. Its LOC resource record described geographic locations for hosts, networks and subnets. Alongside latitude, longitude and altitude, it carried the size of the described entity and separate horizontal and vertical precision values.

In the text format, an omitted horizontal precision became 10,000 metres. This was the diameter of an error circle, not a ten-kilometre radius. The same record could use the default entity size of one metre. A small thing in a large area of uncertainty was an entirely coherent description.

An application that extracted only the coordinate could turn that description into something apparently stronger. It did not need to change a digit. It merely had to leave the circle out.

This is a history of that representational boundary, not a claim that LOC became a universal geolocation system. A format can preserve distinctions that its consumers later discard. Understanding the record means recovering those distinctions before treating its output as a place on the ground.

Geography maintained near the name

The problem was partly administrative. Geographic information for some sites had circulated through UUCP maps. Central maintenance and checking made keeping those descriptions current difficult. DNS offered a different arrangement: people responsible for a name could maintain its location information locally, while others could query it through a distributed system.

The earlier experimental RFC 1712, from November 1994, proposed the GPOS record with that local-maintenance ambition. It considered alternatives including SNMP's sysLocation, with its agent and access context and often local description, and the then-limited deployment of X.500. Those are historical design considerations, not a survey of either system today.

GPOS used three printable numeric strings for geographic components. They were not three binary IEEE floating-point values. The ability to print numerous decimal places made a detailed statement possible; it did not establish that anyone had measured the position to that detail.

DNS supplied a place to publish and retrieve a claim. Authority over the name did not become authority over the accuracy of a survey. That distinction was already present before LOC supplied more explicit ways to qualify the claim.

The axis labels were part of the data

There is a further reason to read GPOS carefully. Its text interchanges longitude and latitude terminology and definitions. Official erratum 541, reported in 2006, identifies the problem and proposes corrected labels while retaining the numeric order.

The erratum is marked “Held for Document Update”, not “Verified”. It is not evidence that the original specification has already been formally amended or that every implementation settled the ambiguity identically. The old coordinate examples should not be silently repaired and reproduced as a reliable configuration recipe.

This was not just a matter of a number being too imprecise. A number assigned to the wrong axis can be read perfectly and still mean the wrong thing. The shared interpretation mattered as much as the shared syntax.

Nor should the appearance of LOC be turned into a formal retirement of GPOS. RFC 1876 does not obsolete RFC 1712. The IANA DNS parameters registry still lists GPOS as type 27 and LOC as type 29. Registration distinguishes formats; it does not count installations, establish maintenance quality or measure adoption.

Sixteen octets with more than one scale

Version zero of LOC has sixteen octets of RDATA. That is the type-specific data, not the entire resource record or DNS message. Version, size, horizontal precision and vertical precision take one octet each. Latitude, longitude and altitude take four each.

Latitude and longitude are represented in thousandths of an arcsecond using offset integers. Two to the thirty-first power denotes the equator or prime meridian; larger values mean north or east. These are not ordinary signed angle values copied into a two's-complement field.

The resolution of this encoding tells a program which adjacent numbers it can distinguish. It says nothing about whether the publisher can distinguish the corresponding physical positions. In the case of longitude, the ground distance represented by an angular difference also depends on latitude. There is no single constant metre conversion that works everywhere.

Size and precision use a different compact scheme: a decimal base digit and a decimal exponent, producing a value in centimetres. The two nibbles define values from zero through nine, not ten through fifteen. Zero times ten to the zero means less than one centimetre, not exact zero error. A zero base with a non-zero exponent is not defined.

The record therefore had deliberate limits on representation. It did not offer unlimited meaningful digits. Implementations also had to check the version rather than assume that unfamiliar versions retained the same interpretation. Successfully receiving bytes was only the beginning of reading them.

Size was not a synonym for certainty

SIZE is the diameter of a sphere enclosing the entity. Horizontal precision is the diameter of the horizontal circle of error. Vertical precision is the total possible vertical error. Treating any of these as an unqualified plus-or-minus value changes the extent being described.

Where a half-width interpretation is appropriate, it requires halving the full extent. It does not justify adding a statistical confidence level. The RFC does not say that a specified percentage of observations will fall within the circle. A consumer should not invent that assurance.

The distinction between entity size and uncertainty is especially useful. A one-metre object can be known only to a broad postal area. A large entity can have a well-known reference centre. Its physical spread and the quality of the coordinate answer different questions.

In the zone-file form, size and the two precisions are optional. Their defaults are one metre, 10,000 metres and ten metres respectively. RFC 1876 connects those defaults to the availability of approximate geographic information from postal codes. The omitted text values are still represented in the version-zero wire data through those defaults.

Altitude, size and precision are written in metres in that text form, while the corresponding binary fields use centimetres. Moving between forms requires respecting the unit boundary. A spreadsheet or map that receives a bare number without its interpretation can lose meaning even when it preserves every character.

Altitude needed a reference, not just a sign

LOC's altitude refers to the WGS84 reference ellipsoid. Its stored value counts centimetres from a base 100,000 metres below that reference. Zero metres relative to the ellipsoid consequently corresponds to an encoded value of 10,000,000 centimetres.

The offset allows positions below the reference surface without a negative storage integer. It does not add a hundred kilometres to a site's real height. Nor does it make mean sea level identical to the reference ellipsoid.

The RFC allows a sea-level approximation with appropriate adjustment of altitude or vertical precision. The important historical point is that the reference must remain explicit. More decimal places cannot compensate for starting at the wrong surface.

These qualifications make the data less immediately tidy than a pin labelled with a height. They also make it more informative. The coordinate is a statement made in a particular representation, not a self-explanatory physical fact.

A host question could become a network answer

LOC also qualified how an application could find a position. Starting with a name, it had to check LOC at that name and follow CNAME in the usual way. If there was no direct LOC, associated A records could provide a route to a network or subnet location.

Starting with an IPv4 address, the application first obtained a name through IN-ADDR.ARPA and then checked LOC for that name. This was not a blanket instruction to place LOC directly beneath the reversed address name. If the direct result was absent, an optional network fallback remained possible.

That fallback adapted the historical network-naming mechanism in RFC 1101, published in April 1989. Special reverse names, PTR records and A-shaped subnet-mask data helped recover network and subnet names. In that context, the relevant A-shaped values were masks, not addresses of listening services.

The LOC procedure collected names and looked from the more specific subnet back towards broader networks, using the first available location. It was not ordinary parent-label walking in DNS, nor BGP longest-prefix forwarding. It retained the classful IPv4 assumptions of its period. RFC 1876 discussed possible adaptation to other address schemes but did not define a general IPv6 extension.

The aim was to display a larger, less precise area when a fine location was unavailable. The fallback record still described a network or subnet. Presenting it as the measured position of one host silently changed the subject of the statement.

Multiple A addresses added another application choice: any, some or all associated fallback positions might be used or combined. A direct LOC for a multihomed host could reduce that ambiguity. The format did not guarantee that every successful search produced one uniquely justified pin.

A fresh answer could carry an old claim

The resource-record framework in RFC 1035 includes owner name, type, class, TTL and data. TTL governs cache lifetime before consulting the source again. It does not say how long ago a location was physically measured.

The later RFC 4033, from March 2005, distinguishes cache coherence from the validity period of a DNSSEC signature. DNSSEC provides data-origin authentication and integrity, not a geographic inspection. It also does not supply confidentiality.

The inference is narrow but important: an authentically published coordinate can still be old, misconfigured or interpreted with the wrong scope. A new signature does not add a survey date or repair an incorrect altitude reference. Version-zero LOC contains no separate instrument description or measurement timestamp to answer those questions.

Proposed visual traceroute and management-map uses should be read within that limit. A registered coordinate for an IP hop is not proof of the actual physical path of a packet. A format proposal is not a deployment census, and this history makes no claim about current geolocation accuracy.

Public disclosure was a separate concern from correctness. GPOS explicitly treated DNS information as public; LOC warned that precise geography could increase physical security risks. These warnings establish a design consideration, not evidence of a particular attack. Being able to describe a place accurately did not settle whether publishing that accuracy was appropriate.