Enabling DNSSEC has two parts, and both are required: 1. Turn on signing at the provider that hosts your zone. 2. Publish the matching DS record at the parent zone (your domain's registrar) so the chain of trust connects.

Enable DNSSEC for your MCP server domain

What we checked

We performed a DNSSEC-validating lookup for your endpoint’s domain and checked that the chain of trust reaches the DNS root:

DNSSEC is configured correctly; the domain's records validate against the full chain to the root.

DNSSEC check failed: this domain isn't protected by DNSSEC.

DNSSEC check failed: signatures are present but failed validation.

DNSSEC not yet verified: we couldn't validate it against a resolver.

Why it matters

Plain DNS is unauthenticated: a resolver on the path can hand back forged answers and point your hostname at an attacker’s server, defeating the TLS and HTTPS work you’ve already done. DNSSEC cryptographically signs your DNS records so a validating resolver can detect tampering and refuse a forged answer. For an MCP endpoint that agents resolve and connect to automatically, that integrity at the name-resolution layer is a meaningful trust signal.

A broken signing chain is worse than an unsigned zone for clients: a validating resolver will return no answer at all for a domain whose chain fails validation, so it can take your endpoint offline for those users.

How to fix it

Enabling DNSSEC has two parts, and both are required:

Turn on signing at the provider that hosts your zone.
Publish the matching DS record at the parent zone (your domain’s registrar) so the chain of trust connects.

In the Cloudflare dashboard, for the zone:

DNS  ->  Settings  ->  DNSSEC  ->  Enable DNSSEC

Cloudflare then shows a DS record (key tag, algorithm, digest type,
and digest). Copy those values to your DOMAIN REGISTRAR's DNSSEC /
DS-record section. The chain is only complete once the registrar has
published the DS record at the parent (.com, .org, ...) zone.

In the Route 53 console, for the hosted zone:

Hosted zone  ->  DNSSEC signing  ->  Enable DNSSEC signing
(create / choose a KSK backed by an AWS KMS asymmetric key)

Then open "Establish a chain of trust" to view the DS record, and add
that DS record at your registrar. If the domain is registered with
Route 53, you can add it under Registered domains for that domain.

# Confirm the parent publishes a DS record for your domain:
dig +short DS example.com

# Ask a validating resolver to check the chain. The "ad" (Authenticated
# Data) flag in the response header means validation succeeded:
dig +dnssec example.com

# Or get an explicit verdict with delv - look for "fully validated":
delv example.com

How we re-check

We re-run the validating lookup on our next crawl. DS-record changes can take time to propagate through the parent zone and caches, so allow a few hours. Once the chain validates to the root, the check records the validated state we look for on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt

Context: this repository's infrastructure hosts the DNS zone for the
domain behind a remote MCP endpoint. VerifyMCP's DNSSEC check failed
(either the zone isn't signed, or the chain is signed but broken), which
means a validating resolver either does no integrity checking on this
domain's DNS, or actively refuses to return any answer for it at all.

Goal: a DNSSEC-validating lookup for the domain succeeds all the way to
the root, so the next crawl records a fully validated chain.

Do this:
1. If the chain is signed but broken, treat it as more urgent than an
   unsigned zone: a validating resolver returns nothing for the domain
   right now. Compare the DS record published at the registrar against the
   key actually signing the zone at the DNS host; a stale DS record left
   over from a key rollover is the usual cause.
2. If the zone isn't signed at all, enable zone signing at the DNS
   host (for example Cloudflare's DNS > Settings > DNSSEC, or Route 53's
   "DNSSEC signing").
3. Take the resulting DS record (key tag, algorithm, digest type, digest)
   and publish it at the domain's registrar, in its DNSSEC / DS-record
   section.
4. Verify with `dig +short DS <domain>` (confirms the registrar published
   it) and `dig +dnssec <domain>` (look for the `ad` flag), or get an
   explicit verdict with `delv <domain>`.

Rules:
- This is a registrar-level change with a large blast radius: a
  mismatched or missing DS record makes every validating resolver refuse
  to answer for the domain, which can take the endpoint offline. Confirm
  the exact DS record values and the change window with the human before
  publishing anything at the registrar.
- Never mark this fixed from the DNS host's dashboard alone; trust only
  `dig`/`delv` output taken after propagation, since that's what external
  resolvers actually see.
- Don't touch unrelated records in the zone while you're in there.

Report back: the DS record you published (or found mismatched), the DNS
host and registrar involved, and the `dig +dnssec <domain>` output showing
the `ad` flag set.

Reference: https://verifymcp.io/docs/remote/dnssec