DNSSEC and CAA: Stop Attackers From Hijacking Your Domain

Most vibe coders configure DNS once and never look back. DNSSEC and CAA records close two of the cleanest ways to hijack a domain · here is how to enable both.

By Daniel A · Kraftwire Software

2026-06-30 · 11 min read

Key takeaway

If you shipped an app on Lovable, Cursor, or Bolt and pointed a domain at it, you probably configured DNS once and never looked back. Two DNS-layer settings · DNSSEC and CAA records · are the difference between a domain only you control and one an attacker can quietly redirect. Neither costs money, both take minutes, and together they close off two of the cleanest ways to hijack a domain. This post explains what they do and how to turn them on.

Why DNS is the soft underbelly of your app

DNS is the system that turns `yourapp.com` into an IP address a browser can reach. It also routes your email (via MX records), proves domain ownership for certificate authorities, and anchors nearly every integration you connect. If someone can forge or tamper with DNS answers for your domain, they don't need to break into your app at all. They just point your visitors somewhere else.

The classic version of this attack is **DNS spoofing**, also called **cache poisoning**. Resolvers (the servers your ISP or network uses to look up domains) cache answers to stay fast. In a cache poisoning attack, an attacker tricks a resolver into storing a forged answer · so `yourapp.com` resolves to the attacker's server for everyone using that resolver, until the cache entry expires. The original DNS protocol had no way to tell a real answer from a forged one. It trusted whatever arrived first and looked plausible.

That is the gap DNSSEC was built to close.

What DNSSEC actually does

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. When your domain is signed, each set of records is signed with a private key, and the matching public key is published in DNS. A chain of trust runs from the root zone down through your top-level domain (`.com`, `.io`, and so on) to your domain, so each level vouches for the next.

Here is the part that matters in practice. When a **validating resolver** looks up your domain, it checks those signatures against the chain of trust. If the signatures are valid, it returns the answer and sets the **AD flag** (Authenticated Data) in the DNS response. If an attacker injects a forged record, the signature won't match, validation fails, and the resolver rejects the answer instead of serving it. A poisoned cache entry gets thrown out rather than handed to your users.

So DNSSEC doesn't stop someone from trying to forge DNS answers. It makes forged answers detectable and rejectable, which removes the payoff.

The limit worth understanding

DNSSEC authenticates DNS data · it proves an answer genuinely came from your domain and wasn't altered. It does not encrypt anything. DNS queries and responses are still visible on the wire, and DNSSEC is not a substitute for HTTPS. Confidentiality is HTTPS's job. Integrity and authenticity of DNS answers is DNSSEC's job. You want both, and they solve different problems. Don't skip TLS because you enabled DNSSEC, or vice versa.

CAA records · deciding who may issue your certificates

DNSSEC protects the answers. CAA records protect a different door · certificate issuance.

Every HTTPS certificate is issued by a certificate authority (CA). The problem is that, by default, more or less any public CA can issue a certificate for your domain if someone passes that CA's validation checks. If an attacker finds a way to trick a CA into validating them · for example, by briefly hijacking DNS or exploiting a weak validation path · they can get a legitimate-looking certificate for your domain and impersonate you convincingly.

A **CAA record** (Certification Authority Authorization, defined in RFC 8659) is a DNS record that lists which CAs are allowed to issue certificates for your domain. Compliant CAs are required to check it before issuing. If your CAA record only names Let's Encrypt and someone asks a different CA for a certificate, that CA is supposed to refuse. You have narrowed issuance from "anyone" to "the CAs I chose."

CAA uses three tags:

`issue` · authorizes a CA to issue regular certificates for the domain. The value is the CA's domain, for example `letsencrypt.org`.

`issuewild` · authorizes issuance of wildcard certificates (like `*.yourapp.com`) specifically. Handy when you want wildcards restricted separately.

`iodef` · gives a contact (a `mailto:` or URL) where a CA can report a request that violates your policy, so you find out when someone tries.

A typical set of records looks like this:

yourapp.com. IN CAA 0 issue "letsencrypt.org"

yourapp.com. IN CAA 0 issuewild "letsencrypt.org"

yourapp.com. IN CAA 0 iodef "mailto:security@yourapp.com"

The leading `0` is the flags field. Set your `issue` value to whichever CA actually issues your certificates · if your host uses Google Trust Services or another CA, name that one instead, or list several. Get this wrong and legitimate renewals can start failing, so check who issues your current certificate before you lock it down. Many managed platforms (including Cloudflare and various Lovable-connected hosts) handle certificates for you · make sure their CA is in the list.

How to enable DNSSEC and CAA, step by step

Before you click anything, understand the two roles · this is the single thing that trips people up.

The **DNS host** is whoever answers lookups for your domain · where your DNS records actually live. That might be Cloudflare, Route 53, Vercel, or your registrar's default DNS. The DNS host is what **signs** your zone and generates a **DS record** (a short fingerprint of your signing key).

The **registrar** is where you bought and manage the domain. The DS record has to be **published at the registrar** to complete the chain of trust up to the TLD. Signing without publishing the DS does nothing · and publishing a DS that doesn't match your host's key will break resolution.

