DNS is a critical dependency for every web application, and it operates largely on trust. Standard DNS responses are not authenticated: a resolver cannot verify that a response actually came from the authoritative name server for a domain. DNSSEC adds cryptographic signatures to DNS responses. CAA records restrict which certificate authorities may issue TLS certificates for a domain, closing a separate but related attack path.
This article covers what DNSSEC and CAA records do, how they differ from each other, how to configure each, and how to verify they are correctly active.
The DNS Trust Problem
When a browser resolves example.com, it queries a recursive resolver. The resolver queries authoritative name servers and returns the result. Without DNSSEC, neither the browser nor the resolver can cryptographically verify that the returned answer is authentic. A compromised resolver, a cache poisoning attack, or a BGP hijack can return forged DNS responses, redirecting users to attacker-controlled infrastructure while the browser believes it is communicating with the legitimate site.
Separately, the CA/Browser Forum requires certificate authorities to check CAA records before issuing a certificate for a domain. Without a CAA record, any of the hundreds of publicly trusted CAs may issue a certificate for your domain. A CAA record narrows this to a specific set of CAs you explicitly authorize.
DNSSEC: Cryptographic DNS Validation
How DNSSEC Works
DNSSEC adds digital signatures to DNS record sets. The zone operator signs each record set with a private key. The corresponding public key is published in the DNS as a DNSKEY record. Resolvers that support DNSSEC validation fetch the signature alongside the DNS record and verify it against the published public key.
The chain of trust starts at the DNS root. The root zone is signed, and each delegated zone can be signed and linked to its parent through DS (Delegation Signer) records. For a domain like example.com, the chain is:
- Root zone signs and publishes the trust anchor for the
.comTLD. - The
.comregistry publishes a DS record forexample.comthat references the zone's DNSKEY. - The
example.comzone is signed with a key that a validating resolver can verify by following the chain from the root.
When DNSSEC validation is enabled, a forged DNS response fails signature verification and is rejected by the resolver. The client receives an error rather than the forged address.
Enabling DNSSEC
DNSSEC is configured at the DNS hosting provider level, not in the application. The process varies by registrar and DNS provider, but the general steps are:
- Enable DNSSEC signing in your DNS provider's control panel. The provider generates a key pair and signs all zone records. This is handled automatically by most modern DNS providers (Cloudflare, Route 53, Google Cloud DNS).
- The provider gives you a DS record (or the key data needed to generate one). Submit this DS record to your domain registrar. The registrar publishes it in the parent zone (
.com,.net, etc.), completing the chain of trust. - Verify the chain is complete using a DNSSEC validator.
The DS record submission to the registrar is the step most commonly missed. If the DNS provider has signed the zone but no DS record is published in the parent zone, the DNSSEC chain is not established and validating resolvers do not check signatures.
# Check if DNSSEC is enabled and the chain is valid
dig +dnssec example.com
# Check the DS record in the parent zone
dig DS example.com @8.8.8.8
# Validate the full chain with an online tool
# https://dnssec-debugger.verisignlabs.com/
# https://dnsviz.net/DNSSEC Limitations
DNSSEC authenticates DNS responses but does not encrypt them. A network observer can still see which domains are being resolved. DNS over HTTPS (DoH) and DNS over TLS (DoT) provide query privacy but are separate from DNSSEC; the two mechanisms complement each other.
DNSSEC also does not protect against a compromised DNS provider account. If an attacker gains access to your DNS provider's control panel, they can modify records and re-sign them. DNSSEC assumes the zone operator's signing keys are secure.
CAA Records: Restricting Certificate Issuance
A Certification Authority Authorization (CAA) record is a DNS record that specifies which certificate authorities are authorized to issue TLS certificates for a domain. Since September 2017, the CA/Browser Forum Baseline Requirements mandate that CAs must check CAA records before issuance and must not issue a certificate if a CAA record prohibits it.
Without a CAA record, any trusted CA may issue a certificate for your domain. While certificate misissuance is relatively rare, it has occurred: a CA that issues a certificate for a domain it should not have authorized gives any holder of that certificate the ability to run a TLS-encrypted site that appears legitimate to browsers.
CAA Record Syntax
CAA records have three fields: flags, tag, and value. The two most used tags are issue (authorizes a CA to issue standard certificates) and issuewild (authorizes a CA to issue wildcard certificates).
# Allow only Let's Encrypt to issue certificates for example.com
example.com. CAA 0 issue "letsencrypt.org"
# Allow Let's Encrypt and DigiCert
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
# Allow no CAs to issue wildcard certificates (more restrictive)
example.com. CAA 0 issuewild ";"
# Block all certificate issuance entirely (useful for domains that should never have certs)
example.com. CAA 0 issue ";"
# How to add in common DNS providers (the format is usually just the tag and value):
# Cloudflare: add a CAA record with tag "issue" and value "letsencrypt.org"
# Route 53: same — choose CAA type, enter the record value in standard formatThe CA identifier values for commonly used CAs:
- Let's Encrypt:
letsencrypt.org - DigiCert:
digicert.com - Sectigo (formerly Comodo):
sectigo.com - GlobalSign:
globalsign.com - Google Trust Services:
pki.goog - ZeroSSL:
zerossl.com
Handling Wildcard Certificates
The issue tag controls standard certificate issuance. The issuewild tag controls wildcard certificate issuance separately. If you have only an issue record and no issuewild record, the issue record applies to wildcard certificates as well. WebDefect flags a CAA record that has issuewild entries but no corresponding issue restriction as an informational finding, because the intent may be ambiguous.
If you use wildcard certificates, explicitly add issuewild records to make the authorization intent clear:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"Violation Reporting with iodef
The iodef tag specifies a URL or mailto address where the CA should report any certificate issuance requests that violate the CAA policy. This provides notification if a CA attempts to issue a certificate that the CAA record does not authorize, which may indicate an attempt to obtain an unauthorized certificate.
example.com. CAA 0 iodef "mailto:security@example.com"Not all CAs implement iodef reporting, but adding it costs nothing and provides visibility when a CA does support it.
Verifying DNSSEC and CAA
# Check CAA records
dig CAA example.com
# Expected output: one or more CAA records listing authorized CAs
# Check DNSSEC signatures on a specific record type
dig +dnssec A example.com
# Look for RRSIG records accompanying the A record response
# Validate the DNSSEC chain
dig DS example.com @a.gtld-servers.net
# Should return DS record if the registrar has published it
# Online DNSSEC chain validator:
# https://dnssec-analyzer.verisignlabs.com/example.comHow WebDefect Checks DNSSEC and CAA
WebDefect's DNS phase queries the target domain for both DNSSEC and CAA configuration:
- DNSSEC (
dns-002): The scanner checks for the presence of DNSKEY records at the domain and whether the response includes RRSIG records indicating active signing. The absence of DNSSEC is flagged as low severity, reflecting that DNSSEC adoption is not universal and the configuration requires registrar cooperation. - CAA records (
dns-003): The scanner queries for CAA records at the domain. The absence of any CAA record is flagged as low severity. The presence of a CAA record that hasissuewildentries without a correspondingissuerestriction is flagged as an informational finding (dns-010).
Both findings are low severity because neither directly enables an attack against the application. They represent the absence of defense-in-depth controls rather than exploitable misconfigurations. Their value increases significantly in threat models that include supply chain attacks on certificate infrastructure or targeted DNS manipulation.