Two DNS Records That Take 3 Minutes to Add: How CAA and DNSSEC Stop Attackers From Issuing Fake SSL Certificates

The Public Key Infrastructure Blindspot: Trusting 100+ Certificate Authorities

Every green padlock, TLS connection, and HTTPS session on the web relies on an uncomfortable reality: the global Public Key Infrastructure (PKI) operates on universal cross-trust.

Your web browser and operating system trust well over 100 root Certificate Authorities (CAs) distributed across dozens of foreign jurisdictions. Under default PKI rules, any single one of these 100+ CAs can issue a valid, trusted SSL/TLS certificate for your domain.

THE UNRESTRICTED CERTIFICATE AUTHORITY HAZARD

• Your Company: Uses Let’s Encrypt exclusively on HestiaCP / Nginx
• Attacker Compromises Obscure Foreign CA (or Spoofs ACME HTTP Validation): Requests fraudulent certificate for: https://yourcompany.com/
• Obscure CA Issues Fraudulent Certificate! (Signed by trusted root)
• Attacker Performs Man-in-the-Middle (MitM) via BGP Hijack or Rogue Wi-Fi: Browser Sees Valid Green Padlock! Zero Warnings! Customer Passwords Stolen!

If an attacker compromises an obscure regional CA in another country, tricks an automated domain validation system via BGP route hijacking, or exploits an insider at a commercial CA, they can mint a cryptographically valid SSL certificate for your exact domain name. Because every browser trusts that root CA, your visitors will see a valid TLS padlock while their encrypted traffic is silently intercepted and decrypted.

Fortunately, two lightweight DNS standards close this vulnerability completely: CAA Records (RFC 8659) and DNSSEC (RFC 4033).

Through our managed hosting and technical consulting practices, we configure these two records on every enterprise domain to establish an ironclad cryptographic perimeter on Debian GNU/Linux.

CAA Records: Restricting Who Can Issue Certificates

A Certificate Authority Authorization (CAA) record is a DNS record that acts as an explicit whitelist of approved certificate issuers.

Since September 2017, the CA/Browser Forum has legally mandated that every public Certificate Authority must query DNS for CAA records before issuing any SSL/TLS certificate. If your domain publishes a CAA record, and an unauthorized issuer receives a certificate request, the CA is legally and technically prohibited from signing it.

CAA ENFORCEMENT CHECKPOINT BY THE CA

• Attacker Infiltrates Commercial CA → Requests cert for example.com
• CA Automated Pipeline Queries DNS: dig CAA example.com
• RETURNED CAA RECORD: example.com. IN CAA 0 issue “letsencrypt.org” example.com. IN CAA 0 iodef “mailto:security@example.com”
• CA Evaluates Identity: “I am NOT Let’s Encrypt! Request is FORBIDDEN!”
• Certificate REJECTED! CA Sends Incident Report to security@example.com!

The Three Core CAA Tags

• issue: Explicitly authorizes a specific CA to issue standard single-domain or multi-domain certificates (e.g., "letsencrypt.org").
• issuewild: Restricts the issuance of wildcard certificates (*.example.com). If you set issue "letsencrypt.org" and issuewild ";" (a semicolon), no CA on Earth is permitted to issue wildcard certificates for your domain!
• iodef: Specifies an email address or webhook endpoint where CAs must report policy violation attempts.

DNSSEC: The Cryptographic Anchor That Makes CAA Inviolable

A CAA record on its own has an Achilles’ heel: unauthenticated DNS.

By default, DNS queries travel over cleartext UDP port 53. If an attacker controls a local router, poisons a public DNS cache, or executes a local ARP spoofing attack, they can intercept the CA’s DNS query and forge a reply claiming: “example.com has NO CAA records.” Seeing no CAA record, the CA proceeds with issuance.

This is why DNSSEC (Domain Name System Security Extensions) is mandatory.

THE DNSSEC CRYPTOGRAPHIC CHAIN OF TRUST

• ICANN Root Zone (.) → Signs .com zone key via Root KSK (Key Signing Key)
• .com TLD Registry → Signs example.com Delegation Signer (DS Record)
• Your DNS Nameserver → Signs CAA Record with Zone Signing Key (RRSIG Record)
• Recursive Resolver / CA: Mathematically verifies RSA/ECDSA signature!
• Result: Impossible to forge, spoof, or strip CAA records in flight!

