Skip to main content

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 (target) — the domain is registered to SBS (org-level contact, SBS-controlled email alias — same survivability rationale as the DODigitalOcean account, §2.1). The Build Register carries the domain transfer item ("Transfer SBSDASH.COM") until registrar ownership sits with SBS; interimthe hostingcurrent registration under the temporaryinterim registrar/hostaccount is a tracked transitional state.
  • Registrar lockclientTransferProhibited enabled; transfer-out requires an authenticated unlock action. Domain-transfer attempts are a high-severity alert.
  • Registrar MFA — phishing-resistant MFA on the registrar accountaccount. (IAM-03 applies to every control plane, registrar included;included: registrar compromise is functionally equivalent to full platform compromisecompromise, since it permits NSnameserver redelegation).redelegation.
  • Renewal — auto-renew enabled, multi-year registration, expiry monitored (an expired domain is simultaneously an availability failure and a takeover event)opportunity).
4.2 Authoritative DNS

ZoneAs hostingbuilt decision.(2026-07-18): DigitalOceanthe DNSzone is hosted on GoDaddy nameservers. GoDaddy does not supportprovide DNSSEC signing.signing Becausefor externally manageable zones in this configuration, records are console-managed rather than IaC-managed, and no API-driven change control is in place. This state satisfies neither DNS-01 mandates(DNSSEC) DNSSECnor the IaC management rule (§4.5),Chapter 10) and is a tracked nonconformance (Build Register item 9).

Target: the authoritative zone is hosted at a DNSSEC-capablecapable, providerAPI-managed rather than DigitalOcean DNS.provider. Approved options, in preference order:

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

Zone cutover sequence (Nelson Santos, execution owner): replicate the current record set at the new provider → verify resolution parity against §4.3 → lower TTLs to 300 → update NS delegation at the registrar → confirm propagation → enable DNSSEC and publish DS (§4.5) → raise TTLs. The zone is thereafter 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 cutoverdrift and NS delegation.reverted.

4.3 Record Inventory

PublicAs surface records — all five subdomains resolve to Prod droplet public IPsbuilt (§2.2.1)2026-07-18):

Record Type Value (actual) State
sbsdash.com A TTL138.197.222.154 (Dev-Gitlab-server) ⚠ Nonconformant — apex resolves to an uninventoried dev host, not prod (§2.2.2, Build Register item 16) monitor.sbsdash.com A 162.243.28.132 (monitor-servers) Live and verified — TLS valid, Grafana responding (changelog 2026-07-17) wiki.sbsdash.com A 167.172.135.88 (sbs-wiki, NYC1) Live; IP changes at NYC2 rebuild admin.sbsdash.com, clients.sbsdash.com, www Not yet published Pending prod proxy/TLS readiness (Chapter 5)

Target:

Record Type Value TTL Serves sbsdash.com A 107.170.72.145 300 (build) → 3600 (steady) Primary tenant surface — repointed from 138.197.222.154 at cutover www.sbsdash.com CNAME sbsdash.com 3600 Redirect to apex at proxy admin.sbsdash.com A 107.170.72.145 300 → 3600 Administrative console clients.sbsdash.com A 107.170.72.145 300 → 3600 Client-facing surface monitor.sbsdash.com A 162.243.28.132 3600 Grafana/Prometheus (IdP-gated) wiki.sbsdash.com A 167.172.135.88 → NYC2 rebuild IP 300 until rebuildrebuild, then 3600 BookStack portal

Notes:

  • Tenant surfaces share one A target; host-header routing at the reverse proxy (Chapter 5) separates them. No wildcard record exists — *.sbsdash.com unresolvedis unresolvable by design (FE-FE family: no unintended surface enumeration; a wildcard would also complicatepollute CTthe CT-monitoring signal, §4.6).
  • wiki.sbsdash.comThe TTLapex heldrepoint at(138.197.222.154 300 until107.170.72.145) is executed only after the NYC2prod rebuildproxy landsand itsTLS finalstack IP,pass their Chapter 5 gates — repointing to an unready origin is an availability failure. Until then raised.the current apex target remains inside the engagement security boundary (§2.2.2).
  • Dev has no records in the public zonezone. (§2.4).The as-built apex record violates this rule today; it is cured by the repoint. Dev access is by IP against the admin allowlist.
  • IPv6: AAAA records are added only when droplet IPv6 is enabled and firewall rulesets carry mirrored v6 rules — publishing AAAA without v6 firewall parity is a firewall bypass, so the two land together or not at all. (As built there are no v6 firewall rules anywhere; no AAAA records are published.)
