DNS & account hardening (operator runbook)

Operator-applied hardening for the creddit.xyz domain, its DNS, and the accounts that control both. None of this is code; it is dashboard and registrar work. Do it once, then re-check at each renewal.

Current state (2026-07-20):

• Domain: creddit.xyz, registered at Spaceship, expiry 2027-05-12.
• Nameservers: Cloudflare (full setup; Cloudflare is authoritative for the zone).
• DNSSEC: unsigned (this runbook fixes it).
• CAA records: already set (good). Keep them; monitor certificate issuance.
• TLS: certificates via Cloudflare at the edge.

Two accounts ultimately control the domain: the Spaceship registrar account (owns the registration and the DS record) and the Cloudflare account (authoritative DNS + edge). Both must be hardened, or the weaker one is the attack surface.

---

1. Enable DNSSEC

DNSSEC signs the zone so resolvers can detect forged DNS answers (cache poisoning, hijacked responses). Because Cloudflare is authoritative and Spaceship is the registrar, enabling it is a two-step handoff: turn on signing at Cloudflare, then publish the DS record at Spaceship.

1. Cloudflare: enable signing. Dashboard, select the creddit.xyz zone, then DNS > Settings > DNSSEC > Enable DNSSEC. Cloudflare generates and displays a DS record (key tag, algorithm, digest type, digest) plus the equivalent DNSKEY fields. Leave this page open.
2. Spaceship: publish the DS record. In the Spaceship dashboard open creddit.xyz, go to the domain's DNSSEC / DS records section, and add a DS record with the exact values Cloudflare showed (key tag, algorithm, digest type, digest). Save.
3. Wait for propagation. The registrar pushes the DS record to the .xyz registry; this can take from minutes to a few hours. Cloudflare's DNSSEC panel moves from Pending to Active / DNSSEC is enabled once it sees the DS at the parent.
4. Verify.

   # DS present at the parent (.xyz) and DNSKEY signed
   dig DS creddit.xyz +short
   dig DNSKEY creddit.xyz +dnssec +short
   # full-chain validation (AD flag set, no SERVFAIL)
   dig creddit.xyz +dnssec | grep -E 'flags:.* ad|SERVFAIL'

   A clean run shows the ad (authenticated data) flag and no SERVFAIL. For a visual chain check use DNSViz (https://dnsviz.net/d/creddit.xyz/) or Cloudflare's own DNSSEC status.

Order matters. Never publish a DS record at the registrar before Cloudflare is signing, and never disable Cloudflare signing while a DS record still exists at Spaceship. Either mismatch makes the domain fail validation and go dark for validating resolvers. To turn DNSSEC off later, remove the DS at Spaceship first, wait for it to clear the registry, then disable signing at Cloudflare.

---

2. Confirm domain auto-renew (Spaceship)

An expired domain is a total outage and a hijack window. Do not rely on the 2027 expiry being far off.

1. Spaceship dashboard, open creddit.xyz, confirm Auto-renew: ON.
2. Confirm a valid payment method is on file and not expiring before 2027-05-12; a dead card silently defeats auto-renew.
3. Confirm renewal/expiry email notifications go to a monitored inbox (not a personal address that may lapse).
4. Confirm the registrar lock (transfer lock / clientTransferProhibited) is ON so the domain cannot be transferred away without unlocking.
5. Record the expiry (2027-05-12) in the team calendar with a reminder ~30 days out as a backstop to auto-renew.

---

3. Enforce hardware-key / 2FA on both accounts

The registrar and DNS accounts are the keys to the domain. Enforce phishing-resistant 2FA on both.

Cloudflare:

1. My Profile > Authentication > Two-factor authentication: add a hardware security key (WebAuthn/FIDO2) as the primary factor. Add a TOTP authenticator app as backup. Avoid SMS 2FA (SIM-swap risk).
2. Save the recovery codes in the team password manager, not on the same device as the key.
3. If the account is a Cloudflare organization/team, set a policy requiring 2FA for all members and review that no member has 2FA disabled.
4. Rotate/scope any Cloudflare API tokens: least-privilege (only the zones/permissions they need), no legacy Global API Key in scripts, and delete tokens that are unused.

Spaceship:

1. Account security settings: enable 2FA, hardware key if supported, otherwise TOTP authenticator app. Avoid SMS.
2. Save recovery codes in the team password manager.
3. Ensure the login email itself is on an account with hardware-key 2FA (registrar recovery usually flows through email).

---

4. Restrict who can edit DNS

1. Least privilege on Cloudflare. Only named operators who need it get DNS-edit or Super Administrator roles. Everyone else is read-only (Analytics/Reader). Remove stale members and any leftover contractor accounts.
2. Separate humans from automation. Automation uses scoped API tokens, never a human login and never the Global API Key. One token per job, minimum scope, rotated on a schedule.
3. Audit access quarterly. Review the Cloudflare member list and API token list; review Spaceship account access. Revoke anything unexplained.
4. Change-awareness. Cloudflare logs DNS changes (Audit Log); check it after any DNS edit and periodically for changes nobody made.

---

5. CAA records and certificate monitoring

CAA records are already set (good): they restrict which certificate authorities may issue for creddit.xyz, so a mis-issued cert from an unauthorized CA is refused at issuance time.

1. Confirm CAA is intact (do not remove it, and make sure it lists the CA Cloudflare uses):

   dig CAA creddit.xyz +short

2. Monitor issuance. Watch Certificate Transparency logs for any certificate issued for creddit.xyz or its subdomains, so an unexpected cert is noticed fast. Set up a free CT monitor (for example crt.sh alerting, or a commercial CT-monitoring service) pointed at the domain. Spot-check manually:

   https://crt.sh/?q=creddit.xyz

3. Review on change. Any time the CA or edge setup changes, re-check that CAA still authorizes the CA in use, otherwise renewals will start failing.

---

Re-check cadence

• At every renewal (annually): re-run this whole runbook.
• Quarterly: section 4 access audit + section 5 CT spot-check.
• After any DNS/registrar change: verify DNSSEC still validates (section 1 verify block) and CAA is intact.