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:
- It does not fall into the "majority use case" category of name/IP lookups, mail exchanger lookups, etc.
- It is standards-based. Something random that someone somewhere plunked into a zone file does not make the cut.
- The data does not need to use a unique record type (for example, using a
TXTrecord for something is allowed).
- 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.
- The ACME server sends a random value known as the "token" to the requestor.
- The requestor uses their account key--which only they possess--to construct a "key authorization".
- 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
_acme-challenge to the domain. For example, the authorization
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...
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
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
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
SSHFP record was standardized in RFC 4226 (Using DNS to Securely
Publish Secure Shell (SSH) Key