DNSSEC does not encrypt your DNS queries; rather, it attaches cryptographic digital signatures (RRSIG) to every DNS record set. The cryptographic chain stretches from the ICANN root zone (.), down to the top-level domain registry (like .com or .pt), down to your individual nameserver.

If an attacker attempts to tamper with or strip your CAA records, the cryptographic signature fails verification, and the validating resolver discards the response with a SERVFAIL status.

3-Minute Configuration: Adding CAA and Enabling DNSSEC

Let us configure both records. The entire process takes less than three minutes using modern DNS providers like Cloudflare or standard BIND9 zone files.

1. The Production CAA Record Set

Add the following records to your domain’s DNS zone:

; Explicitly authorize ONLY Let's Encrypt for standard certs
example.com.    3600    IN    CAA    0 issue "letsencrypt.org"

; Forbid all wildcard certificate issuance completely
example.com.    3600    IN    CAA    0 issuewild ";"

; Receive real-time security alerts if an unauthorized CA is approached
example.com.    3600    IN    CAA    0 iodef "mailto:security@example.com"

If you also use Google Trust Services or DigiCert for enterprise backup infrastructure, simply add another issue line:

example.com.    3600    IN    CAA    0 issue "pki.goog"

2. Enabling DNSSEC with One Click

1. In your Cloudflare dashboard (or DNS provider), navigate to DNS → Settings → DNSSEC.
2. Click Enable DNSSEC. Cloudflare automatically generates your DS (Delegation Signer) record containing:
   • Key Tag (e.g., 2371)
   • Algorithm (e.g., 13 - ECDSA Curve P-256 with SHA-256)
   • Digest Type (e.g., 2 - SHA-256)
   • Digest (e.g., E2D3C4...)
3. Copy these four values and paste them into your domain registrar’s control panel (Namecheap, Porkbun, PTisp, OVH).
4. Within 15 minutes, the TLD registry publishes the DS record.

Verifying Your Defenses from the Linux Terminal

Never assume DNS security is working without terminal verification. Use standard dig queries to test both records:

# 1. Verify CAA Records are properly published
dig +noall +answer CAA example.com

# 2. Verify DNSSEC Cryptographic Signatures (Note the +dnssec flag and ad bit)
dig +dnssec +multiline example.com CAA

Look closely at the flags: in the dig output:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

The crucial marker is the ad (Authenticated Data) bit in the header! The presence of ad proves that your local recursive resolver verified the complete cryptographic chain of trust all the way from the ICANN root.

TERMINAL DNSSEC VERIFICATION CHECKLIST

• Command: dig +dnssec example.com CAA
• Check 1: Does the header contain the “ad” (Authenticated Data) flag? → YES!
• Check 2: Is an RRSIG record returned alongside the CAA records? → YES!
• Check 3: Does testing with a non-existent domain return NSEC3 proof? → YES!

Incident Response: What Happens When a Violation Occurs?

If a malicious actor or an automated internal script attempts to request an SSL certificate from an unauthorized CA, the CA generates an RFC-compliant JSON report and delivers it to your iodef address:

{
  "caa-report": {
    "certificate-authority": "digicert.com",
    "domain": "example.com",
    "request-time": "2026-10-19T14:32:00Z",
    "validation-method": "dns-01",
    "account-id": "unknown-requester-ip-198.51.100.42",
    "status": "rejected-caa-policy-violation"
  }
}

This instant telemetry provides your security operations team with early warning of targeted attacks, allowing you to trace compromised developer accounts or identify misconfigured continuous deployment pipelines before any breach occurs.

By investing 3 minutes to publish CAA records and activate DNSSEC, you eliminate an entire class of man-in-the-middle attacks. Guided by our anti-over-engineering principles, you achieve enterprise-grade transport security without expensive proprietary software. Explore open-source DNSSEC auditing tools on GitHub to keep your domain zones cryptographically sound.

Alongside our operational work at Webxtek Studio, we apply these exact architectural standards across specialized sectors including b2b cybersecurity & corporate intelligence and extreme cybersecurity & pen-testing. Whether you are modernizing core workflows through managed hosting for websites and apps and technical consulting before you build, connecting sector-specific requirements to disciplined execution is what turns technical theory into compounding commercial advantage.