DNS & Domains

Summary

Cloudflare is Asymmetric's standard DNS platform across the client portfolio, and losing DNS control there is not a cosmetic inconvenience — it severs access to automated SEO tooling, backend infrastructure, and security capabilities that the agency depends on operationally. DNS migrations carry three categories of risk that clients routinely underestimate: access revocation (managed-host credentials, ad accounts), record preservation (email infrastructure survives nameserver changes only if explicitly audited and migrated), and reputation damage (primary domains used for bulk email or left unprotected against lookalike registration). The two-phase migration pattern — nameserver transfer first, DNS cutover at launch — eliminates most downtime risk and is the established standard. Email deliverability failures are the most common post-migration incident and are entirely preventable with a pre-migration DNS audit.

Current Understanding

Cloudflare is not merely a preferred vendor — it is an operational dependency. Asymmetric's backend infrastructure, including automated SEO audits, PHP/phpMyAdmin access, custom plugin development, and MCP server integrations, runs through Cloudflare DNS control ^[1]. When Adovacare's DNS was moved away from Cloudflare without coordination, the automated monthly SEO audits that had previously corrected 18,000 data rows and raised meta description coverage from 39/54 to 53/54 pages stopped functioning entirely ^[2]. That single incident defines the stakes.

The Two-Phase Migration Pattern

DNS migrations are decoupled into two non-simultaneous phases. Phase one moves nameservers to Cloudflare before any site work begins — this is non-disruptive because existing DNS records continue pointing to the same infrastructure ^[3]. Phase two is the DNS cutover at launch, updating A records to point to the new hosting environment. Cloudflare propagation for this cutover takes approximately 10 minutes, confirmed across Seamless, Cordwainer, and FinWellU engagements ^[4].

The critical failure mode in phase two: updating nameservers does not automatically update A records. These must be explicitly verified and changed to point to new infrastructure ^[5]. Treating nameserver migration and A record updates as a single atomic operation is the most common technical error in this workflow.

Email Infrastructure Preservation

DNS record audits before any migration must identify and preserve email infrastructure records — MX, DKIM selectors, SPF, and third-party verification records — or email service breaks silently at cutover ^[5]. Cordwainer's DNS audit surfaced MX routing through a Barracuda firewall, multiple DKIM selectors, and a GoDaddy Pay Links CNAME — none of which would have been obvious without an explicit pre-migration audit ^[6]. MX records also reveal the underlying email provider, which is essential for troubleshooting and replicating setups across clients ^[7].

SPF, DKIM, and DMARC records are required for email platform functionality and sender reputation, observed across PaperTube, Corustone, and VCEDC ^[8]. DMARC is the most frequently missing record — VCEDC's domain lacked it at migration time, leaving a deliverability gap ^[9].

Access Revocation Risk

DNS migrations that move hosting control can revoke third-party access to website management platforms and ad accounts in ways that are not obvious until something breaks ^[10]. The Adava Care case illustrates a specific and non-obvious distinction: managed-host access (WP Engine console credentials) is entirely separate from WordPress user account access. Moving off WP Engine invalidated the console-provisioned access even though WordPress credentials remained technically valid — they simply had never been shared ^[11]. The implication is that access credential inventories must be taken before any hosting migration, not after.

Sending Domain Architecture

Separate marketing or sending domains protect the primary business domain's sender reputation during high-volume email campaigns. This pattern is established across PaperTube (papertube.pro for Account Engagement sends) and Corustone (go.corustone.com as the consolidated sending domain) ^[12]. Corustone's setup went further: the www sending domain was explicitly deleted from Salesforce Account Engagement to force all sends through go.corustone.com, eliminating split-reputation risk ^[13]. New sending domains require a warm-up period with gradually increasing send volume before operating at full scale ^[14].

Email forwarding between different domains is a distinct problem that DNS alone cannot solve. Forwarding from papertube.pro to papertube.co requires a third-party forwarding service or dedicated mailbox — DNS alias records are insufficient ^[15]. WI Masons learned this the hard way: email forwarding from Google to Office 365 produced a 100% quarantine rate from Office 365 spam filters, because forwarded mail fails SPF alignment checks ^[16].

