DNS Security: DNSSEC, CAA and Domain Protection

Reviewed October 2026.

What DNS controls

DNS turns your domain into the addresses of your website, your mail servers and every service under it. Whoever can change your DNS can redirect visitors, receive your mail and get certificates issued for your names. Two places hold that control.

The registrar holds the domain's registration: who owns it, when it expires, which nameservers it is delegated to and, with DNSSEC, its DS record.
The DNS host serves the zone, the records themselves. It is often the same company as the registrar, but need not be.

Record	What it does	Why it matters for security
A and AAAA	Map a name to IPv4 and IPv6 addresses	Where visitors go; an address you no longer hold is a takeover risk
CNAME	Makes a name an alias of another name	Often points at a hosted service, and dangles when the service is removed
MX	Names the servers that receive mail for the domain	Where your mail is delivered
TXT	Free text: SPF, DMARC, DKIM keys, verification tokens	Email authentication, and old tokens that prove control to third parties
NS	Delegates a name to nameservers	Control of the whole zone, or of a subdomain
CAA	Lists the certificate authorities allowed to issue	Limits who can get certificates for your names
DS	Held at the parent zone, links it to your DNSSEC keys	Makes DNSSEC validation possible

Keep the records in order

Most DNS problems are records nobody remembers adding. Keep a list of what each record is for and who owns it, and review it whenever a service is added or retired.

Give every record an owner and a reason. A record with neither is a candidate for removal.
When a service is retired, remove its records as part of the retirement, before the service itself is deleted.
Remove verification TXT records once they have done their job, where the service allows it.
Watch critical records for unexpected changes: NS, MX, the website's address records and anything delegated to a third party. NCSC guidance recommends monitoring them.

DNS checker Look up a domain's A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and DS records through public resolvers.

Nameserver redundancy

If the only nameserver for a domain is unavailable, the website, email and everything else under the domain stop resolving. Delegate to at least two nameservers on separate networks. RFC 2182 recommends three for most organisation-level zones, with at least one well removed from the others, and notes that large numbers add little benefit.

Managed DNS providers normally supply several nameservers on separate networks by default. They still share one provider and one account. Serving the zone from two providers removes that dependency, but both copies must be kept in step and, with DNSSEC, both must serve correctly signed answers. For most small organisations a reputable managed provider and a well-protected account is the practical choice.

Findings and fixes are in the nameserver redundancy check reference.

DNSSEC

DNSSEC (RFC 4033) signs DNS data so that a validating resolver can tell a genuine answer from a forged or altered one. It protects against an attacker who can tamper with DNS traffic, for example by poisoning a resolver's cache. It does not encrypt anything: DNS answers stay readable.

The chain of trust runs down from the root. Your DNS host signs the zone, and a DS record at the parent zone, published through your registrar, vouches for your keys.

Turn on signing at your DNS host.
Publish the DS record it gives you at your registrar. Where the DNS host is also the registrar, this may happen for you.
Check that the domain validates.

The cost is operational. If the DS record at the parent stops matching the keys that sign the zone, validating resolvers reject every answer and the domain stops resolving for their users. The usual cause is moving to a new DNS host without planning for the keys: either remove the DS record and wait for it to expire from caches before the move, or follow the new host's procedure for moving a signed zone. NCSC guidance notes that key management and zone signing need care.

Many domains run safely without DNSSEC, which is why Ironfang reports its absence as a low-severity hardening item. Turn it on when your DNS host supports it and you know who will handle a change of provider.

DNSSEC checker See whether a domain's zone is signed, with a DS record at its parent.

Findings and fixes are in the DNSSEC check reference.

CAA records

A CAA record (RFC 8659) names the certificate authorities allowed to issue certificates for your domain. A publicly trusted CA must check for it before issuing, and must refuse if it is not allowed. Without CAA, any public CA may issue for the domain.

A record allowing one CA: example.com. CAA 0 issue "letsencrypt.org"

issue lists CAs allowed to issue certificates for the name; issuewild overrides it for wildcard certificates.
iodef gives an address where a CA can report a request that broke your policy, for example CAA 0 iodef "mailto:security@example.com".
CAA 0 issue ";" allows no CA at all, which suits a name that should never have a certificate.
A CA looks for CAA at the name the certificate is for, then climbs towards the root, so a record at example.com covers its subdomains unless a subdomain publishes its own.

