Seamlessly Migrating DNS from GoDaddy to AWS Route 53

Critical infrastructure changes—like DNS migrations—shouldn’t disrupt user access or introduce outages. Yet, trusting UI wizards for production DNS cutovers is reckless. GoDaddy’s DNS remains static and limited; Route 53 scales internationally, supports dynamic routing, and natively syncs with AWS-native workloads. Below: all the nuanced steps and pitfalls in real-world DNS migration, including record import pain points, TTL tuning, and propagation caveats.

Why Route 53 Supersedes GoDaddy DNS

• Native AWS Integration: Route 53 links directly to EC2, ELB, CloudFront; no glue records or cross-provider hacks.
• Dynamic Routing: Geolocation, weighted, and failover policies eliminate manual record juggling.
• Detailed Health Checks: Automate endpoint failover for A/AAAA records.
• Scalable API & Automation: Boto3, AWS CLI, Terraform, and cli53 support enable true Infrastructure-as-Code for DNS.

GoDaddy is adequate for static sites but outclassed for modern, elastic architectures.

1. Assess Existing DNS

An incomplete migration often stems from missed records or TTL misconfiguration.

• Inventory DNS: Enumerate every record: A, AAAA, CNAME, MX, TXT, SRV, CAA, plus any custom SPF/DKIM. GoDaddy omits export support—plan for manual extraction.
• TTL Planning: Existing records may have 1h–24h TTLs; reduce all to 300s (5 minutes) 24 hours prior to migration. This reduces client-side caching when you switch providers.

Tip: Watch for internal-use-only records (development systems, subdomains) that aren't obvious from your public-facing config.

2. Extract Records From GoDaddy

GoDaddy lacks a zone file export. Workarounds:

• Manual Copy: Navigate to GoDaddy DNS Manager, document all entries by hand.

• Automated Scrape: Third-party tools like dns-zonefile-export (Python, unofficial) can dump via Selenium scripting.

• Query Authoritative Servers: For public records only, run:

  dig @<current_godaddy_ns> example.com AXFR
  

  Gotcha: Most registrars block AXFR by default—expect:

  ; Transfer failed.
  

  Don’t rely on AXFR for this.

3. Prepare Route 53 Hosted Zone

• Login to AWS Console (tested on awscli 2.15.x)
• Create a Public Hosted Zone for your domain (do not prefix with www., enter as example.com).
• Capture the four generated NS values; e.g.,

  ns-2048.awsdns-64.com
  ns-2049.awsdns-65.net
  ns-2050.awsdns-66.org
  ns-2051.awsdns-67.co.uk
  

  AWS nameservers won’t match GoDaddy’s—do not attempt to mix.

4. Import Records into Route 53

Manual UI Method

• In Route 53 Hosted Zone, select Create record for each DNS entry.

• Enter type, hostname, value, and set the reduced TTL (e.g., 300s).

• Example:

  Type	Name	Value	TTL
  A	@	198.51.100.24	300

CLI Automation (for many records)

For >10 records, use cli53:

1. Create a BIND-format zone file (zonefile.txt). Example:

   $ORIGIN example.com.
   @ 300 IN A 198.51.100.24
   www 300 IN CNAME example.com.
   

2. Import with:

   cli53 import --file zonefile.txt --replace example.com
   

Note: Route 53 will reject duplicate or invalid records (e.g. CNAME at apex). Error returned:

InvalidChangeBatch: [Tried to create resource record set [Name=example.com., Type=CNAME] but it already exists]

Handle these manually.

5. Switch Nameservers at GoDaddy

• In GoDaddy domain manager, open the domain’s settings.
• Under Nameservers, select Custom and input all four Route 53-provided NS values.
• Save. Lock-in can take up to 48h globally, though typical TTL-driven propagation is ~1–2 hours.

Known Issue: GoDaddy UI occasionally rejects new NS entries due to formatting (trailing dot). Omit trailing dots in the GoDaddy UI; e.g., ns-2048.awsdns-64.com (not ns-2048.awsdns-64.com.).

6. Validate Migration & Propagation

• Confirm authoritative NS:

  dig NS example.com +short
  

  Must match AWS NS set.

• Test vital record types:

  dig A example.com +short
  dig MX example.com +short
  dig TXT example.com +short
  dig CNAME www.example.com +short
  

  Output should equal Route 53 entries.

• Use dnschecker.org to inspect global status.

Practical flaw: Some ISPs or enterprise networks cache nameserver data for days, regardless of TTL. Critical for email—always test actual mail delivery post-migration.

7. Retire or Document Old Configs

• Once confirmed stable (monitor 48 hours), legacy GoDaddy DNS records may remain as harmless debris; consider cleaning to avoid operator confusion.
• Return TTLs to sane values (30m–1h) for non-changing records; keep mail/service endpoints at low TTL if frequent future cutovers are planned.
• Document every non-obvious mapping, e.g. TXT used for domain verification (Google Workspace, Office 365).

Additional Professional Notes

• Parallel Dry-Run: Before switching, stand up a test domain or a subdomain (test.example.com) in Route 53, replicate all entries, and point an internal device via /etc/hosts for end-to-end validation.
• Health Checks: For applications demanding >99.9% availability, deploy Route 53 health checks and attach them to critical A or CNAME records. Example config:

  {
    "HealthCheckConfig": {
      "IPAddress": "198.51.100.24",
      "Port": 443,
      "Type": "HTTPS",
      "ResourcePath": "/status"
    }
  }
  

• Change Windows: For SaaS or B2B domains, always migrate on weekends or published maintenance windows—client-side caching can defy expectations.

Not Perfect: Trade-Offs

• Route 53’s UI lags vs. Cloudflare for bulk edits.
• Bulk import tools mangle some advanced record types.
• Split-horizon or private DNS? Separate zones and VPC associations required.

Migrating DNS to Route 53 isn’t just a click-and-wait event—it’s a deliberate re-platforming. Treat it with the same respect as a database failover or TLS key rollover. Most downtime traces back to hidden records or TTL mishandling. Validate, monitor, and expect the unexpected.

Questions about DKIM, SPF, or multi-region failover on Route 53? Post specifics, or check the AWS Route 53 Developer Guide for extended patterns.

Originally published on [Your Blog Name], for practitioners who demand cloud DNS precision.