Publishing Keys in DNS

Over the years, several methods have been devised to publish cryptographic keys in the DNS tree. This page presents some of them briefly.

For X.509 certificates

The DANE workgroup has created two specific DNS record types for publishing X.509 certificates: the TLSA record type (RFC 6698) for certificates used by TLS servers, and the SMIMEA record type (draft-ietf-dane-smime) for certificates used in S/MIME applications.

They differ by the name under which the record is located:

for TLSA records, the name is made up of the following components:
- the port number the server is listening to, preceded by an underscore;
- the transport protocol (either _tcp or _udp);
- the server hostname ¹;
for SMIMEA records, the name is made up as follows:
- the local part of the email address associated with the certificate, hashed by the SHA2-256 function and truncated to the first 28 octets;
- the _smimecert label;
- the domain part of the email address.

The record data is the same for both record types and contains:

a value indicating the certificate usage (one of PKIX-TA, PKIX-EE, DANE-TA, or DANE-EE);
a value indicating whether the record contains the full certificate (Cert) or only the public key (SPKI);
a value indicating whether the record contains the certificate (or the public key) itself (Full), or only a hash of it (SHA2-256 or SHA2-512);
finally, either the DER-encoded certificate or public key, or the corresponding fingerprint.

Here are some example TLSA or SMIMEA records:

_443._tcp.www.example.org. IN TLSA DANE-TA Cert SHA2-256 [fingerprint]
2bd8[…]71db._smimecert.example.org. IN SMIMEA DANE-EE SPKI Full [public key]

Support for TLSA records has been introduced in Bind 9.9.1; Bind does not support (as of december 2015) SMIMEA records yet, but they can still be represented in a zone file using the RFC 3597 syntax.

On the client side, the DNSSEC/TLSA validator plugin brings TLSA support to most web browsers; Postfix (when acting as a SMTP client) also has full support for TLSA records.

There is another record type which can be used to publish X.509 certificates: the CERT type as described in RFC 4398. The same type can also be used to publish OpenPGP public keys.

However, although RFC 4398 is still officially a current standard, CERT records have been informally deprecated in favor of the new record types from the DANE workgroup.

Example CERT records:

host.example.org. IN CERT PKIX 0 0 [DER-encoded X.509 certificate]
alice.example.org. IN CERT PGP 0 0 [OpenPGP public key packet]

For OpenPGP keys

The DANE workgroup has also proposed the OPENPGPKEY record type (draft-ietf-dane-openpgpkey) for publishing OpenPGP public keys.

The name under which the record is located is built up similarly to SMIMEA records above:

the local part of the email address associated with the key, hashed with the SHA2-256 hash function and truncated to the first 28 octets;
the _openpgpkey label;
the domain part of the email address.

The record data is simply the OpenPGP public key packet (the current draft does not allow to publish only a fingerprint).

Here is an example OPENPGPKEY record:

2bd8[…]71db._openpgpkey.example.org. IN OPENPGPKEY [Public key packet]

Support for the OPENPGPKEY record type has been introduced in Bind 9.9.7 and 9.10.2.

GnuPG since version 2.1.9 also supports the current draft specification. It can both print records suitably formatted for insertion into a zone file (with the --print-dane-records option), and automatically lookup for such records when given an email address and fetch the corresponding key (--auto-key-locate dane).

Before the DANE workgroup, GnuPG developers independently devised their own method to publish and lookup OpenPGP keys in the DNS: the Public Key Association record or PKA, of which two versions exist.

Version 1 PKA records are based on the TXT record type. The record name is made up of the local part of the email address, the _pka label, and the domain part. The record data contains either the key fingerprint or an URL pointing to the full public key, or both, as in the following example:

alice._pka.example.org. IN TXT "v=1;fpr=[fingerprint];uri=http://example.org/~alice/key.asc"

Version 1 PKA records are deprecated and only usable with GnuPG up to version 2.1.2. Starting from GnuPG 2.1.3, PKA records use a new format with the following differences:

the local part of the email address is encoded in Zooko’s Base32 encoding;
the record type is CERT, with the IPGP subtype;
only the key fingerprint is published.

Here is an example of such a “version 2” PKA record:

kei1[…]31xe._pka.example.org. IN CERT IPGP 0 0 14 [key fingerprint]

Both versions of PKA records are non-standard and specific to GnuPG, and should probably be avoided in favor of the soon-to-be-standardized OPENPGPKEY record.

For SSH keys

Fingerprints for the public keys of a SSH server can be published using SSHFP records as specified in RFC 4255.

The record name is simply the hostname of the SSH server. The record data contains:

a value indicating the type of key (1 for RSA keys, 2 for DSA keys, 3 for ECDSA keys);
a value indicating the type of fingerprint (1 for SHA-1, 2 for SHA2-256);
the fingerprint itself.

Example:

host.example.org. IN SSHFP 1 2 [fingerprint]

SSHFP records are fully supported by OpenSSH. They can be generated using the -r option of ssh-keygen(1), and the SSH client can be instructed to lookup those records with the VerifyHostKeyDNS configuration option.

↑ See RFCs 7671, 7672, and 7673 for considerations on the hostname to use in the TLSA record.

6 December 2015