The access and email infrastructure risks described above are the two most common post-migration failure modes. Domain security — the third category — is less frequent but higher severity when it occurs.

What Works

Two-phase nameserver migration (pre-launch nameserver transfer, launch-day DNS cutover). Separating nameserver migration from site launch eliminates the window where both DNS and site infrastructure are in flux simultaneously. The nameserver transfer is non-disruptive because existing records continue pointing to live infrastructure; the cutover at launch is fast (~10 minutes on Cloudflare) and scoped to a single record change ^[17].

Pre-migration DNS record audit with explicit email infrastructure mapping. Auditing all DNS records before migration and tagging each by function (web, email, verification, payment) prevents silent email failures at cutover. Cordwainer's audit identified Barracuda MX routing, DKIM selectors, and a GoDaddy Pay Links CNAME that would have been lost without explicit review ^[6].

Cloudflare free tier for security and operational control. Cloudflare's free tier provides WAF, Bot Fight Mode, DDoS protection, and traffic monitoring — capabilities that Webflow hosting cannot replicate at the hosting layer ^[18]. For AviaryAI on Webflow, Cloudflare was the only path to custom security headers and WAF rules.

Separate sending domain for bulk email. Isolating high-volume sends to a subdomain (go.corustone.com) or secondary domain (papertube.pro) means deliverability problems with campaigns don't contaminate the primary domain's sender reputation. PaperTube's .pro domain was acquired through Porkbun at a promotional rate of ~$3 ^[12].

Proactive lookalike domain registration. Registering common typo and variant domains before bad actors do eliminates the attack surface for impersonation. PaperTube experienced a phishing domain (papertube.us.com) registered and weaponized on January 22, 2026, within a single day — no detection window existed after registration ^[19].

Porkbun as registrar for new domain acquisitions. Porkbun offers low cost, bulk domain search, and a clean interface for managing multiple domains. Recommended for protective domain registration and secondary sending domains ^[20].

Access credential inventory before hosting migrations. Documenting managed-host credentials, WordPress admin accounts, and ad account access before any migration prevents the Adava Care scenario where access was assumed but not verified ^[11].

PayPal checkout as GoDaddy payment fallback. When GoDaddy direct card entry fails despite valid cards and sufficient funds, PayPal checkout succeeds. This is a known GoDaddy payment processing quirk, not a card issue ^[21].

What Doesn't Work

Assuming nameserver migration updates A records. Nameserver changes transfer DNS control; they do not update the records themselves. A records pointing to old infrastructure must be explicitly changed at launch. Conflating these two operations is the most common technical error in DNS migrations ^[5].

Email forwarding between domains via DNS alone. DNS alias records cannot forward email between different domains. A mailbox or third-party forwarding service is required. WI Masons' Google-to-Office 365 forwarding setup produced 100% quarantine rates because forwarded mail fails SPF alignment — Office 365 treats it as spoofed ^[22].

Relying on managed-host credentials after platform migration. WP Engine console access and WordPress user credentials are independent systems. Moving off WP Engine invalidates console-provisioned access regardless of whether WordPress credentials exist ^[11].

Uncoordinated client-side DNS migrations. Clients who move DNS without agency coordination — as happened with Adovacare — break backend infrastructure access, automated tooling, and potentially ad account connections. The client's mental model ("I just changed where the domain points") does not match the operational reality ^[10].

Sending bulk email from the primary business domain. Using the primary domain for high-volume campaigns exposes the domain's sender reputation to deliverability problems. Once a primary domain is flagged or throttled, all transactional email from that domain is affected ^[23].

Launching a new sending domain at full volume immediately. New domains have no sender reputation. Sending at full scale from day one triggers spam filters. A warm-up period with gradually increasing volume is required ^[14].

