Skip to content

Engineering

Dns Records: what to verify before client handoff

Before handoff, verify the public DNS inventory matches the hosts and mail vendors the client is paying for—NS, A/AAAA, MX, and leftovers—then keep DNSSEC and mail as separate rows.

· by Maya Okonkwo

Dns Records: what to verify before client handoff

What an attacker—or a confused customer—sees first is often not your React tree. It is whatever public DNS still advertises. Handoff docs that say "DNS updated" without an inventory are how you inherit last year's Netlify CNAME and a mailbox vendor nobody renews.

SlaySlop's DNS records check "Collects the public records that resolve and configure the domain." That sentence is the handoff gate I want signed off, not a registrar screenshot with a coffee stain.

Outcome before you hand the keys over

The client inherits a public zone that matches the hosting and mail vendors in the contract, with leftovers named or removed, and with DNSSEC / WHOIS / mail configuration tracked as separate tickets when they apply. Green uptime on one URL is not a zone audit.

Boundaries

Permissioned assessment only. Read-only collection. Not a pentest. Not permission to alter a zone you do not operate. DNS records sits in Domain and infrastructure beside DNSSEC, WHOIS, mail configuration, redirects, ports, and server location. Collecting records does not sign them. Signing does not fix MX.

Loading diagram.

What I verify on the happy path

  1. Nameservers. Do NS records point at the DNS host the client will pay for after you leave?
  2. Apex and www. Do A/AAAA and CNAME targets match the live site, not a preview the agency still owns?
  3. Mail. Do MX (and related TXT) match the mailbox or ESP in the contract—even on "brochure" sites that still receive mail at the apex?
  4. Verification clutter. Are old domain-verification TXT records still required? If not, schedule cleanup so the next person does not fear deleting them.
  5. Siblings. Open DNSSEC and mail configuration after the inventory is honest.
bash
# Permissioned handoff script fragment
printf 'NS: '; dig +short "$DOMAIN" NS
printf 'A:  '; dig +short "$DOMAIN" A
printf 'WWW:'; dig +short "www.$DOMAIN" CNAME; dig +short "www.$DOMAIN" A
printf 'MX: '; dig +short "$DOMAIN" MX
text
handoff_dns:
  check: DNS records
  ns_ok: yes|no
  apex_ok: yes|no
  www_ok: yes|no
  mx_ok: yes|no|n/a
  leftovers: staging-cname|old-txt|none
  siblings_reviewed: dnssec|whois|mail
  rescan: done|scheduled

Pitfalls that still show up in week one

Updating the CDN and forgetting the registrar delegation. The CDN UI looks perfect. Public NS still points elsewhere.

Polling only / for uptime while www CNAMEs to a retired project. Availability status and DNS records answer different questions; keep both.

Assuming "no email product" means MX can be ignored. Apex MX still shapes deliverability and spoofing conversations. Mail configuration is the deeper row; DNS records is where MX first appears in the inventory.

Calling DNSSEC done because a registrar toggle is green while the collected records still show a stale host. Different checks. Different evidence.

Skipping WHOIS when the registration contact still lists a contractor who left. WHOIS reviews available public domain registration signals—another handoff landmine beside the record inventory.

How I talk about exposure without drama

I name what the public zone still publishes: addresses, nameservers, mail targets, leftovers. I do not claim the collection is a full OSINT review of every subdomain ever. Subdomains is its own check in the Domain and infrastructure set. Stay in lane.

If DNS block lists come up on the call, I keep that in Security reputation territory. DNS records explains where the name points. Block lists ask whether certain resolvers filter the domain or address. Related, not identical.

Cutover weekend checklist

TTL lies to optimistic schedules. On cutover weekend I re-open DNS records after the longest relevant TTL should have expired, compare apex and www again, and confirm MX if mail moved. Monitoring stays on so availability flaps show up next to the inventory instead of in a panicked screenshot thread.

If the client keeps the old DNS host as a backup for a week, I document which NS set is authoritative now. Two partially updated systems are how half the internet sees the new site and half sees a parking page.

Ownership of the zone after you leave

Somebody has to own the registrar login, the DNS host login, and the mailbox DNS changes. I write those three names into the handoff packet even when all three are "the client IT lead." Ambiguity here recreates the stale CNAME problem six months later when a certificate fails to renew because the challenge TXT never landed.

Soft close on the call

I end the DNS portion by restating the glossary line and naming the sibling tickets. Soft link if they want the product definition in writing: DNS records. Keep scanning the live host through cutover so a "temporary" CNAME does not become the production story.

Related next step

After the inventory matches the contract, leave monitoring on through the cutover window and re-open DNS records the day after TTL should have expired. Soft link: DNS records, WHOIS, and Domain insights.