← SOP Library

Runbooks

Registrar to Cloudflare — DNS and Domain Registration Migration

Owner Build & Infrastructure Updated 2026-05-28 For Operator (Jerry); CyberSuite Engineer

Registrar to Cloudflare — DNS and Domain Registration Migration

Document name: bluehost-to-cloudflare-migration.md (filename retained for link stability; content now registrar-agnostic) Version: 1.2.0 Last updated: 2026-05-28 Owned by: Build & Infrastructure Pairs with: cybersuite-cloudflare-runbook.md (Cloudflare Pages deployment), cybersuite-resend-runbook.md (Resend email domain), supabase-project-lifecycle.md

Status

Open items as of 2026-05-28

ItemStateOwnerNext action
Resend DKIM✅ Live (resend._domainkey TXT)—None
Proofpoint DKIM✅ Verified at provider (selector chosen by Proofpoint admin)—None
M365 DKIM CNAMEs in DNS✅ selector1._domainkey / selector2._domainkey both CNAME to …pdright.d-v1.dkim.mail.microsoft—None
M365 DKIM signing enabled in Defender⏳ PendingOperatorDefender → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM → cybersuite.tech → click Enable. May require CNAME propagation (typ. a few hours) before Defender lets you toggle
DMARC aggregate reporting (rua=)❌ MissingOperatorDMARC currently v=DMARC1;p=reject; with no rua=. Hard-reject without reporting = silent mail loss if anything misaligns. Add rua=mailto:dmarc-reports@cybersuite.tech (or another monitored mailbox) — see §8
Assessment Edge Functions (submit, save, resume)✅ Deployed to cmevvhyvrkphsfkghpix.supabase.co — all return 204 to OPTIONS—None
Assessment app frontend deployment❌ Not deployed — source only in ~/Code/cybersuite-assessment/Operator + BuildDeploy static assets to Cloudflare Pages; see §9
assessment.cybersuite.tech DNS❌ No recordOperatorAdd CNAME to the Pages project hostname once §9 is done

Important: registrar identification

This runbook was originally drafted assuming Bluehost was the registrar. The actual registrar for cybersuite.tech is Network Solutions (whois cybersuite.tech confirms Registrar: NETWORK SOLUTIONS, LLC., expiration 2030-10-09). Bluehost may have been the historical reseller or hosting account; Network Solutions holds the WHOIS record.

For Phase 1 (already complete) this distinction did not matter — the nameserver swap is dashboard-driven at whichever provider controls the NS pointer for the zone, and the work was done successfully. For Phase 2 (registrar transfer, not yet started), all steps that reference “Bluehost” must be performed at Network Solutions instead:

The Phase 2 procedure below uses the generic term “current registrar” to avoid further confusion.

Purpose

cybersuite.tech is registered at Network Solutions and (previously) used the registrar’s default nameservers. This runbook migrates both items to Cloudflare:

Phase 1 unlocks the technical capabilities CyberSuite needs (Workers routes, Pages, WAF). Phase 2 reduces ongoing cost and consolidates account management. They are intentionally separate; do Phase 1 first and let it settle before touching Phase 2.

1. Why migrate

Technical capabilities Phase 1 enables:

Cost benefits Phase 2 enables:

2. The two phases — and why order matters

DNS hosting and domain registration are independent. The registrar holds the WHOIS record and controls who can change the nameservers. The DNS host serves the actual records when someone queries the domain. You can have one provider for each.

Phase 1 only changes which nameservers the registrar points to. Bluehost remains the registrar; their records remain in their DNS panel (untouched). If Phase 1 breaks anything, reverting is one click in Bluehost’s nameserver panel.

Phase 2 changes the registrar. Once the registration transfers to Cloudflare, Bluehost no longer owns the domain. Reverting at this point requires a transfer-back, which is a 5-7 day process.

Always do Phase 1 first. Verify it works for 48+ hours. Then do Phase 2.

3. Pre-migration checklist

Before changing anything:

3.1 Export the current DNS state from Bluehost

  1. Log in to Bluehost → Domains → cybersuite.tech → DNS (or “Zone Editor”, depending on the Bluehost UI version).
  2. Take a screenshot of every record, OR copy the full record list into a text file. For each record, capture: Type, Host/Name, Value, TTL, Priority (MX only).
  3. Save the export somewhere outside Bluehost (e.g., ~/Documents/cybersuite-dns-backup-2026-05-27.txt).

The records you must capture include but are not limited to:

TypeLikely purpose
AApex cybersuite.tech → Bluehost web hosting IP (if marketing site is on Bluehost)
CNAMEwww → apex; assessment → Cloudflare Pages (if already pointed); mail, webmail
MXEmail routing — Bluehost mail, Google Workspace, M365, or other
TXTSPF (v=spf1 ...); DMARC (_dmarc); Resend domain verification; Google Search Console verification; site verification for other services
TXT (CNAME equivalent for some setups)DKIM keys for Resend/SendGrid/Google — these often live at s1._domainkey, s2._domainkey, or resend._domainkey

