Chapter 4 — DNS & Domain Architecture

 

---

4.1 Domain and Registrar

sbsdash.com is the sole Platform domain. Registrar-level state is a security control surface in its own right (DNS-01):

• Ownership — the domain is registered to SBS (org-level contact, SBS-controlled email alias — same survivability rationale as the DO account, §2.1). The Build Register carries the domain transfer item ("Transfer SBSDASH.COM") until registrar ownership sits with SBS; interim hosting under the temporary registrar/host is a tracked transitional state.
• Registrar lock — clientTransferProhibited enabled; transfer-out requires an authenticated unlock action. Domain-transfer attempts are a high-severity alert.
• Registrar MFA — phishing-resistant MFA on the registrar account (IAM-03 applies to every control plane, registrar included; registrar compromise is functionally equivalent to full platform compromise since it permits NS redelegation).
• Renewal — auto-renew enabled, multi-year registration, expiry monitored (an expired domain is an availability and takeover event).

4.2 Authoritative DNS

Zone hosting decision. DigitalOcean DNS does not support DNSSEC signing. Because DNS-01 mandates DNSSEC (§4.5), the authoritative zone is hosted at a DNSSEC-capable provider rather than DigitalOcean DNS. Approved options, in preference order:

1. Cloudflare DNS (free tier sufficient) — one-click DNSSEC, DS record handoff to registrar, API for IaC management, native CT/CAA tooling.
2. deSEC — DNSSEC-by-default, API-managed, nonprofit.
3. Registrar-hosted DNS only if the registrar signs zones and exposes an API.

The zone is managed as code (Chapter 10): records are defined in the IaC repository and applied via provider API; console edits are drift. Nelson Santos is execution owner for zone cutover and NS delegation.

4.3 Record Inventory

Public surface records — all five subdomains resolve to Prod droplet public IPs (§2.2.1):

Notes:

• Tenant surfaces share one A target; host-header routing at the reverse proxy (Chapter 5) separates them. No wildcard record exists — *.sbsdash.com unresolved by design (FE-family: no unintended surface enumeration; a wildcard would also complicate CT monitoring signal, §4.6).
• wiki.sbsdash.com TTL held at 300 until the NYC2 rebuild lands its final IP, then raised.
• Dev has no records in the public zone (§2.4). Dev access is by IP against the admin allowlist.
• IPv6: AAAA records added only when droplet IPv6 is enabled and firewall rulesets carry mirrored v6 rules — publishing AAAA without v6 firewall parity is a bypass, so the two land together or not at all.

4.4 Mail Posture (DNS-03)

sbsdash.com sends and receives no mail. Null-mail posture, published explicitly so the domain cannot be spoofed as a sender:

DMARC aggregate reports route to an SBS security mailbox (existing SBS mail domain, not sbsdash.com) so spoof attempts are observable — this is a MON-02 anomaly input, not merely a static record.

4.5 DNSSEC (DNS-01)

• Zone signed at the DNS provider (ECDSA P-256, algorithm 13 — compact signatures, universal resolver support).
• DS record published at the registrar — signing without registrar DS publication provides no validation path; the chain of trust must be verified end-to-end: dig +dnssec sbsdash.com returns AD flag from a validating resolver, and DNSViz shows an unbroken chain. This verification is a named gate in the Build Register.
• Key rollovers are provider-automated (CDS/CDNSKEY where the registrar supports it); manual DS changes are change-controlled.
• Failure mode note: DNSSEC misconfiguration causes hard resolution failure, not degraded security — DS/keyset changes are therefore executed with the 300-TTL window and verified before TTL raise.

4.6 Certificate and Registration Surveillance

• CAA (DNS-02): sbsdash.com CAA 0 issue "letsencrypt.org" plus CAA 0 iodef "mailto:<SBS security alias>". Only Let's Encrypt may issue for the domain (matches ACME design, Chapter 5); any other CA refusing on CAA is the control working. Wildcard issuance intentionally not authorized (issuewild absent → inherits issue; acceptable, as no wildcard certs are used).
• CT monitoring (DNS-04): subscription against Certificate Transparency logs for sbsdash.com (Cloudflare CT alerts or crt.sh RSS into the alert pipeline). Any certificate appearing in CT that was not issued by the platform's ACME automation is a high-severity incident (indicates CAA bypass or issuance compromise).
• Typosquat monitoring (DNS-05): dnstwist run scheduled (weekly, from monitor-servers) against a generated permutation set (sbsdash.com homoglyphs, transpositions, TLD swaps); newly registered lookalikes feed MON-02 alerting. No defensive registrations are made by default; escalation is case-by-case via Alexandra Del Rey (security-compliance routing).

4.7 Change Control and Verification

Zone changes follow the IaC path (Chapter 10) with the same drift rules as firewalls (§3.5). Verification gates: NS delegation correct at registrar; DNSSEC chain validates (AD flag, DNSViz clean); null-MX/SPF/DMARC present; CAA present; all five A/CNAME records resolve to the IPs in §4.3; no wildcard resolves; Dev absent from zone. Controls covered: DNS-01 through DNS-05 complete.