The asset you forgot you depend on

Ask a lean team who owns the application and you'll get a name in a second. Ask who owns the domain — the registrar login, the DNS zone, the renewal date — and you'll usually get a pause. DNS is the plumbing everything else runs through, which is exactly why it's invisible until it breaks. And when it breaks, it breaks at the worst possible layer: an attacker who controls your DNS doesn't need to breach your app, because they can quietly repoint your traffic, mint valid TLS certificates for your name, and read or send your email — all while your servers sit untouched and your monitoring stays green.

The domain is the one credential you can't rotate. You can reset every password and revoke every token, but if your registrar account is compromised or your domain lapses, the name your customers type and your software trusts is no longer reliably yours. For a lean team that's the good and bad of it: DNS is a small, finite surface you can actually lock down in an afternoon — and one that goes catastrophically wrong if nobody ever does.

The handful of failures that actually happen

DNS incidents are not exotic. They cluster around a few boring, preventable causes:

  • Registrar account takeover. The account that controls your domain is often protected by a single password and an email nobody guards like a crown jewel. Compromise it and an attacker can change nameservers wholesale — this is just account takeover aimed at the one account that controls all the others, so it earns the strongest MFA and identity hardening you have.
  • The lapsed renewal. Domains expire. A renewal email lands in an inbox nobody reads, auto-renew was tied to an expired card, and the name drops — to be re-registered by a squatter or an attacker within hours. An expired domain is an outage and a hijack at the same time.
  • Dangling DNS and subdomain takeover. You point status.example.com at a cloud bucket or SaaS host, later tear down the resource, and forget the CNAME. The record now points at unclaimed infrastructure an attacker can register and serve content from — under your subdomain, with your reputation. These dangling records are precisely the kind of forgotten exposure that attack surface management exists to catch.
  • Unprotected email authentication. Without SPF, DKIM, and DMARC, anyone can send mail as your domain — and DNS is where those records live, so a weak zone is a weak anti-spoofing posture by definition.

The baseline a lean team can actually finish

You don't need a dedicated DNS team. You need a short, enforced set of controls and one named owner:

  • Lock the registrar account down hard. Phishing-resistant MFA, a unique password in a vault, and an account-recovery email that is itself MFA-protected. This account sits above your application in the trust chain, so it deserves stricter protection than your app, not the same.
  • Turn on registrar and registry lock. Most registrars offer a transfer lock (clientTransferProhibited) for free; some offer a stronger registry lock that requires out-of-band confirmation before any change. Both exist to stop a single compromised login from silently moving your domain.
  • Make renewal a tracked control, not an email. Enable auto-renew, put the expiry date in your asset inventory with an owner, and treat a domain inside its renewal window as a finding with a deadline — the same way you'd treat any other tracked remediation.
  • Audit the zone for dangling records. Periodically reconcile every CNAME and A record against infrastructure you still actually own. A record pointing at a resource you decommissioned is a subdomain-takeover waiting to happen and should be deleted the moment the resource is.
  • Consider DNSSEC where it's supported. Signing your zone defends against DNS spoofing and cache poisoning. It adds operational care (key rollovers), so weigh it against your risk — but for a domain that anchors customer trust, it's increasingly table stakes.
  • Watch the records, not just set them. A CAA record limits which certificate authorities can issue for your name; monitoring nameserver and MX changes turns a silent hijack into an alert. DNS drift belongs in the same log and detection pipeline as everything else.

Treat DNS changes like production changes

The deeper fix is cultural: DNS edits get made casually, by whoever has the login, with no record of who changed what or why. That's how dangling records and surprise outages happen. Route zone changes through the same change-management discipline you'd apply to production — a reason, an owner, and a trail — so that six months later you can still answer why a record exists. A zone full of records nobody can explain is a zone you can't safely clean up.

When something does change unexpectedly, it's a finding with an owner and a clock, ranked by blast radius: a nameserver change is a five-alarm fire, a stray TXT record can wait behind it. This is the same exposure-first triage that governs the rest of your program, pointed at the zone.

It shows up in the audit, too

Frameworks rarely say "DNS" by name, but they all ask the questions DNS answers: how do you protect the systems customer data depends on, how do you control changes to critical infrastructure, how do you prevent impersonation of your organization. A locked registrar, a monitored zone, enforced email authentication, and a clean record of changes are exactly the evidence those questions want, and they drop straight into continuous evidence collection alongside the rest of your posture.

One honest caveat: a platform can inventory your domains and their renewal dates, surface dangling or unexpected DNS records as findings, track who owns the fix, and keep that evidence current for an assessor — it organizes and proves the work. It does not register your domains, configure your registrar locks, sign your zone, or grant or guarantee any certification; the registrar hardening, the DNSSEC rollout, and the record cleanup are operational steps your team owns, and which obligations apply to you is a question for counsel.

Your domain is the one credential you can't rotate, and DNS is the layer where a quiet hijack beats your app entirely — repointed traffic, spoofed mail, certificates minted in your name, all with your monitoring still green. The fix is unglamorous and finishable: lock the registrar with strong MFA, turn on transfer and registry locks, make renewal a tracked control, hunt down dangling records, and watch the zone for changes. Treat DNS edits like production changes, and the plumbing nobody owned becomes a surface you can actually prove is yours.