CAA governs issuance only. It has no effect on certificates already issued, and browsers do not check it.

CAA checker See which certificate authorities a domain allows to issue its certificates.

Findings and fixes are in the CAA check reference.

Dangling records and subdomain takeover

A dangling record points at something you no longer control. The common case is a CNAME left behind when a hosted service, such as a cloud app, a storage bucket or a hosted page, was deleted. If the platform lets another customer claim the same resource name, they can serve their content on your subdomain, under your domain's name. This is subdomain takeover.

Whether a particular dangling record can be taken over depends on the platform. Some never hand a released name to anyone else, or ask for proof of domain ownership first; others do not. Treat every dangling record as something to remove, without assuming each one is exploitable.

The risk is not limited to CNAMEs. OWASP's testing guide lists A, MX, NS and TXT records as well: an address record for a cloud IP address that has been released, an MX record for a mail service you left, or an NS delegation to a zone that has been deleted. A dangling NS record is the most serious, because it can hand over control of every name beneath it. A CNAME to an external domain that has expired is another route, since whoever registers that domain controls your subdomain.

Ironfang's dangling DNS check looks for CNAME records whose target name no longer resolves. A clean result does not rule out every form of takeover: an address record for a released IP address, or a CNAME to a resource that still resolves but now belongs to someone else, looks normal from outside. The fix is the same in every case. Remove the records when you retire the service, and in that order.

Dangling DNS checker Find a CNAME that points at a name that no longer exists.
Subdomain finder Find a domain's subdomains in public certificate transparency logs.

The subdomain finder lists names that appear in public certificate transparency logs, a useful start for finding names you may have forgotten. Findings and fixes for dangling records are in the dangling DNS check reference.

Registrar account security and locks

Whoever controls the registrar account controls the domain: they can change its nameservers, remove DNSSEC or transfer it away. Protect it as you would the email administrator account.

Turn on two-step verification for every user of the registrar account, as NCSC guidance recommends.
Register the domain to the organisation, with contact addresses on the organisation's own systems rather than a personal mailbox that leaves with its owner.
Limit who can log in, and give each person their own login where the registrar allows it.
Set the domain to renew automatically, paid by a method the organisation maintains rather than a personal card. An expired domain can be registered by someone else.
Know the registrar's procedure for reclaiming a hijacked domain, and keep the registration documents.

Locks

Registrars and registries can lock a domain against changes. The locks appear as EPP status codes (RFC 5731) in the domain's public registration data.

Lock	Status codes	What it stops
Registrar lock	`clientTransferProhibited`, often with `clientUpdateProhibited` and `clientDeleteProhibited`	Transfers and, with the others, changes and deletion, until the registrar removes the lock at your request
Registry lock	`serverTransferProhibited`, `serverUpdateProhibited`, `serverDeleteProhibited`	The same, set by the registry; removing it needs extra verification outside the control panel, often a call to a named contact

A registrar transfer lock is usually a setting in the control panel; keep it on for every domain you are not moving. A registry lock, where the registry offers one, may carry a fee and adds a step to every change. It suits high-value domains whose nameservers rarely change.

Checking your DNS

DNS security checker Check a domain's address records, nameserver redundancy, CAA, DNSSEC and dangling CNAMEs.
DNS checker Look up a domain's A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and DS records through public resolvers.
DNSSEC checker See whether a domain's zone is signed, with a DS record at its parent.
CAA checker See which certificate authorities a domain allows to issue its certificates.

What a check can show, and what it cannot

Ironfang can check

The records a domain publishes, as public resolvers see them
How many nameservers the domain is delegated to
Whether a DS record exists at the parent zone
CAA records, and CNAME records whose target does not resolve
Names under the domain that appear in certificate transparency logs

The organisation must establish

An inventory of records, with an owner and a reason for each
Who can log in to the registrar and the DNS host, and that each has two-step verification
Renewal arrangements, and the decision on transfer and registry locks
A DNS step in the process for retiring a service

The External Security Check runs these checks on a verified domain with the email, TLS and header checks, and keeps the results with the domain's history. Continuous monitoring rechecks verified domains on a schedule and tells you when a result changes, such as a new dangling record.

Sources

Checked on the review date above. Standards and schemes change; the source is the authority.