This is a running list of unusual data found in the Domain Name System.

Typically, DNS stores name-to-IP (for example, foo.example.net -> 192.0.2.123) and IP-to-name mappings (i.e., the inverse). But, the DNS is arguably the biggest, most distributed key/value store on the planet, making it a great place to stash all kinds of simple data.

For a type of data to be considered for this list, I use this criteria:

  1. It does not fall into the "majority use case" category of name/IP lookups, mail exchanger lookups, etc.
  2. It is standards-based. Something random that someone somewhere plunked into a zone file does not make the cut.
  3. The data does not need to use a unique record type (for example, using a TXT record for something is allowed).
  4. The data is something that I've worked directly with.

Automated Certificate Management Environment (ACME) domain validation⌗

To quote Wikipedia, ACME is a protocol for "automating interactions between certificate authorities and their users' web servers, allowing automated deployment of public key infrastructure [...]."

In other words, it's a protocol that enables programmatic request and receipt of X.509 certificates to enable secure network services such as TLS-secured web sites. ACME is documented in RFC 8555.

One of the mechanisms used to prove ownership of the domain in the certificate request is to use DNS.

  1. The ACME server sends a random value known as the "token" to the requestor.
  2. The requestor uses their account key--which only they possess--to construct a "key authorization".
  3. The requestor computes the SHA-256 digest of the key authorization, base64-encodes it, and whacks it into the DNS zone for the domain being verified.

The requestor uses the TXT record type and builds the record's domain name by prepending _acme-challenge to the domain. For example, the authorization record for www.example.org would look similiar to:

_acme-challenge.www.example.org. 300 IN TXT "gfj9Xq...Rg85nM"

SSH server public key fingerprints⌗

When an SSH client connects to an SSH server, the server presents the client with its public host key. Notionally, the client is supposed to use this public key to validate the identity of the server. There is a problem though: what does the client do the very first time it connects to the server? What does it compare the presented host key against?

Ideally, the client would have access to some out-of-band mechanism which would pre-populate the server's host key into the client's known_hosts file. But that adds complexity. If only there was some sort of highly distributed database that could store key/value pairs...

The SSHFP or SSH Fingerprint record type stores the fingerprint for a host's public SSH key. For example:

host.example.net. SSHFP 4 2 12345...ABCD

When an SSH client connects to host.example.net, it can issue a DNS query to retrieve the SSHFP record and use the fingerprint(s) in the answer to validate the public key that the server is presenting.

The OpenSSH client uses the VerifyHostKeyDNS configuration setting to control whether a DNS query will be issued. The ssh-keygen command can be used to generate SSHFP records which can be copied into a zone file.

ssh-keygen -r host.example.net

The SSHFP record was standardized in RFC 4226 (Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints).