Front Sentinel / guides

How to enable DNSSEC for your dApp domain

DNSSEC signs your DNS records, and a DS record at the registry tells resolvers which key to trust. When someone points your domain at nameservers that don't have your key, validating resolvers return an error and don't hand out the attacker's IP address. For a dApp, that turns a hijack that serves a fake frontend into an outage.

Checked 23 October 2026 against Cloudflare and AWS documentation.

From our October 2026 survey of the 100 largest DeFi protocols by TVL. Domains registered at Cloudflare get the DS record added for them, which is probably why that group is so far ahead.

What DNSSEC did for eth.limo

On 17 April 2026 an attacker posing as an eth.limo team member talked the registrar, EasyDNS, into an account recovery. Early on 18 April they switched the domain's nameservers to Cloudflare, and later to Namecheap. eth.limo's wildcard record serves about 2 million .eth names, so a working redirect would have reached a lot of people.

The attacker changed the nameservers but not the DS record. Resolvers that validate DNSSEC checked the new nameservers' answers against the old key, found they didn't match, and returned SERVFAIL. The team's downtime alerts went off, EasyDNS restored their access a few hours later, and eth.limo says it knows of no user impact (The Block).

What it doesn't cover

• An attacker inside your registrar account can delete the DS record too. In the eth.limo case it stayed in place. Registry lock (see the registry lock guide) makes both changes go through a manual check at the registry.
• An attacker inside your DNS provider account edits records that the provider then signs with your own key. DNSSEC can't tell those edits apart from yours.
• Users whose resolver doesn't validate get the attacker's answer anyway. Many ISP resolvers don't validate; 1.1.1.1, 8.8.8.8 and Quad9 do.
• A compromised server or a hijacked script is outside DNS entirely. For those you need SRI on third-party scripts and checks on what your frontend actually serves.

DNSSEC helps most when an attacker gets partial access to the registrar, which is how several frontend hijacks in recent years started.

Before you start

• Find where the DNS is hosted (dig yourdomain.com ns +short) and where the domain is registered. They are often different companies, and the DS record goes to the registrar.
• If the domain already has a DS record from an old DNS provider (dig yourdomain.com ds +short), don't move nameservers until that is sorted out. An old DS pointing at keys nobody publishes any more takes the domain offline for validating resolvers.
• Have someone watching the site for the next day or two after the DS record goes in. Most problems show up as SERVFAIL from 1.1.1.1 or 8.8.8.8.

Cloudflare DNS

1. In the dashboard open DNS → Settings and click Enable DNSSEC (Cloudflare docs).
2. If the domain is registered at Cloudflare, that's it: Cloudflare adds the DS record itself. Their docs say this can take one to two days.
3. If it's registered elsewhere, the dialog shows the DS values: key tag, algorithm 13 (ECDSA P-256 with SHA-256), digest type 2 (SHA-256) and the digest. Paste them into the DNSSEC section at your registrar.

This is the DS record frontsentinel.com publishes, with Cloudflare DNS:

frontsentinel.com.  DS  2371 13 2 F193CB199FD165F298106D4A9A8C4E114667BA91AA233828C1F8CB8BBE4DEBD5

Moving a signed domain to Cloudflare: remove the DS at the registrar first, wait until dig yourdomain.com ds +short comes back empty and the old TTL has passed (Cloudflare says 24 to 48 hours for most TLDs), then change nameservers, then enable DNSSEC in Cloudflare. If the old provider can publish extra DNSKEY records, multi-signer DNSSEC lets you skip the unsigned gap.

Route 53

1. Lower the longest TTL in the zone to about an hour first, so you can roll back quickly. AWS recommends this in its DNSSEC steps.
2. In the hosted zone open the DNSSEC signing tab, choose Enable DNSSEC signing and create a key-signing key. It needs a customer managed KMS key in us-east-1 (asymmetric, ECC_NIST_P256), and KMS bills it separately.
3. Choose View information to create DS record. If Route 53 is also the registrar, add the key under Registered domains → DNSSEC keys. Otherwise enter the DS values (algorithm 13, digest type 2) at your registrar.
4. AWS suggests watching for resolver problems for up to two weeks before raising TTLs again.

Keep the KMS key. If it is disabled or deleted, Route 53 can't sign the zone, and validating resolvers stop resolving the domain.

Check it

• dig yourdomain.com ds +short shows the DS record at the registry.
• dig yourdomain.com a +dnssec @1.1.1.1 should have the ad flag in the header, meaning the resolver validated the answer.
• DNSViz draws the whole chain from the root and shows where it breaks.
• The free domain scan checks DNSSEC next to registry lock, CAA (see the CAA guide) and frontend scripts.

Know when your DS record or nameservers change

Front Sentinel checks nameservers, the DS record, registry statuses and certificate transparency logs on a schedule, and alerts your team in Telegram, email or webhooks when any of them change. If the DS record disappears, that is an alert of its own. One domain is free.

Scan your domain   Monitor a domain