How DNS Secures SSL & PKI (CAA, TLSA, DNSSEC)

Public Key Infrastructure (PKI) is the framework that enables secure, encrypted connections across the internet using SSL/TLS certificates. Traditionally, this relied entirely on third-party Certificate Authorities (CAs). Today, domain owners can use specific DNS records to take back control, enforce strict security policies, and prevent rogue certificate issuance.

Audit your DNS Security Posture

Is your Let's Encrypt renewal failing? Test your CAA, TLSA, and DNSSEC setup all at once.

Run the SSL/PKI DNS Check

The Security Triad: CAA, TLSA, and DNSSEC

To fully secure a domain against Man-in-the-Middle (MitM) attacks and fraudulent certificates, three distinct DNS records must work in harmony:

  • CAA (Certificate Authority Authorization): The Gatekeeper. This record tells the world exactly which companies are allowed to issue an SSL certificate for your domain. If a hacker tries to buy a certificate from an unauthorized CA, the CA will check your CAA record and block the request.
  • TLSA (DANE Binding): The Verifier. This record acts as a cryptographic "pin". It publishes a hash of your exact SSL certificate in your DNS. When a client connects to your server, they verify that the certificate presented matches the hash in your DNS.
  • DNSSEC (Chain of Trust): The Foundation. Because a hacker could theoretically spoof your DNS to send fake CAA or TLSA records, DNSSEC cryptographically signs your entire DNS zone. Without DNSSEC, TLSA records cannot be trusted.

SSL/PKI DNS FAQ

Yes, absolutely. The DANE protocol (which utilizes TLSA records) strictly requires that the DNS response containing the TLSA record is cryptographically signed and verified by DNSSEC. If DNSSEC is disabled or broken, DANE validators will ignore your TLSA records.

The most common reason is a restrictive CAA record. If your domain has a CAA record that only authorizes digicert.com, and you attempt to use a tool like Certbot to generate a free certificate from letsencrypt.org, Let's Encrypt is legally required to refuse the issuance until you add them to your CAA policy.

Timing is critical. You must generate the hash of your new upcoming certificate, publish it alongside your old hash in the DNS, and wait for the DNS TTL to expire. Only once the new TLSA record is fully propagated globally should you swap the physical certificates on your web server.

No, standard HTTPS works perfectly fine without TLSA or DANE. It simply relies on the traditional Certificate Authority trust model built into your browser. TLSA is an additional layer of security, primarily used today to secure server-to-server SMTP (email) traffic against downgrade attacks.