A subdomain your team spun up three years ago for a staging environment. A CNAME record that once pointed to a Heroku app you decommissioned. A DNS entry for a third-party SaaS tool you stopped paying for. These artifacts look harmless — until someone else registers the underlying resource and starts responding to traffic meant for you.

That is the core problem behind "for-sale" DNS records, and it is more widespread than most engineering teams realize.

What Are For-Sale DNS Records?

DNS records become "for-sale" — or more precisely, dangling — when they continue to point to an external resource that no longer belongs to you. The classic scenario:

  1. You create app.yourdomain.com with a CNAME pointing to yourapp.someplatform.com.
  2. You shut down that service and delete the app, but forget to remove the DNS record.
  3. The platform frees up the subdomain (yourapp.someplatform.com), making it available for anyone to register.
  4. An attacker or opportunist registers it, now receiving all traffic routed through app.yourdomain.com.

Because the DNS record still resolves — and the TLS certificate may even be issued automatically — browsers and users see a seemingly legitimate response from your domain. This is the crux of subdomain takeover, one of the most underestimated vulnerabilities in production infrastructure.

The "for-sale" framing adds another dimension: some dangling DNS targets are not immediately claimed by attackers but are instead listed on domain marketplaces. Anyone can buy the expired resource, inherit all inbound traffic, and do whatever they like with it — legitimate or otherwise.

Why This Happens So Often

The root cause is organizational, not purely technical. DNS records are infrastructure artifacts that outlive the decisions that created them.

  • Team turnover: The engineer who set up the record left, and nobody owns DNS hygiene.
  • No offboarding checklist: Decommissioning a service rarely includes a formal "remove all DNS entries" step.
  • Distributed provisioning: Developers add DNS records through Terraform, platform CLIs, or vendor dashboards — creating sprawl that no single registry tracks.
  • Long TTLs masking the problem: A high TTL means stale records persist in resolvers long enough to feel "active," discouraging cleanup.

For SaaS companies operating at scale, this compounds quickly. A company with dozens of microservices, multiple environments (dev, staging, preview, production), and several third-party integrations can easily accumulate hundreds of DNS records — many of which were last reviewed years ago.

The Real-World Impact

Subdomain takeover via dangling DNS is not theoretical. Bug bounty programs consistently rank it as a valid, rewarded finding. The consequences range from:

  • Credential harvesting: An attacker serves a convincing login page on your subdomain.
  • Cookie theft: Depending on cookie scope, session tokens set on the parent domain may be readable from the subdomain.
  • Reputation damage: Phishing campaigns that appear to originate from your own domain infrastructure.
  • Compliance exposure: Under GDPR or Ghana's Data Protection Act, a breach facilitated by your DNS negligence is still your breach.

A particularly nasty variant involves services that issue TLS certificates automatically upon resource registration (many cloud platforms do this). The attacker's takeover site gets a valid HTTPS certificate, making it indistinguishable from a legitimate endpoint to end users.

Auditing Your DNS Surface Area

A practical audit does not require expensive tooling. Start here:

# Export all DNS records for your zone (example with dig + a known zone transfer target)
dig axfr yourdomain.com @your-nameserver

# For each CNAME, check if the target resolves to an active, owned resource
dig CNAME app.yourdomain.com
curl -I https://app.yourdomain.com

Beyond manual checks, several open-source tools — subjack, dnsx, and nuclei with subdomain takeover templates — can automate detection across large record sets. Pair these with your cloud provider's asset inventory to cross-reference which resources are still live.

What to Fix Immediately

  • Remove DNS records at decommission time, not during the next quarterly audit. Make it a required step in your service teardown runbook.
  • Audit CNAMEs pointing to third-party platforms (Heroku, GitHub Pages, Netlify, Fastly, etc.). These are the highest-risk category.
  • Scope cookies carefully: Use __Host- prefixed cookies and explicit domain scoping to limit blast radius if a subdomain is compromised.
  • Implement a DNS record ownership policy: Every record should have an owner (a team or a service) tracked in your infrastructure-as-code repository.

Making DNS Hygiene Part of Engineering Culture

The best fix is process, not tooling. DNS cleanup fails when it is treated as a one-time event rather than an ongoing discipline. Consider:

  • Adding a DNS record review step to every infrastructure PR.
  • Running a monthly automated scan that flags CNAMEs resolving to platforms where the target resource no longer exists.
  • Defining a default TTL policy (300–600 seconds for dynamic records) so you can clean up quickly without waiting on resolver caches.

Infrastructure-as-code helps enormously here. When DNS records live in version-controlled Terraform or Pulumi configurations alongside the resources they reference, deleting the resource and the record becomes a single, reviewable change — not two separate operations separated by months.

Source: for-sale DNS records — specification.website via Hacker News

Why this matters for your project: Whether you are running a SaaS product, a fintech platform, or a customer-facing mobile backend, your DNS zone is part of your attack surface. Dangling records are low-hanging fruit for opportunists and a quiet compliance risk for founders. Building a clean DNS offboarding process now — before your team scales — is one of the highest-leverage, lowest-cost security improvements you can make.