4.4 Mail Posture (DNS-03)

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

Record Type Value
sbsdash.com MX 0 . (null MX, RFC 7505)
sbsdash.com TXT v=spf1 -all
_dmarc.sbsdash.com TXT v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:<SBS security alias>

These records are publishable on GoDaddy today — they do not depend on the zone cutover and should not wait for it. DMARC aggregate reports route to an SBS security mailbox (on an existing SBS mail domain,domain (not sbsdash.com), somaking spoof attempts are observable — this is a MON-02 anomaly input, not merely a static record.

One caution: the Grafana admin account and the changelog reference admin@sbsdash.com and a Yahoo mailbox as service identities. No mailbox exists or will exist on sbsdash.com under the null-mail posture; service accounts must use SBS-controlled aliases on SBS's mail domain. Folded into the credential remediation (Build Register item 15).

4.5 DNSSEC (DNS-01)

As built: unsigned — no signing path exists on the current GoDaddy hosting (§4.2). DNS-01 is unmet until zone cutover completes.

Target, unchanged in substance:

  • 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;path. theEnd-to-end chain of trust must be verified end-to-end:verification: dig +dnssec sbsdash.com returns the AD flag from a validating resolver, and DNSViz shows an unbroken chain. This verification is a named Build Register gate in(item the Build Register.10).
  • Key rollovers are provider-automated (CDS/CDNSKEY where the registrar supports it); manual DS changes are change-controlled.
  • Failure Failure-mode note: DNSSEC misconfiguration causes hard resolution failure, not degraded security — DS/keyset changes areexecute therefore executed withinside the 300-TTL window and are verified before TTLTTLs raise.are raised.
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 — consistent with the deployed ACME/certbot practice already live on monitor.sbsdash.com (matchesLet's ACMEEncrypt design,via Chaptercertbot, 5);auto-renewal anyby systemd timer, per changelog 2026-07-17). Any other CA refusing on CAA is the control working. Wildcard issuance intentionally not authorized (issuewild is intentionally absent (inherits issue; acceptable,acceptable as no wildcard certscertificates are used). Publishable on GoDaddy today; does not wait for cutover.
  • CT monitoring (DNS-04): subscription against Certificate Transparency logs for sbsdash.com (Cloudflare CT alerts or crt.sh RSS into the alert pipeline). AnyBaseline certificatenote: appearingcertificates for monitor.sbsdash.com already appear in CT thatfrom wasthe 2026-07-17 issuance — expected and legitimate. Any CT appearance not issuedoriginating byfrom the platform's ACME automation is a high-severity incident (indicates CAA bypass or issuance compromise).
  • Typosquat monitoring (DNS-05): dnstwist run scheduled (weekly,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

ZoneUntil zone cutover, GoDaddy console changes are restricted to: the three mail records (§4.4), the CAA record (§4.6), and the apex repoint (§4.3) — each logged in SERVER_CHANGELOG.md with date and operator. After cutover, zone changes follow the IaC path (Chapter 10) with the same drift rules as firewallsfirewalls.

(§3.5).

Verification gates: NS delegation correct at registrar;registrar points to the DNSSEC-capable provider; DNSSEC chain validates (AD flag, DNSViz clean); null-MX/SPF/DMARC present; CAA present; apex and all five A/CNAMEsubdomain records resolve toper the IPs in §4.3;3 target table (apex → 107.170.72.145, not 138.197.222.154); no wildcard resolves; no Dev absenthost fromreferenced anywhere in the zone. Controls covered: DNS-01 through DNS-0505.

complete.

Build Register deltas from this chapter: item 9 restated as GoDaddy→provider cutover with sequence; item 16 apex repoint gated on Chapter 5 readiness; new item 23 — publish null-mail + CAA records on GoDaddy immediately (pre-cutover); item 15 extended to cover the admin@sbsdash.com / Yahoo service-identity cleanup. Chapter 5 (TLS & Edge Security) next — the monitor's live nginx/certbot stack gives it a verified as-built baseline to write against.