DNSSEC and CAA Records: Securing Your DNS Infrastructure

DNSSEC: What It Protects Against

Standard DNS has no built-in authentication. When a resolver asks for the IP address behind example.com, it trusts whatever response arrives first. This design makes DNS vulnerable to two well-known attacks:

• Cache poisoning. An attacker injects forged DNS responses into a resolver's cache. Every user of that resolver is then silently redirected to an attacker-controlled server. The authoritative nameserver is never modified -- the poisoning happens entirely at the resolver layer.
• Spoofing. An attacker on the network path between a client and its resolver forges responses in real time, redirecting individual queries without touching any cache.

DNSSEC (Domain Name System Security Extensions) counters both attacks by adding cryptographic signatures to DNS records. A validating resolver can verify that a response genuinely originated from the authoritative nameserver and was not tampered with in transit. For a broader look at the risks posed by unauthenticated DNS, see DNS Security: What Your Domain Configuration Reveals to Attackers.

How DNSSEC Signing Works

DNSSEC uses a chain of trust rooted at the DNS root zone and extending down through each level of the hierarchy.

1. Zone Signing Key (ZSK). Each DNS zone has a ZSK, a public/private key pair. The private ZSK signs every record set (RRset) in the zone, producing RRSIG records that accompany each response.
2. Key Signing Key (KSK). The KSK signs the DNSKEY record set that contains the ZSK's public key. This separates day-to-day signing from the higher-trust key that anchors the zone.
3. DS record. A Delegation Signer record in the parent zone contains a hash of the child zone's KSK. This is the link that chains trust upward -- from your zone to the TLD, and from the TLD to the root.
4. Validation. A resolver walks the chain from the root's trust anchor down through each DS and DNSKEY record until it can verify the RRSIG on the record it actually requested. If any link is broken or a signature fails, the response is rejected.

Enabling DNSSEC at Your Registrar

The exact steps vary by DNS provider and registrar, but the general workflow is the same.

Step 1: Enable signing in your DNS provider. Most managed DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS, NS1) offer a toggle or API call to enable DNSSEC. When you enable it, the provider generates the ZSK and KSK, signs your zone, and publishes DNSKEY records.

Step 2: Retrieve the DS record details. Your DNS provider will present the DS record values: key tag, algorithm number, digest type, and digest. Copy these exactly.

Step 3: Publish the DS record at your registrar. Log in to your domain registrar (this may be a different company than your DNS provider) and add the DS record to your domain. The registrar publishes it in the parent zone (the TLD zone for most domains).

Step 4: Wait for propagation. DS records propagate according to TTL timelines. Allow 24-48 hours before assuming something is broken.

Step 5: Validate. Confirm the chain of trust is intact (see Verification below).

If your registrar and DNS host are the same company (common with Cloudflare, for example), steps 2 and 3 may be automatic.

DS Record Publication and the Validation Chain

The DS record is the critical handoff point. It lives in the parent zone, not in your zone, which means you cannot simply add it to your own zone file. It must be submitted through your registrar's interface or API.

A correct chain looks like this:

Root (.) -> DS for .com -> .com DNSKEY
.com -> DS for example.com -> example.com DNSKEY
example.com DNSKEY -> RRSIG -> verified A/MX/TXT records

Common failures include mismatched DS records after a key rollover, DS records pointing to a KSK that has been rotated out, or the DS record simply not being present at the registrar. Any break in the chain causes SERVFAIL responses for DNSSEC-validating resolvers, effectively making your domain unreachable for those users.

CAA Records: Controlling Certificate Issuance

Certificate Authority Authorization (CAA) is a DNS record type (RFC 8659) that specifies which certificate authorities are permitted to issue certificates for your domain. All publicly trusted CAs are required to check CAA records before issuing a certificate. If a CAA record exists and the CA is not listed, the CA must refuse the request.

CAA Record Syntax

A CAA record has three components:

example.com. CAA <flags> <tag> <value>