Email auth records are the highest-risk items. If MX, SPF, DKIM, or DMARC are not perfectly imported into Cloudflare, outgoing email from info@cybersuite.tech will silently start failing SPF/DKIM and may be marked as spam by recipients.

3.2 Audit live services on the domain

Confirm what is currently using the domain. Open each in a browser and verify it loads:

For email:

Document every working endpoint in the DNS backup file from 3.1.

3.3 Confirm Cloudflare account exists

A Cloudflare account at the operator’s primary email address. If one does not exist, sign up at https://dash.cloudflare.com/sign-up before proceeding. Enable 2FA on the Cloudflare account immediately — this is the new root-of-trust for the domain.

4. Phase 1 — DNS migration steps

Step 1: Add the site to Cloudflare

  1. Open https://dash.cloudflare.com → Add a site (or Add Site button on the dashboard home).
  2. Enter cybersuite.tech. Click Continue.
  3. Select the Free plan. Continue.

Step 2: Verify the auto-imported DNS records

Cloudflare queries Bluehost’s nameservers and imports every record it can resolve into the new Cloudflare zone. This takes 30-60 seconds and presents a record list.

Carefully cross-check the imported list against the export from step 3.1. Specifically verify:

If any record is missing, add it manually: DNS tab → Add record. Match Type, Name, Content (Value), TTL, and Priority exactly.

For each imported record, leave the Proxy status toggle as DNS only (gray cloud) initially. Proxied (orange cloud) routes through Cloudflare’s edge and adds capabilities, but it can break things on first migration. Switch records to proxied after Phase 1 is stable.

Step 3: Note the Cloudflare-assigned nameservers

After step 2, Cloudflare displays two nameservers for this zone. They look like:

xxx.ns.cloudflare.com
yyy.ns.cloudflare.com

The names vary per zone. Copy both values exactly. Do NOT close this tab.

Step 4: Change the nameservers at Bluehost

  1. Log in to Bluehost → Domains → cybersuite.tech → Name Servers (or “Nameservers”).
  2. Choose Custom Nameservers (the option name varies; you want the field where you can enter your own NS values).
  3. Replace the current Bluehost nameservers with the two Cloudflare nameservers from step 3. Save.
  4. Bluehost confirms the change. The change is submitted to the registry; propagation begins immediately but takes 5-60 minutes typically, up to 48 hours in edge cases.

Step 5: Wait for Cloudflare to confirm activation

In the Cloudflare dashboard for cybersuite.tech, the status will read Pending Nameserver Update. Refresh periodically. When Cloudflare detects that the registry now points to its nameservers, the status changes to Active with a green checkmark.

You can manually trigger the recheck: dashboard → Overview → Check nameservers.

Step 6: Immediate post-activation verification

Once Cloudflare reads Active:

  1. Send a test email to info@cybersuite.tech from an external account. Confirm receipt within 5 minutes. If receipt fails: MX records did not import correctly — go back to step 2 and reconcile.
  2. Send a test email from info@cybersuite.tech to an external Gmail address. Open the message in Gmail → “Show original”. Confirm SPF: PASS, DKIM: PASS, DMARC: PASS. If any of these fail: the relevant TXT/DKIM records did not import correctly.
  3. Visit https://cybersuite.tech/ (and www.) — confirm the marketing site loads.
  4. Visit any other subdomain (assessment.cybersuite.tech, etc.) — confirm each loads.
  5. Check Cloudflare’s SSL/TLS tab → set encryption mode to Full (strict) if the backing servers serve valid SSL certs; otherwise Full is acceptable initially.

Step 7: Let Phase 1 settle for at least 48 hours

During the 48-hour window:

If anything breaks during the 48 hours, see section 7 (rollback).

5. Phase 2 — Domain registration transfer

Only initiate Phase 2 after Phase 1 has been stable for 48+ hours AND the email-DKIM open item above is resolved.

The current registrar is Network Solutions (whois cybersuite.tech). UI labels below use generic terms because Network Solutions UI naming shifts; treat them as “find the equivalent.”

Step 1: Unlock the domain at the current registrar

  1. Log in to Network Solutions → My Domains → cybersuite.tech → Manage → Domain Protection (sometimes shown as “Domain Lock” or “Theft Protection”).
  2. Set the protection to Off / Unlocked / Disabled.
  3. Save.

Step 2: Request the authorization code (EPP / Auth Code)

  1. Same domain management area, find Authorization Code (sometimes “Transfer EPP Code” or “Auth Info”). Click Get / Send / Reveal.
  2. Network Solutions typically emails the EPP code to the registered admin email; some flows display it inline.
  3. Save the EPP code. It is a one-time-use string, typically alphanumeric with some symbols. Valid ~14 days.

