LOC Location Common
Publishes a host's physical geographic location — latitude, longitude, and altitude — directly in DNS.
What it's for
A LOC (Location) record publishes a host's physical geographic location directly in DNS — latitude, longitude, altitude, and even a precision/size radius, all encoded in a single record. It was defined in RFC 1876 as a way to let anyone querying DNS learn roughly where a server (or the organization behind a domain) is physically located, without needing a separate geolocation lookup service.
In practice, LOC adoption stayed fairly niche — most real-world geolocation today happens through commercial IP-geolocation databases and services rather than DNS LOC records, largely because publishing accurate physical location data in an openly queryable system raised the same kind of concerns as HINFO (unnecessary information disclosure), and because IP-based geolocation databases turned out to be a more practical, no-configuration-required solution for the same underlying need.
Format & syntax
example.com. 3600 IN LOC 37 46 30.000 N 122 25 10.000 W 30.00m 1m 10000m 10m
- Latitude — degrees, minutes, seconds, and N/S hemisphere
- Longitude — degrees, minutes, seconds, and E/W hemisphere
- Altitude — meters above/below a reference sea level
- Size — the diameter of a sphere covering the location, expressing a level of precision/uncertainty
- Horizontal Precision — how precisely the coordinates are known horizontally
- Vertical Precision — how precisely the altitude is known
The format is deliberately more elaborate than a simple lat/long pair, since it was designed to express both a location and how much to trust the precision of that location.
How it's used in practice
- Niche network/infrastructure documentation — occasionally used by network operators to document the physical location of specific infrastructure (a data center, a specific rack of equipment) in a way that's discoverable via DNS tooling, mostly within specialized network operations contexts rather than general web infrastructure.
- Amateur radio and specialized hobbyist networks — some amateur radio and hobbyist DNS deployments have historically used LOC more than mainstream commercial internet infrastructure, where the audience querying it has direct interest in physical antenna/station locations.
- Rarely encountered in typical web/app development — for the overwhelming majority of modern domain and infrastructure work, you're unlikely to ever need to create or consume a LOC record; commercial IP-geolocation services fill this need far more commonly today.
Common mistakes & gotchas
- Publishing precise real-world location data unnecessarily — similar to HINFO's information-disclosure concern, publishing exact physical coordinates for infrastructure in a publicly queryable DNS record is rarely something you actually want, unless there's a specific, deliberate reason (like the network-operations documentation use case above).
- Assuming LOC is how modern geolocation services work — it isn't. Commercial geolocation (used by CDNs, analytics tools, fraud detection, etc.) is based on maintained IP-to-location databases, not DNS LOC records, which never saw broad adoption for that purpose.
- Getting the coordinate format wrong — the degrees/minutes/seconds plus precision-radius format is more involved than a typical simple lat/long pair, and it's easy to make an encoding mistake if hand-writing a LOC record without tooling to help.
Comparison & FAQ
| Type | Purpose | Key difference from LOC |
|---|---|---|
| TXT | General arbitrary text, could informally include location info | Unstructured, versus LOC's specific, structured geographic coordinate format |
| HINFO | Publishes CPU/OS info, a similarly niche legacy record type | Different data category, but shares the same "openly disclosing info you might not want to disclose" concern |
Is LOC how services like CDNs determine your geographic location?
No — commercial geolocation services rely on maintained IP-to-location databases, not DNS LOC records. LOC never became the practical mechanism for real-world geolocation despite being defined for that purpose.
Should I publish a LOC record for my domain?
Generally not necessary for typical web/app infrastructure, and it does disclose physical location information publicly — only worth doing if you have a specific, deliberate reason (network operations documentation, hobbyist/amateur radio contexts) for wanting that information openly queryable.
What does the "size" field in a LOC record represent?
It expresses a diameter (in meters) representing how precisely the coordinates should be trusted — essentially a margin-of-error radius rather than the literal physical size of anything at that location.
Why didn't LOC records become widely used?
A combination of information-disclosure concerns (similar to HINFO) and the practical rise of dedicated commercial IP-geolocation databases, which solved the same underlying need without requiring domain owners to manually publish and maintain coordinate data in DNS.