• flags -- Usually 0. A value of 128 sets the critical flag, meaning a CA must refuse issuance if it does not understand the tag.
• tag -- One of issue, issuewild, or iodef.
• value -- The domain identifying the authorized CA, or a reporting URI.

Tag types:

• issue -- Authorizes a CA to issue standard (non-wildcard) certificates.
• issuewild -- Authorizes a CA to issue wildcard certificates. If absent, the issue tag applies to wildcards as well.
• iodef -- Specifies a URL or email address where CAs should report policy violations (e.g., someone requesting a certificate they are not authorized for).

Example: Restrict to Let's Encrypt Only

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"

This permits only Let's Encrypt to issue both standard and wildcard certificates. All other CAs must refuse. Violation reports go to your security inbox.

Example: Allow Let's Encrypt and DigiCert

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"

Here, both Let's Encrypt and DigiCert can issue standard certificates, but only Let's Encrypt can issue wildcards.

Example: Block All Certificate Issuance

staging.example.com. CAA 0 issue ";"

The semicolon with no CA domain means no CA is authorized. Use this on subdomains that should never have certificates issued for them.

CAA Inheritance

CAA records are inherited by subdomains. If you set a CAA record on example.com and do not set one on app.example.com, the parent's CAA policy applies to the subdomain. You can override this by setting explicit CAA records on specific subdomains.

Zone Transfer Restrictions (AXFR)

DNS zone transfers replicate an entire zone file from a primary nameserver to a secondary. When AXFR is left open to the public, anyone can request a full dump of every record in your zone -- every subdomain, every internal hostname, every IP mapping. This is a reconnaissance goldmine.

Why It Matters

An unrestricted zone transfer exposes records that were never meant to be discovered through normal lookups. Internal-only subdomains like jenkins.corp.example.com, vpn-mgmt.example.com, or db-primary.example.com become visible. Attackers get a complete map of your infrastructure without sending a single probe to your network. Keeping your registrar settings and WHOIS data locked down is equally important -- see our domain registration and WHOIS hygiene guide for essential registrar-level protections.

How to Restrict Zone Transfers

BIND (named.conf):

options {
    allow-transfer { 192.0.2.1; 198.51.100.1; };
};

Replace the IPs with your authorized secondary nameservers. Use allow-transfer { none; }; if you have no secondaries that pull via AXFR.

If you use a managed DNS provider (Cloudflare, Route 53, Google Cloud DNS), zone transfers are typically disabled by default or handled internally. Verify this in your provider's documentation -- do not assume.

Verification Commands

Verify DNSSEC

Check that DNSSEC signatures are present and valid:

dig +dnssec example.com A

Look for the ad (Authenticated Data) flag in the response header and RRSIG records in the answer section. If the ad flag is absent, the response was not DNSSEC-validated.

For a full chain-of-trust check:

dig +dnssec +multi example.com DNSKEY
dig DS example.com @a.gtld-servers.net

The second command queries the parent zone's nameserver directly for your DS record. Online tools like DNSViz (dnsviz.net) provide a visual representation of the entire chain.

Verify CAA Records

dig CAA example.com

The response should list your CAA records with the correct tags and CA domains. If no records appear, any CA is permitted to issue certificates for your domain.

Test Zone Transfer Restrictions

dig @ns1.example.com example.com AXFR

Run this against each of your nameservers from an external network. The expected response is Transfer failed or a refused status code. If you receive a list of DNS records, zone transfers are open and need to be locked down immediately.

Putting It All Together

A properly secured DNS configuration combines all three measures. DNSSEC ensures that responses have not been tampered with between the authoritative server and the resolver. CAA records prevent unauthorized certificate authorities from issuing certificates for your domain. Zone transfer restrictions keep your full zone file from being enumerated by anyone on the internet. Each addresses a distinct threat, and none is a substitute for the others. To understand how DNSSEC compares with transport-layer protections like DoH and DoT, read our DNS privacy protocols comparison.