Step 3: Initiate the transfer at Cloudflare

  1. Cloudflare dashboard → cybersuite.tech → Registrar tab (left sidebar). If the tab reads “Transfer Domain”, that’s the entry point.
  2. Click Transfer to Cloudflare.
  3. Cloudflare confirms the domain is eligible (it is, if Phase 1 nameservers are active and the domain is older than 60 days — confirmed: domain expires 2030-10-09, well past the 60-day floor).
  4. Enter the EPP code from step 2. Confirm.
  5. Cloudflare charges the renewal fee for one year at the wholesale .tech rate (currently ~$5-12/yr; exact varies by TLD pricing year-over-year). This adds one year of registration to whatever time remains on the current Network Solutions registration. Pay via the saved Cloudflare payment method.

Step 4: Approve the transfer at the current registrar

  1. ICANN requires a confirmation step from the losing registrar. Network Solutions emails a transfer-approval link (from @networksolutions.com or @web.com).
  2. Open the email. Click Approve (or “Accept Transfer”).
  3. Some Network Solutions flows additionally surface the approval inside the dashboard under My Domains → Transfers Out (or similar). Approve there if no email arrives.

If you do not approve, the transfer auto-completes after 5-7 days per ICANN rules. Approving immediately speeds it up to 1-2 days.

Step 5: Wait for transfer completion

The Cloudflare dashboard shows the transfer status. When complete, the domain shows as Registered with Cloudflare and renewal goes forward via Cloudflare.

Step 6: Verify

  1. WHOIS lookup: whois cybersuite.tech (terminal). The Registrar line should read Cloudflare, Inc. (or similar Cloudflare-issued name).
  2. Cloudflare dashboard → Registrar tab now shows the domain with its renewal date and at-cost pricing for future renewals.
  3. All sites and email continue to work because the nameservers and DNS records have not changed — only the registrar of record has.

6. Risks and mitigations

RiskLikelihoodMitigation
Email routing breaks (MX/SPF/DKIM not imported correctly)ModerateVerify every email-auth record in step 4.2 BEFORE changing nameservers; send test email immediately after activation in step 4.6
A subdomain stops resolving (CNAME missed)Low to moderateAudit subdomains in step 3.2; verify each loads in step 4.6
Cloudflare’s auto-import misses non-standard recordsLowManual cross-check against the export from step 3.1 catches this
SSL certificate warnings on subdomainsLowCloudflare auto-provisions SSL within ~15 min of activation. If a subdomain warns, check the SSL/TLS tab and confirm “Full” or “Full (strict)” mode
Transfer rejected by current registrar (EPP code expired or domain still locked)LowEPP codes are valid for ~14 days; if expired, request a new one. Verify the domain is unlocked at step 5.1
Customer-facing downtime during nameserver propagationVery lowDNS propagation is gradual; old Bluehost nameservers continue to answer queries during propagation, and Cloudflare records match Bluehost records. End users see no change

7. Rollback procedure (Phase 1)

Phase 1 is complete as of 2026-05-27. This section is retained as the rollback path during the 48h+ stability window before Phase 2.

If something breaks and a rollback is required:

  1. Log in to Network Solutions → My Domains → cybersuite.tech → Name Servers.
  2. Change nameservers back to the Network Solutions defaults (the previous values captured in the pre-migration backup file). Network Solutions may also offer a “Reset to Default” / “Use Network Solutions DNS” option.
  3. Save.
  4. Propagation back takes 5-60 minutes typically.
  5. Network Solutions’ DNS records were untouched during Phase 1, so service resumes as before once propagation completes.

The Cloudflare zone for cybersuite.tech remains in place but is no longer authoritative. You can delete it from Cloudflare or leave it dormant. Leaving it dormant costs nothing and lets you retry Phase 1 later.

Phase 2 has no equivalent fast rollback. If the domain has already transferred to Cloudflare and you want to revert, initiate a transfer-out from Cloudflare back to a registrar of choice (5-7 day ICANN process). Therefore: do not start Phase 2 until Phase 1 is verified stable for 48+ hours.

8. Post-migration verification checklist

After both phases complete:

8. DMARC aggregate reporting (post-Phase-1 hardening)

DMARC is currently v=DMARC1;p=reject; with no rua= aggregate-report destination. Hard reject without reporting is silent: if a legitimate mail flow misaligns (new SaaS sending on your behalf, a missed DKIM rotation, an SPF include going stale), receivers will quietly drop the mail and nobody is paged.

