Over the years, several methods have been devised to publish cryptographic keys in the DNS tree. This page presents some of them briefly.
The DANE workgroup has
created two specific DNS record types for publishing X.509 certificates:
TLSA record type (RFC 6698) for
certificates used by TLS servers, and the
for certificates used in S/MIME applications.
They differ by the name under which the record is located:
The record data is the same for both record types and contains:
Cert) or only the public key (
Full), or only a hash of it (
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
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
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]
The DANE workgroup has also proposed the
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 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
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
type. The record name is made up of the local part of the email
_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:
CERT, with the
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.
Fingerprints for the public keys of a SSH server can be published
SSHFP records as specified in RFC 4255.
The record name is simply the hostname of the SSH server. The record data contains:
host.example.org. IN SSHFP 1 2 [fingerprint]
SSHFP records are fully supported by OpenSSH. They can be generated
-r option of ssh-keygen(1), and the SSH
client can be instructed to lookup those records with the
VerifyHostKeyDNS configuration option.