Storing Certificates in the Domain Name System (DNS)
obsoletes
- rfc-2538 — Storing Certificates in the Domain Name System (DNS)
updated by
- rfc-6944 — Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
Extracted elements (26)
CERT RRs for email (S/MIME or OpenPGP) change DNS access patterns from per-domain to per-user lookups. Wide deployment of certificate-based signed email could substantially increase DNS query volume and degrade cache effectiveness, though the magnitude of this impact is unknown.
The IPKIX, ISPKI, IPGP, and IACPKIX indirect types were introduced because the DNS RDATA field is limited to 65535 octets, making it impossible to store large certificates or CRLs inline. Indirect types carry a URL reference instead of the certificate data itself.
Two owner name guidelines are defined: content-based (derived from certificate content such as Subject field or OpenPGP User ID) and purpose-based (a name the client already knows, such as TLS server hostname or email address). Purpose-based names are preferred because clients may not know all certificate content fields prior to retrieval.
The algorithm field in the CERT RR has the same meaning as in DNSKEY and RRSIG RRs, except that an algorithm value of zero indicates the algorithm is unknown to secure DNS — which may simply mean it has not been standardized for DNSSEC. The CERT RR reuses the DNS Security Algorithm Numbers registry and requires algorithm 0 remain reserved.
The SPKI and ISPKI types are reserved for the SPKI certificate format but their format is not yet specified, pending SPKI documents advancing from experimental status (RFC 2692/2693). Implementations encountering these types cannot currently interpret the certificate portion.
Each CERT RR MUST NOT contain more than 65535 octets (64 KB) of payload, even if the corresponding certificate or CRL is larger. The indirect types address this by allowing the CERT RR to reference external content via URL.
For the PGP certificate type, the data is binary and MUST NOT be encoded into ASCII armor. An implementation SHOULD process transferable public keys as described in Section 10.1 of RFC 2440, but MAY handle additional OpenPGP packets.
For the URI private certificate type, the certificate portion of the CERT RR MUST begin with a null-terminated URI, and the data after the null is the private format certificate itself.
Implementations SHOULD use the purpose-based owner name guidelines described in this document and MAY use CNAME RRs at content-based owner names pointing to the purpose-based owner name.
The indirect types (IPKIX, ISPKI, IPGP, IACPKIX) MUST be used when the certificate content is too large to fit in the CERT RR, and MAY be used at the implementer's discretion. They SHOULD NOT be used where the DNS message is 512 octets or smaller and could fit in a UDP packet.
The key MUST be transformed to the format it would have as the public key portion of a DNSKEY RR before the key tag is computed. If the key is not applicable to a DNS security algorithm, the algorithm field MUST be zero and the key tag SHOULD be zero.
X.509 certificates conforming to the IETF PKIX profile SHOULD be indicated by the PKIX type, not the OID private type.
For content-based X.509 CERT RR naming, priority order is: (1) domain name in certificate/CRL identification, (2) reverse DNS of IP address, (3) domain name extracted from a URI in the certificate, (4) character string name treated as OpenPGP-style, (5) distinguished name mapped to domain per RFC 2247.
For purpose-based OpenPGP CERT RR naming, the owner name should be the key fingerprint or Key ID expressed in hexadecimal. Multiple owner names can be used (full fingerprint, partial fingerprint, Key ID), and CNAME can reduce duplication when the same key material is stored under multiple names.
Purpose-based X.509 CERT RR owner names by scenario: S/MIME uses RFC 2822 email address translated to hostname (e.g., postmaster.example.org); TLS uses the server hostname; IPsec uses the machine hostname and/or reverse DNS of the IP address.
The IPGP certificate type contains a one-octet fingerprint length, followed by the OpenPGP fingerprint (computed as per RFC 2440), followed by the URL. A zero-length fingerprint or zero-length URL is legal (URL-only or fingerprint-only), but both being zero-length is invalid.
The key tag field is a 16-bit value computed for the key embedded in the certificate using the RRSIG Key Tag algorithm. It serves as an efficiency measure to narrow which CERT RRs may be applicable to a given key, but note that two different keys can share the same key tag.
The OID private type certificate section begins with a one-octet unsigned OID length followed by a BER-encoded OID indicating the nature of the remainder of the certificate section. Recognition of private types may use OID prefix matching rather than exact equality.
The PKIX type certificate section begins with a one-octet unsigned OID length followed by an X.500 OID indicating the nature of the remainder. Defined OIDs include id-at-userCertificate (0x03 55 04 24), id-at-cACertificate (0x03 55 04 25), id-at-authorityRevocationList (0x03 55 04 26), and id-at-certificateRevocationList (0x03 55 04 27).
IANA created a new registry for CERT RR certificate types. Initial values include: 0 (Reserved), 1 PKIX, 2 SPKI, 3 PGP, 4 IPKIX, 5 ISPKI, 6 IPGP, 7 ACPKIX, 8 IACPKIX, 9-252 (IANA assignment via Standards Action), 253 URI, 254 OID, 255 (Reserved), 256-65279 (IANA assignment via IETF Consensus), 65280-65534 (Experimental), 65535 (Reserved).
Certificates contain their own authenticating signatures, so it is reasonable to store them in non-secure DNS zones or retrieve them without DNS security checking. The retrieved certificate may be trusted if the certificate chain is verified back to a known trusted key, or if DNSSEC verification is used in lieu of chain verification.
If an organization stores CERT RRs by employee owner name and DNSSEC with NSEC is in use, an attacker can enumerate all employees by walking the zone. This is analogous to publicly exposing an enterprise phone directory and is generally undesirable.
If DNSSEC is deployed, the non-existence of a CERT RR — and therefore of certificates or revocation lists — can be securely asserted. Without DNSSEC, this negative assertion cannot be made reliably.
Using the URI (indirect) types introduces an additional level of indirection that may be exploited. One mitigation is to include a hash of the certificate in the URI itself, so that a retrieved document can be verified against the expected content.
In master file text representation, the CERT RR RDATA type field is an unsigned decimal integer or mnemonic, the key tag is an unsigned decimal integer, the algorithm field is an unsigned decimal integer or mnemonic, and the certificate/CRL is represented in base 64 (RFC 3548), which may be split across lines using parentheses.
The CERT RR wire format consists of a 16-bit type field, a 16-bit key tag field, an 8-bit algorithm field, and a variable-length certificate or CRL field. The RR type code is 37.