Add aggregate reporting:

  1. Decide on a destination mailbox. Cheapest: dmarc-reports@cybersuite.tech (a distribution list or shared mailbox you’ll actually read). Easiest: route to a free DMARC analyzer like Postmark DMARC Digest, DMARC Report, or dmarcian — they ingest the daily XML reports and email a human-readable summary.
  2. In Cloudflare → DNS → Records, edit _dmarc.cybersuite.tech TXT to: 
    v=DMARC1; p=reject; rua=mailto:dmarc-reports@cybersuite.tech; ruf=mailto:dmarc-reports@cybersuite.tech; fo=1;
    • rua= aggregate reports (daily XML, the useful one)
    • ruf= per-failure reports (optional; can be noisy; some receivers don’t send them)
    • fo=1 request a failure report when any underlying check (SPF or DKIM) fails, not only when DMARC fails — better signal for diagnosis
  3. Verify with dig +short TXT _dmarc.cybersuite.tech.
  4. Within 24 hours, the first aggregate XMLs arrive from major receivers (Google, Microsoft, Yahoo).

Consider a soft-fail ramp first. If you have any uncertainty about an outbound flow (e.g., the just-enabled M365 DKIM, a marketing automation tool, a SaaS that sends on your behalf), temporarily drop the policy to p=quarantine with pct=25 for 1-2 weeks and read the rua reports before going back to p=reject. The current p=reject is correct end-state but unforgiving during config changes.

9. Assessment app deployment to Cloudflare Pages

The static frontend at ~/Code/cybersuite-assessment/ (HTML/CSS/JS + 3 PNGs + schema.json) is wired to the production Supabase functions (cmevvhyvrkphsfkghpix.supabase.co) and has diagnosticMode: false. Edge functions are deployed; only the frontend host + DNS remain.

9.1 One-time Pages project setup

There are two equivalent ways to create the Pages project. Either works; pick the one your tooling allows.

Option A — Cloudflare dashboard (no special token scope required):

  1. Cloudflare dashboard → Workers & Pages → Create → Pages → Upload assets.
  2. Project name: cybersuite-assessment (this becomes the *.pages.dev URL).
  3. Drag the ~/Code/cybersuite-assessment/ folder (excluding supabase/, node_modules/ if present, and .DS_Store) into the upload box.
  4. Click Deploy. The first deploy gives you a URL like https://cybersuite-assessment.pages.dev.

Option B — Wrangler CLI: requires the Cloudflare API token to have Account.Cloudflare Pages:Edit scope (the “Edit Cloudflare Workers” template does not include this; either edit the token to add it or create a new token).

cd ~/Code/cybersuite-assessment
op run --env-file=./.env.op -- npx wrangler pages project create cybersuite-assessment --production-branch=main
op run --env-file=./.env.op -- npx wrangler pages deploy . --project-name=cybersuite-assessment

9.2 Custom domain

  1. In the Pages project → Custom domains → Set up a custom domain → assessment.cybersuite.tech.
  2. Cloudflare auto-creates the CNAME in the same zone. Verify with dig +short CNAME assessment.cybersuite.tech — should resolve to cybersuite-assessment.pages.dev (or similar) and Cloudflare proxy (orange cloud) on.
  3. SSL provisions automatically within ~15 minutes. Test https://assessment.cybersuite.tech returns the assessment landing page with no cert warning.

9.3 Smoke test the full pipeline

  1. Open https://assessment.cybersuite.tech in an incognito window. Confirm there is no yellow diagnostic-mode banner.
  2. Fill in a test submission with Firm name = TEST_<your-initials>_<date>. Submit.
  3. Verify in Supabase dashboard → assessments table → row appears with the test firm name.
  4. Verify in operator inbox (info@cybersuite.tech) → email from the assessment app arrives with the resume link.
  5. Delete the test row from Supabase to keep production data clean.

9.4 Operational notes

10. Open decisions

These are not blocking but should be made by Operations or surfaced for operator review:

Change log

VersionDateChange
1.0.02026-05-27Initial runbook for Bluehost → Cloudflare DNS + registration migration
1.1.02026-05-27Corrected registrar (Network Solutions, not Bluehost) per whois lookup; recorded Phase 1 completion; documented open M365/Proofpoint DKIM and assessment subdomain items; rewrote Phase 2 and rollback steps to be registrar-accurate
1.2.02026-05-28Restructured open items into a state table reflecting verified actual state; recorded M365 DKIM CNAMEs in DNS (signing-enable still pending in Defender); recorded Proofpoint DKIM verified; recorded assessment Edge Functions deployed; added §8 (DMARC rua= reporting plan) and §9 (Cloudflare Pages deploy for assessment frontend); removed stale §9 “Open decisions” entry about DMARC p= ramping (already at p=reject)

How to update

Edit this file in place. Increment the version in the header per semantic versioning rules:

Update the change log table with one line summarizing the change.