Dnssec: what to verify before client handoff

I want the handoff packet to answer a mechanism question, not a vibe: do DNS responses for this domain use signed verification, and does that match what the client asked for? SlaySlop's DNSSEC check "Checks whether DNS responses use signed verification." That glossary line is the gate I put next to the DNS records inventory—not instead of it.

Outcome before you hand the keys over

The client inherits a written answer to the signed-verification question. If DNSSEC is in scope, the public chain is consistent (zone signed, parent DS present, validating resolvers agree). If DNSSEC is explicitly out of scope, the portal note says so without pretending a CDN badge covers it. DNS records, WHOIS, and mail configuration stay separate rows.

Green uptime on one URL is not a DNSSEC review. A dig A that returns an address is not a DNSSEC review either.

Boundaries

Permissioned assessment only. Read-only observation. Not a pentest. Not permission to flip registrar DS on a zone you do not operate. DNSSEC sits in Domain and infrastructure beside DNS records, WHOIS, mail configuration, redirects, ports, and server location. Domain insights product copy: check DNSSEC, mail config, WHOIS, TXT records, and subdomains. Collecting records does not sign them. Signing does not rewrite MX.

What I verify on the happy path

1. Intent. Did the SOW or security questionnaire require DNSSEC, or only "DNS set up"?
2. Inventory first. Open DNS records so you know which NS host and apex you are talking about.
3. Signed verification. Open DNSSEC. Read whether responses use signed verification as the check observes it.
4. Parent consistency. If signing is intended, confirm DS at the registrar matches what the DNS host expects. Half-finished enable is how launch week creates SERVFAIL theater.
5. Siblings. WHOIS contact still correct? Mail configuration reviewed if MX exists? Availability status separate?

# Permissioned handoff fragment — owned / authorized domain
DOMAIN=client.example.com
echo "NS:"; dig +short "$DOMAIN" NS
echo "DNSKEY:"; dig +short "$DOMAIN" DNSKEY
echo "DS:"; dig +short "$DOMAIN" DS
dig "$DOMAIN" A +dnssec +multi | sed -n '1,40p'

handoff_dnssec:
  check: dnssec
  definition: Checks whether DNS responses use signed verification.
  intent: required|explicitly-out|undecided
  signed_verification: yes|no|broken
  ns_host: <provider>
  ds_at_registrar: yes|no|n/a
  siblings_reviewed: dns-records|whois|mail
  rescan_after_change: done|scheduled|n/a
  portal_note: <one sentence>

Pitfalls that still show up in week one

Calling DNSSEC done because a DNS-host toggle is green while the parent DS is missing or wrong. Validating resolvers fail closed. The handoff call hears "we enabled security" and then support hears "site won't resolve on some networks."

Skipping the inventory. Signing machinery next to a stale CNAME is still a wrong-host story. DNS records owns the resolve-and-configure collection; DNSSEC owns signed verification.

Treating TLS as proof. Certificate problems stay certificate problems. DNSSEC does not replace TLS configuration or SSL certificate checks.

Leaving intent blank. Unsigned production zones are common. What embarrasses you on a call is claiming "DNS is fully secured" when nobody measured signed verification—or when the client never asked for it and you enabled a half-broken chain.

How I write the portal note

Prefer mechanism language:

DNSSEC: signed verification <present|absent|inconsistent> for <domain>
per SlaySlop DNSSEC check. Intent: <required|out of scope>.
DNS records inventory reviewed separately. Mail: <n/a|see mail configuration>.

Avoid: "DNS hardened and enterprise-ready." That sentence does not tell the next engineer whether DS exists.

Cutover and monitoring

Domain insights notes that future scans reveal when public configuration shifts. After a DNSSEC enable or disable, schedule a rescan past the relevant TTL and parent publish delay. Keep monitoring on so availability flaps show up next to the infrastructure change instead of in a panicked screenshot thread.

If the client keeps an old DNS host as backup for a week, document which NS set is authoritative now. Two partially signed systems are worse than one honest unsigned zone with a dated decision.

Ownership of registrar and DNS host

Somebody must own the registrar login and the DNS host login after you leave. Write both names. Ambiguity recreates half-signed zones when keys rotate and DS is deleted during a casual cleanup. If signing is out of scope, write the revisit date so the next agency does not invent a yes on a security questionnaire.

Related next step

Quote the glossary definition on the call if someone asks what was measured. Soft links: DNSSEC, DNS records, Domain insights. Soft close: run a permissioned SlaySlop pass and paste the DNSSEC evidence into the handoff packet instead of a registrar screenshot with a coffee stain.