Transferring a Domain to Google Cloud Platform: A Pragmatic Workflow

Running production workloads in GCP, while leaving your domain at a third-party registrar, fragments operational control. Centralizing the domain within Google’s ecosystem simplifies DNS management, hardens the attack surface, and improves integration with internal GCP resources. Critically, direct DNS changes propagate rapidly via Google’s infrastructure—a real advantage during incident response or blue/green deployments.

Below is a condensed practitioner’s checklist for moving a domain to GCP (technically, Google Domains) and configuring integrated cloud DNS.

When Moving Your Domain Actually Matters

• M&A activity: consolidating infrastructure across acquired business units.
• CI/CD stack migration: immediate cutover with minimized risk.
• Streamlining managed identities and access (IAM, SSO).

Otherwise, for simple/external sites, benefits are marginal.

Pre-Transfer: Validate Registrar, Policy, and Data

Checklist:

• Verify your registrar supports standard EPP transfers; avoid country-specific TLD quirks (e.g., .uk may require additional contact confirmation).
• Domain must be at least 60 days past creation or last transfer (ICANN rule, RFC 5731 §7.9).
• Current registrar account: domain unlocked (clientTransferProhibited status removed).
• Obtain EPP/Auth code (valid for a limited period, typically 5-14 days).
• Confirm WHOIS admin contact uses an accessible email (no catch-alls, check forwarding rules).
• Export all DNS records—A, AAAA, CNAME, MX, TXT, SRV, CAA. Many providers have JSON or zone file export; otherwise, copy verbatim.

Tip: Save a dated copy of existing DNS records (as CSV or text) for audit and rollback.

Step 1: Unlock & Extract from Current Registrar

Most registrars expose “Domain Lock” via dashboard UI. Disable it. Next, request the EPP code—usually under “Transfer Out” settings. If the UI is unclear, check for clientTransferProhibited in WHOIS output:

whois mydomain.com | grep Status
# should NOT see clientTransferProhibited

Notification of EPP code issuance generally arrives by email; window to use it may be short.

Step 2: Initiate Transfer in Google Domains

Google Domains (as of June 2024) serves as the registrar; GCP Cloud DNS manages DNS zones. These are distinct UIs but closely integrated.

1. Visit https://domains.google/.
2. Select Transfer > enter FQDN.
3. Supply EPP/Auth code, review default settings:
   • Enable privacy (WHOIS redaction)
   • Confirm new owner/admin details (do not skip; mistakes here cause delays)
   • Choose one-year renewal (mandatory per policy)
4. Review quote, submit.

Known issue: Transfers from some providers (e.g., GoDaddy) may require explicit email/portal approval. Monitor inbox (and spam) for confirmation.

Transfer may take up to 7 days by ICANN design; actual completion varies. Interruptions (e.g., registrar-side lock, incorrect WHOIS data) will halt progress. No changes to DNS records until the process is confirmed complete.

Step 3: Reproduce or Migrate DNS Records

On transfer completion, DNS hosting does NOT automatically move. Immediate action needed to avoid downtime. Two options:

Option 1: Use Google Domains Interface

• Go to domains.google.com, select domain, open DNS tab.
  • Manually re-create each DNS record.
  • Set TTL based on workload needs (default is 3600s, lower during migration).
  • For web apps on Compute Engine, use public IPv4/IPv6 for A/AAAA records.

Option 2: Use Cloud DNS for GCP-native Management

Best for complex setups, multi-region/multi-project CDC, or templated infra via IaC (Terraform, gcloud).

• In Google Cloud Console: Network Services > Cloud DNS.
  • Create a managed zone, e.g. mydomain-com.
  • Import saved zone file or use the UI/API.
  • Update nameservers in Google Domains to those given by Cloud DNS.

Example zone file fragment:

@    300 IN A    35.192.45.123
www  300 IN CNAME   ghs.googlehosted.com.
mail 300 IN MX 10   ASPMX.L.GOOGLE.COM.

Gotcha: Cloud DNS zones and Google Domains DNS settings are independent. Switch only when ready—partial configuration can lead to split-brain DNS.

Step 4: Integrate With GCP Services

At this point, tie domain/DNS to your GCP infra:

• Use HTTPS Load Balancer (with managed SSL) for production ingress.
• Attach Cloud CDN to static resources or microservices endpoints.
• Route email (update MX, SPF, DKIM, DMARC records — take care, as propagation can briefly disrupt mail delivery)
• Apply organization-level IAM controls: restrict who can edit DNS, domain, and SSL certs.

Practical example:
Deploy a global web service (App Engine, version 2.21 or later), set up an A record to the load balancer IP, and configure a Cloud Armor policy to rate-limit traffic.

Troubleshooting: Known Friction Points

• No confirmation email: Check mail forwarding, SPF/DKIM on WHOIS admin address. Some providers send from no-reply addresses that get filtered.
• Transfer stuck at ‘waiting for approval’: Log in to current registrar and manually approve on their side. Not obvious—some registrars bury the UI.
• DNS downtime: If propagation or DNS records are missed, outage occurs. Use tools (dig, nslookup) to verify before decommissioning old nameservers.
• Propagation lag: Realistically, cached records persist for ¼ the original TTL on most public recursors. Reduce TTL before migration for minimal brownouts.

Trade-offs and Alternatives

• Google Domains is not available in all jurisdictions; some ccTLDs require local presence.
• For hybrid or multi-cloud setups, consider Cloudflare Registrar + GCP DNS for increased separation (some SREs prefer decoupling).
• A fully automated migration (e.g., Terraforming DNS entries) is nontrivial and error-prone; manual review is still best-practice for critical domains.

Summary

Moving a domain into GCP (via Google Domains) shifts operational control closer to the workloads and eliminates a common friction point in cloud-native infrastructure. The real upgrade is the deterministic, API-driven DNS and IAM integration—not just “one less vendor login.” Still, it isn’t universally necessary; assess business fit before migrating en masse.

Non-obvious tip: Use GCP’s DNS change logs to audit every edit post-migration. It’s the fastest way to diagnose who touched what, and when, during inevitable troubleshooting.

Questions about GCP domain moves or DNS cutovers? Add them below. Implementation isn’t perfect yet—but each quarter, integration tightens.