Skip to content

Engineering

Fixing Subdomains without guessing

Fix public subdomain leftovers with evidence: match discovered signals to intent, then retire, gate, or document, without guessing from a homepage glance.

· by Henry Smith

Fixing Subdomains without guessing

I still reach for curl first when someone says a mystery subdomain is haunting launch week. Guessing is how you delete the wrong CNAME. SlaySlop's Subdomains check "Discovers public subdomain signals associated with the target." Your fix plan should make the public surface match the runbook and prove it on a rescan.

Outcome the fix is for

Intentional hostnames remain. Leftovers stop answering or stop advertising themselves. Tickets cite evidence instead of folklore. Domain insights stays usable because the inventory no longer contradicts what you told the client.

Boundaries

Read-only observation first. Permission to change DNS or hosting when you act. Not a pentest. Not a silent mass-delete of every hostname that appears in a scanner. Fix only hosts you own or manage. Keep siblings separate: DNS records for zone shape, mail configuration for sender policy, TLS configuration for transport on names that stay live.

Loading diagram.

Happy path

Quote the glossary line in the ticket so nobody expands the job into a full attack-surface fantasy. Attach the discovered names and how they resolve. For each name: keep with owner, put behind auth, redirect, or remove DNS. Wait for TTL when you remove records. Rescan. Domain insights framing is explicit that future scans catch public configuration shifts.

bash
# Permissioned: confirm a name before you edit it
dig +short staging.example.com A
dig +short staging.example.com CNAME
curl -sI -L --max-redirs 2 "https://staging.example.com/" | head -n 15

Pitfalls

Deleting apex records because a subdomain annoyed you. Flipping registrar DNSSEC while cleaning hosts. Declaring mail fixed because you removed an email hostname without opening Mail configuration. Assuming CDN dashboard deletes equal DNS deletes. Skipping the rescan after TTL.

I have watched teams "fix" by rewriting the portal text while the leftover still resolves. That is theater. The public signal is the defect.

What done looks like

The portal note lists decisions. Unexpected public signals are gone or intentionally gated. A fresh Subdomains pass matches the story you will defend on the call. Soft link if they want the product definition in writing: Subdomains. Keep scanning through cutover so a temporary preview host does not become the production story.

Worked example without folklore

Suppose discovery shows preview.client.com and email.client.com. I do not delete both because they "look temporary." I dig each one. Preview might be a leftover Netlify-style CNAME. Email might be required for the ESP. Mail configuration "Checks public mail-routing and sender-policy records." is the sibling for the second name.

text
name: preview.client.com
resolve: CNAME to retired provider
action: remove DNS after confirming no traffic owners
rescan_after: TTL + buffer

name: email.client.com
resolve: CNAME to ESP
action: keep; open mail-configuration sibling

Change control notes

Edits at the registrar and at the DNS host are easy to desync. I write which panel I touched. If DNSSEC is enabled, I do not casually rotate DS while cleaning hostnames. DNSSEC "Checks whether DNS responses use signed verification." stays out of the subdomain cleanup ticket unless evidence says signing broke.

Aftercare

Leave a permissioned rescan on the calendar. Soft link: Subdomains. Soft close: SlaySlop Domain insights next to uptime is how I stop temporary hosts from becoming permanent lore.

Coordination with TLS and mail

Hostnames you keep need a transport story. Hostnames used for sending need a mail story. I open TLS configuration or Mail configuration as siblings instead of declaring those topics solved because DNS no longer lists a leftover. Fixes should shrink confusion, not move it.