A LOC record stores a geographic location, latitude, longitude, and altitude, directly in DNS, letting a name carry a physical position alongside its addresses and mail routing. It is one of the oldest and least-used record types in the system, defined back in RFC 1876 (still the governing spec as of November 2026), yet it is perfectly valid and occasionally useful. This guide explains exactly what a LOC record holds, how its coordinate and precision fields are written and encoded, and the handful of places the data still shows up.
What a LOC record is
The LOC record was introduced so that a host or network could publish where it physically sits. The motivation in 1994 was experimental: network operators wanted a way to map the internet geographically, troubleshoot routing against real-world distance, and draw diagrams of where machines actually were. The record never became part of day-to-day operations, but it was standardized and remains supported by all major DNS software, so you can publish and query it today without any special tooling.
A LOC record answers a different question from the rest of DNS. An A record says where to connect; a LOC record says where the thing is on the planet. The two are completely independent, and nothing about normal name resolution consults a LOC record.
The master-file format
You rarely write the binary form by hand. Zone files use a human-readable syntax that most name servers parse into the wire format for you:
example.com. IN LOC 42 21 54.000 N 71 06 18.000 W 24m 30m 10000m 10mReading that left to right: latitude 42 degrees 21 minutes 54 seconds North, longitude 71 degrees 6 minutes 18 seconds West, altitude 24 meters, then three optional precision values, size 30m, horizontal precision 10000m, and vertical precision 10m. Only the latitude, longitude, and altitude are required; the three precision fields fall back to defaults if you omit them.
Field by field
| Field | Format | Notes |
|---|---|---|
| Latitude | deg min sec {N|S} | Minutes and seconds optional; hemisphere letter required |
| Longitude | deg min sec {E|W} | Same structure as latitude |
| Altitude | meters, e.g. 24m | Height relative to a reference spheroid, range roughly -100000m to 42849672.95m |
| Size | meters, default 1m | Diameter of a sphere enclosing the entity |
| Horiz precision | meters, default 10000m | Horizontal error radius |
| Vert precision | meters, default 10m | Vertical error |
How the values are encoded on the wire
Underneath the friendly text, LOC packs everything into a fixed structure. Latitude and longitude are 32-bit integers measured in thousandths of an arc-second, with the midpoint value (2 raised to the 31st) representing the equator for latitude and the prime meridian for longitude. Altitude is a 32-bit integer in centimeters, offset so that the encoded zero sits 100000 meters below the reference spheroid, which is why very low altitudes are still representable. The size and two precision fields are each squeezed into a single byte using a base-and-exponent scheme: four bits of mantissa and four bits of power-of-ten, in centimeters. That byte trick is why the defaults look like round numbers; they are the values that encode cleanly.
Reading a LOC record
Query it like any other type with dig, and the answer comes back in the same master-file syntax you would use to write it:
$ dig LOC example.com +short
42 21 54.000 N 71 6 18.000 W 24.00m 30m 10000m 10mIf no LOC record exists you simply get an empty answer, which is the normal state for virtually every domain. There is no fallback or inheritance; a name either has a LOC record or it does not.
Publishing one, step by step
- Find the coordinates you want to publish. Decimal degrees from a map tool convert easily to degrees, minutes, and seconds.
- Decide how precise you want to be. Publishing a building is fine; publishing a rack row inside a data center is oversharing for a public zone.
- Write the record in master-file format, remembering the hemisphere letters and the trailing m on altitude.
- Set the precision fields deliberately, or leave them off to accept the 1m size, 10000m horizontal, and 10m vertical defaults.
- Add it to the zone, reload, and confirm with a dig LOC query.
Where LOC data is actually used
Honest answer: rarely, and never in a way that affects whether your site works. The real uses today are niche. Some network-mapping and visualization tools read LOC records to plot infrastructure. A few amateur radio and research networks publish LOC data as a convention. Hobbyists use it to geotag a server for fun. What LOC is not is a privacy-safe or authoritative location service, so do not publish a home address on a public domain and do not expect browsers, mail servers, or search engines to do anything with it. Treat it as documentation that happens to live in DNS.
Because LOC is a record type like any other, the same lookup and verification habits apply as for the records you use daily. If you are brushing up on reading uncommon types, our references on SRV records and PTR and reverse DNS walk through the same field-by-field style on records that do carry operational weight.
To see what a LOC record actually resolves to from the public internet, drop the name into the Valla DNS DNS lookup tool and query the LOC type directly, so you can confirm your coordinates parse and propagate the way you intended.
Does a LOC record affect how my domain resolves?
No. LOC is purely informational and sits alongside your A, MX, and other records without influencing any of them. Removing or adding a LOC record has zero effect on whether your site, mail, or services work.
What are the default precision values?
If you omit them, size defaults to 1 meter, horizontal precision to 10000 meters, and vertical precision to 10 meters. These defaults come from the values that encode cleanly into the record's single-byte precision fields.
Is it safe to publish my location in DNS?
Only publish what you are comfortable being fully public, because anyone can query a LOC record. Use coarse coordinates for a general area rather than a precise address, and never geotag a private residence on a public zone.
Why is the altitude range so unusual?
Altitude is a 32-bit value in centimeters with an offset that places encoded zero 100000 meters below the reference spheroid. That offset is what lets the field represent points below the reference while still using an unsigned integer on the wire.
Do browsers or search engines use LOC records?
No. There is no mainstream client that reads LOC records for ranking, routing, or display. Any use is confined to specialized network-mapping tools and hobbyist conventions, so treat LOC as documentation rather than a functional location service.