GoDaddy 2FA tied to a single phone number or device. When the phone number on file is inaccessible (as with JBF Concrete, where codes weren't delivered to the number ending in 0728), GoDaddy account access becomes a hard blocker for any DNS work ^[24].

Patterns Across Clients

Cloudflare adoption is near-universal and operationally motivated. Cloudflare migration has been executed or recommended for AviaryAI, Seamless, Cordwainer, VCEDC, Corustone, and PaperTube ^[25]. The driver is not preference — it is that Asymmetric's backend tooling depends on Cloudflare DNS control. Clients on other DNS providers are operationally limited in what the agency can automate and monitor on their behalf.

GoDaddy is the most common source of access friction. AviaryAI and JBF Concrete both hit GoDaddy 2FA blockers during DNS work ^[24]. GoDaddy's 2FA is tied to individual phone numbers and devices, and when the account owner is unavailable or the number has changed, DNS work stalls entirely. This is a predictable bottleneck that should be resolved before any migration is scheduled.

Clients underestimate the blast radius of DNS changes. Adava Care and Adovacare both experienced unexpected access revocations after DNS migrations they believed were routine ^[10]. The pattern is consistent: the client's mental model treats DNS as a simple redirect, while the operational reality involves cascading effects on managed-host access, ad accounts, and backend tooling. Pre-migration briefings that explicitly enumerate what will break are more effective than assuming clients understand the dependencies.

Email infrastructure is the most fragile component of any DNS migration. Cordwainer's pre-migration audit found Barracuda MX routing, multiple DKIM selectors, and payment-related CNAMEs that would have been silently dropped ^[6]. VCEDC's domain lacked DMARC at migration time ^[9]. WI Masons' forwarding setup produced 100% quarantine rates ^[16]. Email failures are the most common post-migration incident, and they are consistently caused by insufficient pre-migration auditing rather than migration execution errors.

Sending domain isolation is adopted reactively, not proactively. PaperTube and Corustone both implemented separate sending domains, but the pattern emerged from specific deliverability concerns rather than a standard onboarding step ^[12]. Clients doing high-volume email should have sending domain isolation established before the first campaign, not after a deliverability problem surfaces.

Domain security is treated as optional until an incident occurs. PaperTube's phishing incident (papertube.us.com, January 22, 2026) prompted protective domain registration recommendations that should have been standard practice ^[19]. No other client in the portfolio has documented proactive lookalike domain registration.

Exceptions and Edge Cases

VCEDC DNS moved away from Cloudflare at launch. The standard pattern is migration to Cloudflare; VCEDC's launch plan moved DNS from Cloudflare to ForkBund (the registrar), with an expected ~1 hour of site inaccessibility during propagation ^[9]. The reason for this exception is not documented in the available fragments. If VCEDC's backend tooling requirements differ from other clients, this may be intentional; if not, it represents a gap in the standard workflow.

JBF Concrete uses registrar-level redirects instead of DNS changes. A Google Workspace lockout made the primary domain inaccessible for DNS management, so a domain redirect strategy at the GoDaddy registrar level was used instead of standard DNS-level changes ^[26]. This is a workaround for an access failure, not a recommended approach — it bypasses the operational control that Cloudflare DNS provides.

WordPress credentials survive managed-host migration, but may never have been shared. At Adava Care, WordPress user credentials remained technically valid after moving off WP Engine, but had not been shared with the agency prior to migration ^[11]. The exception to the "access is revoked" pattern is narrow: direct WordPress credentials survive, but console-provisioned credentials do not, and the distinction only matters if direct credentials were documented in advance.

Cross-domain email forwarding requires infrastructure beyond DNS. The general assumption that DNS configuration handles email routing breaks down when forwarding between different domains (papertube.pro → papertube.co). A third-party forwarding service or dedicated mailbox is required ^[15]. This is a common misconception that surfaces specifically in multi-domain setups.

Evolution and Change

The Cloudflare standardization pattern appears to have solidified over the observation period (January–April 2026). Earlier fragments reference GoDaddy as the default registrar and DNS host for many clients; later fragments show active migration away from GoDaddy toward Cloudflare as the DNS layer, with GoDaddy retained only as a registrar in some cases. The operational motivation — Asymmetric's backend tooling dependency on Cloudflare — appears to be the driver of this shift rather than any change in Cloudflare's product capabilities.

The phishing incident at PaperTube (January 22, 2026) introduced domain security as an active concern in the portfolio. Prior to that incident, protective domain registration and lookalike monitoring are not mentioned in any fragment. Whether this represents a new threat pattern or simply a newly documented one is unclear from the available evidence.

Email deliverability infrastructure (SPF, DKIM, DMARC) has been a consistent concern throughout the observation period, appearing across PaperTube, Corustone, VCEDC, WI Masons, and Cordwainer engagements. There is no evidence of a platform-level change driving this — it reflects the ongoing complexity of email authentication requirements rather than a new development.

No signals in the current fragment set suggest imminent changes to the Cloudflare-centric DNS architecture. The platform is stable, the tooling dependencies are established, and the migration pattern is documented. The most likely evolution is incremental: more clients migrated to Cloudflare, and the pre-migration audit checklist becoming more formalized as the email infrastructure failure pattern repeats.

Gaps in Our Understanding

No documented standard pre-migration checklist. Multiple clients have experienced email infrastructure failures post-migration, but there is no fragment documenting a standardized DNS audit checklist used before migrations. If such a checklist exists, it is not captured here; if it doesn't, the same failures will recur.

VCEDC's Cloudflare departure is unexplained. The fragment documents the migration away from Cloudflare to ForkBund but does not explain why. If there is a legitimate reason (client preference, registrar consolidation, cost), it should be documented so the exception doesn't get treated as a pattern.

No evidence from clients with complex multi-domain architectures. All observed DNS setups are single primary domain with optional subdomains or secondary sending domains. We have no evidence from clients managing 5+ domains, which would stress-test the Cloudflare account structure and access model.

Domain security posture is documented for only one client. PaperTube's phishing incident prompted a security review, but no other client in the portfolio has a documented domain security assessment. We don't know how many clients have DMARC gaps, unregistered lookalike domains, or exposed registrar credentials.

GoDaddy 2FA resolution paths are not documented. Two clients (AviaryAI, JBF Concrete) hit GoDaddy 2FA blockers, but the fragments don't document how — or whether — these were resolved. The workaround for JBF was registrar-level redirects, which is a degraded solution. A documented escalation path for GoDaddy access recovery would prevent future stalls.

No data on DNS TTL management during migrations. The fragments document propagation times post-cutover but don't address pre-migration TTL reduction (lowering TTL 24–48 hours before cutover to speed propagation). Whether this is part of the standard workflow is unknown.

Open Questions

Does Cloudflare's free tier WAF provide meaningful protection against the attack patterns targeting small business clients, or is it primarily a checkbox? The PaperTube phishing incident used a lookalike domain, not a direct attack on the protected domain — WAF wouldn't have helped. Understanding which threat vectors the free tier actually mitigates would sharpen the security recommendation.

What is the correct DMARC policy (none / quarantine / reject) for clients at different stages of email maturity? VCEDC lacked DMARC entirely; the fragments recommend adding it but don't specify policy level. Starting at p=reject on a domain with imperfect SPF/DKIM alignment will break legitimate email.

How does Google's 2024 bulk sender requirement (DMARC mandatory for >5,000 daily sends) affect clients who haven't yet implemented it? Several clients in the portfolio send at volumes that may trigger this requirement. The fragments document DMARC gaps but don't assess whether clients are currently in violation.

Is Porkbun's bulk domain search and management interface sufficient for clients managing 10+ protective domains, or does it break down at scale? The recommendation is based on PaperTube's single-client experience with a small number of domains.

What is the operational procedure when a client unilaterally moves DNS away from Cloudflare? The Adovacare incident documents the damage but not the recovery playbook. How quickly can backend tooling be restored, and what is the client communication protocol?

Does the ~10-minute Cloudflare propagation time hold for all record types, or only A records? The evidence is from A record cutovers. MX record changes, which affect email routing, may propagate differently and require different timing expectations during migrations.

Related Topics

• Index
• Index
• Index
• Index
• Index

Sources

Synthesized from 20 Layer 2 articles, spanning 2026-01-07 to 2026-04-08.