The Weirdest DNS Record Types You Have Probably Never Used

Most domains get by fine on a handful of record types — A, CNAME, MX, TXT, maybe NS and CAA. But the DNS specification defines dozens of record types for far stranger, more specific purposes. Here are a few of the more delightfully obscure ones still in active use somewhere on the internet.

LOC — put your server on a map, literally

The LOC record stores a physical geographic location — latitude, longitude, altitude, even a precision radius — directly in DNS. It was designed in the 1990s for genuinely mapping where infrastructure physically sits. In practice it's almost never used today (geolocation is mostly inferred from IP address databases instead), but it's still a valid, queryable record type, and every so often you'll stumble on a domain that still publishes one, like a tiny digital time capsule.

HINFO — a relic that became a mild security concern

HINFO was meant to describe a host's hardware and operating system in plain text. The problem is obvious in hindsight: broadcasting exactly what OS and hardware a server runs is a gift to anyone probing for known vulnerabilities. Modern practice is to simply never publish one, and most security scanners flag an HINFO record as unnecessary information disclosure if they find one.

SSHFP — verifying SSH servers via DNS instead of blind trust

Normally, the first time you SSH into a new server, you get a prompt asking whether to trust its host key — a moment where you're basically taking it on faith. SSHFP records let a domain publish the fingerprint of its SSH host key directly in DNS (ideally protected by DNSSEC), so an SSH client configured to check it can verify the server's identity automatically instead of asking you to eyeball a fingerprint you have no real way to verify.

TLSA — DANE, or "what if certificate authorities weren't the only source of trust"

TLSA records are the core of DANE (DNS-based Authentication of Named Entities) — they let a domain publish, in DNS, exactly which TLS certificate (or which CA) should be presented for a given service. Combined with DNSSEC, this creates a second, independent channel for verifying a certificate is legitimate, rather than relying solely on the certificate authority system. It's seen real adoption in email (SMTP) security specifically, where it's used to prevent certain downgrade attacks.

NAPTR — the record type behind number portability

NAPTR records rewrite an identifier into a URI through an ordered set of regular-expression-like rules, most notably powering ENUM — systems that translate phone numbers into SIP addresses for VoIP routing. It's dense, and most web developers will go an entire career without touching one directly, but it's quietly doing real work in telecom infrastructure.

URI — a record type for pointing at, well, a URI

A more modern, general-purpose record for publishing a URI associated with a service, with priority and weight fields similar to MX and SRV records. It never achieved wide adoption outside a few specific protocols, but it's a good example of DNS continuing to be extended for new use cases well into the 2010s.

Why any of this matters

You'll probably never need to hand-write a LOC or NAPTR record. But knowing these exist is a useful reminder of what DNS actually is: not just "the thing that turns names into IP addresses," but a general-purpose, hierarchical, globally distributed key-value store that the internet has spent forty years bending toward new problems. Run a scan on any domain and DNSDecode will surface every record type it finds — including the occasional oddball.