So there are two cases. If the same company is both your registrar and your DNS host (common with Cloudflare Registrar, Namecheap, Porkbun, Squarespace), it's usually a **single toggle** and they wire up the DS for you. If they're **split** (for example, domain bought at Namecheap but DNS on Cloudflare), you enable signing at the DNS host, copy the DS record it shows you, and paste it at the registrar by hand.

CAA records are different · they are just normal DNS records you add at your DNS host, and they don't need anything published at the registrar.

Cloudflare (as your DNS host)

Use this when your domain's nameservers point to Cloudflare, regardless of where you bought it.

Go to **DNS**, then **Settings** (labels may shift slightly, but DNSSEC lives under DNS settings).

Click **Enable DNSSEC**. Cloudflare signs the zone and shows you a dialog with a **DS record** · key tag, algorithm, digest type, and digest.

Copy those values. You can reopen them later by clicking **DS record** on the DNSSEC card.

Go to the **registrar where you bought the domain** and publish that DS record there (see the registrar sections below). If your registrar lists Algorithm 13 as **ECDSA Curve P-256 with SHA-256**, that's the same thing.

If you use **Cloudflare Registrar**, Cloudflare adds the DS for you automatically · no copy-paste needed.

Note · Cloudflare only signs the zone. Nothing is active until the DS is published at the registrar.

Namecheap (registrar and DNS)

Use this when the domain is on Namecheap's own **BasicDNS** or **PremiumDNS** nameservers.

Open the **Advanced DNS** tab and find the **DNSSEC** section.

Toggle DNSSEC on. Namecheap signs and publishes everything automatically · there are no DS values for you to copy on BasicDNS.

Allow up to about an hour for it to take effect.

If your domain uses **custom/external nameservers** (like Cloudflare), Namecheap instead gives you fields to **paste the DS record** from that host · look for the DNSSEC section under the domain's management page and add the key tag, algorithm, digest type, and digest there.

Porkbun (registrar and DNS)

Find your domain and click **Details** on the far right to expand it.

If you use Porkbun's default nameservers, find **Porkbun DNSSEC** and click the toggle · it turns green and creates the DNSSEC record for you.

If the toggle won't turn green, delete any existing DNSSEC records for the domain and try again.

If you use **third-party nameservers** (like Cloudflare), use the **Registry DNSSEC** option in that same Details panel to paste the DS record from your DNS host.

GoDaddy (registrar · plus GoDaddy DNS)

Select **DNS**.

If the domain uses **GoDaddy nameservers**, select **DNSSEC**, choose **Turn On DNSSEC**, enter a notification email, and **Save**. GoDaddy manages the keys · allow up to about 90 minutes.

If the domain uses **external nameservers** (like Cloudflare), look for **DS Records** instead, click **Add**, and enter the **Key Tag**, **Algorithm**, **Digest Type** (1 or 2), and **Digest** from your DNS host, then **Save**.

Squarespace Domains (successor to Google Domains)

For domains registered here on Squarespace's own nameservers, DNSSEC is typically **enabled automatically** for supported TLDs · you usually don't need to do anything, and it can take a few hours after registration to start working.

To add a **custom/third-party DS record**, open your **domains dashboard**, click the domain, click **DNS**, then **DNSSEC**, then **Add record**.

Reauthenticate with your password or 2FA when prompted.

Enter the DS/DNSKEY values from your third-party provider and **Save**.

Note · Squarespace requires **custom nameservers** to add third-party DS records, and adding custom nameservers disables its built-in DNSSEC. You can add up to eight DS or DNSKEY records.

Vercel (domains on Vercel nameservers)

This one is a heads-up, not a toggle. Vercel's nameservers **do not support DNSSEC**, and there is no DS record to enable.

If your domain uses **Vercel nameservers**, you must **disable DNSSEC at your registrar** · otherwise the nameservers may fail to resolve, and you'll see an error telling you to turn DNSSEC off at the registrar.

If the domain is **registered with Vercel**, manage nameservers from the **Domains** section of your team dashboard, but expect DNSSEC to be unavailable while on Vercel's nameservers.

To get DNSSEC on a Vercel-hosted project, put your DNS on a host that signs zones (such as Cloudflare), point your nameservers there, enable signing, and publish the DS at your registrar · then point your app's records at Vercel from that host.

Other registrars and DNS hosts

The flow is the same everywhere, even if labels differ.

Go to your **DNS host** and find a **DNSSEC** or **Sign zone** option (often under the domain's advanced or security settings). Enable signing.

If host and registrar are the same company, that toggle usually finishes the job. If not, the host will show you a **DS record**.

Copy the DS record · **Key Tag**, **Algorithm**, **Digest Type**, and **Digest** · and paste it into the **DNSSEC / DS Records** section at your **registrar**.

If you can't find the exact menu, look for anything labeled DNSSEC, DS records, or Secure DNS under the domain's settings · the wording varies but the destination is the same.

Adding CAA records

A CAA record tells Certificate Authorities which CAs are allowed to issue certificates for your domain. You add these at your **DNS host**, the same place your A and CNAME records live · nothing goes to the registrar.

Create a new DNS record and choose type **CAA**.

Set the **flag** · use `0` in almost all cases (128 marks the record critical).