The weird and wonderful world of DNS LOC records
Get Started Free|Contact SalesThe Cloudflare BlogSubscribe to receive notifications of new posts:SubscribeAIDevelopersRadarProduct NewsSecurityPolicy & LegalZero TrustSpeed & ReliabilityLife at CloudflarePartnersAIDevelopersRadarProduct NewsSecurityPolicy & LegalZero TrustSpeed & ReliabilityLife at CloudflarePartnersThe weird and wonderful world of DNS LOC records2014-04-01John Graham-Cumming2 min readA cornerstone of CloudFlare's infrastructure is our ability to serve DNS requests quickly and handle DNS attacks. To do both those things we wrote our own authoritative DNS server called RRDNS in Go. Because of it we've been able to fight off DNS attacks, and be consistenly one of the fastest DNS providers on the web.Implementing an authoritative DNS server is a large task. That's in part because DNS is a very old standard (RFC 1035 dates to 1987), in part because as DNS has developed it has grown into a more and more complex system, and in part because what's written in the RFCs and what happens in the real-world aren't always the same thing.One little used type of DNS record is the LOC (or location). It allows you to specify a physical location. CloudFlare handles millions of DNS records; of those just 743 are LOCs. Nevertheless, it's possible to set up a LOC record in the CloudFlare DNS editor.

My site geekatlas.com has a LOC record as an Easter Egg. Here's how it's configured in the CloudFlare DNS settings:

When you operate at CloudFlare scale the little-used nooks and crannies turn out to be important. And even though there are only 743 LOC records in our entire database, at least one customer contacted support to find out why their LOC record wasn't being served.And that sent me into the RRDNS source code to find out why.The answer was simple. Although RRDNS had code for receiving requests for LOC records, creating response packets containing LOC data, there was a missing link. The CloudFlare DNS server stores the LOC record as a string (such as the 33 40 31 N 106 28 29 W 10m above) and no one had written the code to parse that and turn it into the internal format. Oops.The textual LOC format and the binary, on-the-wire, format are described in RFC 1876 and it's one of many RFCs that updated the original 1987 standard. RFC 1876 is from 1996.The textual format is fairly simple. Here's what the RFC says:
The LOC record is expressed in a primary file in the following format:

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

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 precision
defaults to 10m. These defaults are chosen to represent typical
ZIP/postal code area sizes, since it is often easy to find
approximate geographical location by ZIP/postal code.
So, there are required latitude, longitude and altitude and three optional values for the size of the location and precision information. Pretty simple.Then there's the on-the-wire format. Unlike a TXT record the LOC record data is parsed and turned into a fixed size binary format. Back to RFC 1876:
MSB LSB
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| VERSION | SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2| HORIZ PRE | VERT PRE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4| LATITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6| LATITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8| LONGITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10| LONGITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12| ALTITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
14| ALTITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
So, 32 bits of latitude, longitude and altitude and then three 8 bit values for the size and precision. The latitude and longitude values have a pretty simple encoding that treats the 32 bits as an unsigned integer:
The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc. 2^31 represents the equator; numbers above that are north latitude.
And the altitude can be below sea-level but still unsigned:
The altitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in centimeters, from a base of 100,000m below the [WGS 84] reference spheroid used by GPS.
But the 8 bit values use a very special encoding that allows a wide range of approximate values to be packed into 8 bits and also be human-readable when dumped out in hex!
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.
For example, the value 0x12 means 1 * 10^2 or 100cm. 0x99 means 9 * 10^9 or 90,000,000m. The smallest value that can be represented is 1cm (it's 0x10). So, in just 8 bits there's a range values from 1cm to larger than the diameter of Jupiter.To fix this I wrote a parser for the LOC text record type (and associated tests). It can be found here.We've now rolled out the fix and all the existing LOC records are being served by RRDNS. For example, my geekatlas.com LOC record can be queried like this:
$ dig geekatlas.com LOC
; <<>> DiG 9.8.3-P1 <<>> geekatlas.com LOC
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2997
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;geekatlas.com. IN LOC

;; ANSWER SECTION:
geekatlas.com. 299 IN LOC 33 40 31.000 N 106 28 29.000 W 10.00m 1m 10000m 10m

;; Query time: 104 msec
;; SERVER: 192.168.14.1#53(192.168.14.1)
;; WHEN: Tue Apr 1 14:13:48 2014
;; MSG SIZE rcvd: 59
Cloudflare's connectivity cloud protects entire corporate networks, helps customers build Internet-scale applications efficiently, accelerates any website or Internet application, wards off DDoS attacks, keeps hackers at bay, and can help you on your journey to Zero Trust.Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions. RRDNSDNSReliabilityAttacksGoFollow on XCloudflare|@cloudflareRelated postsOctober 31, 2025 1:00 PMGo and enhance your calm: demolishing an HTTP/2 interop problemHTTP/2 implementations often respond to suspected attacks by closing the connection with an ENHANCE_YOUR_CALM error code. Learn how a common pattern of using Go's HTTP/2 client can lead to unintended errors and the solution to avoiding them....By Lucas Pardue, Zak CutnerHTTP2, Go, DDoS October 27, 2025 12:00 PMFrom .com to .anything: introducing Top-Level Domain (TLD) insights on Cloudflare RadarCloudflare Radar has launched a new Top-Level Domain (TLD) page, providing insights into TLD popularity, traffic, and security. The top-ranking TLD may come as a surprise....By André Jesus, David BelsonResearch, Radar, DNS, 1.1.1.1, Registrar October 08, 2025 2:00 PMHow we found a bug in Go's arm64 compiler84 million requests a second means even rare bugs appear often. We'll reveal how we discovered a race condition in the Go arm64 compiler and got it fixed....By Thea HeinenDeep Dive, Go, Programming September 25, 2025 2:00 PMSafe in the sandbox: security hardening for Cloudflare WorkersWe are further hardening Cloudflare Workers with the latest software and hardware features. We use defense-in-depth, including V8 sandboxes and the CPU's memory protection keys to keep your data safe....By Erik Corry, Ketan GuptaCloudflare Workers, Birthday Week, Attacks, Engineering, Linux, Malicious JavaScript, Security, Vulnerabilities Getting StartedFree plansFor enterprisesCompare plansGet a recommendationRequest a demoContact SalesResourcesLearning CenterAnalyst reportsCloudflare RadarCloudflare TVCase StudiesWebinarsWhite PapersDeveloper docstheNetSolutionsConnectivity cloudSSE and SASE servicesApplication servicesNetwork servicesDeveloper servicesCommunityCommunity HubProject GalileoAthenian ProjectCloudflare for CampaignsCritical Infrastructure Defense ProjectConnect 2024SupportHelp centerCloudflare StatusComplianceGDPRTrust & SafetyCompanyAbout CloudflareOur teamInvestor relationsPressCareersDiversity, equity & inclusionImpact/ESGNetwork MapLogos & press kitBecome a partner© 2025 Cloudflare, Inc. | Privacy Policy | Terms of Use | Report Security Issues |Cookie Preferences | Trademark

The Cloudflare Blog details a fascinating, and somewhat unusual, aspect of their DNS infrastructure: the LOC record. Initially implemented to handle a specific requirement – displaying the geographic location of geekatlas.com – this record highlights the complexities inherent in translating theoretical DNS standards into practical implementation. John Graham-Cumming’s explanation reveals that while LOC records represent a tiny fraction of overall DNS requests (only 743 out of millions), they underscore the challenges of maintaining a globally distributed, high-performance DNS system.

The LOC record, introduced in RFC 1876, allows for the specification of a location using latitude, longitude, altitude, and size data. This data is represented in two formats: a textual format, which is human-readable, and a binary format used for transmission. The textual format is comprised of a string containing the various location parameters, while the binary format employs a 32-bit integer encoding for latitude, longitude, and altitude, along with additional eight-bit values for size and precision. This encoding allows for a wide range of values to be represented within a compact binary format.

The story initially arose when a discrepancy was discovered between the expected and actual output of the LOC record for the geekatlas.com website. Investigation revealed a missing link in the RRDNS code, which meant that the location data was not being correctly parsed and converted into the required internal format. This simple oversight, representing a gap in the software’s ability to appropriately handle this specific record type, ultimately demonstrated the intricacies of translating complex specifications into reliable system operation. The existence of a parser – developed by Graham-Cumming – specifically for the textual LOC record type further clarifies the need for detailed understanding and dedicated processing.

The design of the LOC record itself highlights deliberate choices made to balance human readability with efficient data representation. The use of a wide range of values and the inclusion of size and precision parameters were intended to capture geographic information with a level of detail suitable for various applications. Despite its limited usage, the LOC record serves as a potent reminder of the challenges encountered when scaling a global infrastructure and the importance of thorough testing and careful code development. Furthermore, it underscores how seemingly insignificant elements can play a critical role in ensuring the overall reliability and performance of a robust and complex system, as recognized by Graham-Cumming.