DNS Migration Done Right: Lessons from Moving to Route 53

Introduction

DNS migrations don’t usually get much attention. They’re invisible when done right and very loud when done wrong.

At TO THE NEW, we recently migrated DNS for an ad tech client from NS1 (an IBM Product) to AWS Route 53 as part of their large move to AWS and cost savings. On paper, this looked like a simple vendor switch. In reality, it was a careful exercise in cost optimization, planning, validation, and controlled risk. This post isn’t just about what we did — it’s how the dns migration really works behind the scenes, the tools we used, and the checks that helped us sleep during cutover.

Why We Even Looked at DNS Costs

When the client initially moved from Data Center to AWS in 2022, they chose NS1 with a 2-billion queries/month plan to stay future-ready..

A few months later, we looked at actual usage:

• Average daily queries: ~4 million
• Traffic pattern: stable, predictable
• Peak spikes: minimal
• In short, we were paying for headroom we didn’t need.

Route 53, with its pay-as-you-go pricing and tight AWS integration, became the obvious choice, but only after validating that it could reliably handle current and future traffic.

Step 1: Understanding DNS Traffic (Before Touching Anything)

Before creating even a single Route 53 hosted zone, we focused on query behavior.

Two key observations were:

• Most DNS traffic was steady-state
• TTL values were lower than necessary
• We increased TTLs to 3600 seconds (1 hour) well before the migration.

This change helped in two ways:

• First, it reduced the overall number of DNS queries almost immediately.
• Second, it made the final nameserver switch much safer and more predictable.

TTL tuning is an example of a minor configuration change that can have a significant effect. It’s easy, yet frequently disregarded.

Step 2: DNS Reconstruction: Handle It Like Actual Infrastructure

We thoroughly rebuilt everything rather than transferring records by hand between consoles. A, AAAA, CNAME, TXT, MX, and other records were recreated exactly as they were in NS1 after we created the hosted zones in Route 53. We treated DNS the same way we treat the rest of our infrastructure — structured, reviewed, and controlled — not something managed casually in a browser tab.

Terraform as the Source of Truth

Everything was managed using Terraform, which gave us:

• Version control for DNS (yes, that matters)
• Easy review and approvals
• Instant rollback if something went wrong

This also ensured environment parity — no “prod-only surprises”.

Step 3: Validating Before the Cutover (This Is Where Most Time Goes)

Before touching nameservers, we spent time validating Route 53 responses in isolation for one of the test domains. Useful Commands During Validation:

Check authoritative answers from Route 53:

dig example.com NS

Trace DNS resolution end-to-end:

dig +trace test.example.com

These checks helped us confirm:

• Records resolve correctly
• No missing entries
• No unexpected TTL behavior

Behind the scenes reality: Most migration time is spent proving nothing will break, not actually switching DNS.

Step 4: The Actual Cutover (Quiet, Boring, Perfect)

By the time we updated nameservers:

• TTLs were already high
• Route 53 was fully validated
• Monitoring was in place
• Nameserver Update
• The domain registrar(GoDaddy in our case) was updated to point to Route 53 nameservers.

Because of earlier TTL tuning, propagation was smooth and predictable.

Real-Time Checks During Cutover

dig example.com NS

dig example.com +trace

We watched:

• Which nameservers were responding?
• How quickly did traffic shift?
• Any unexpected resolution failures?
• No drama. Exactly how DNS migrations should be.

Monitoring After Migration (Do Not Skip This)

Once traffic fully moved to Route 53, we kept a close eye on:

• CloudWatch Metrics
• DNS query count
• Health check status
• Latency anomalies
• Route 53 Health Checks & Failover

Critical endpoints were backed by:

• ALBs with health checks
• Route 53 failover routing
• Automated recovery paths
• Alarms were configured early, before issues could become incidents.

Why Were There Still Queries Hitting NS1 Weeks Later?

One interesting thing we noticed after the migration was that NS1 was still receiving a small number of queries, roughly 1,000 in a 24-hour window, even weeks after we had updated the domain nameservers at the registrar. At first glance, this can feel concerning. If the nameservers were changed correctly, why would any traffic still reach the old provider?

In practice, this is completely normal.

DNS behavior across the Internet isn’t perfectly uniform. Some recursive resolvers cache nameserver (NS) records longer than the published TTL. Internal DNS forwarders that don’t refresh instantly are used by some business networks. Information about authoritative nameservers may also be cached for a long time by third-party vendors, security scanners, or monitoring tools. Rarely, resolver paths may even be hardcoded into systems. All of this can result in a small amount of residual traffic continuing to hit the old authoritative servers.

The important part was context. The query volume was very small compared to overall traffic, it was steadily declining, and Route 53 was correctly serving authoritative responses globally. For this reason, we intentionally did not shut down NS1 immediately. We kept it running during a safe decommission window to ensure there was zero risk to production traffic.

DNS propagation is predictable. Resolver behavior across the internet is not.

What We Gained (Beyond Just Cost Savings)

• Cost Optimization
• Eliminated unused query capacity
• Pay only for what we actually use
• Operational Clarity
• DNS is fully versioned and auditable via Terraform
• No manual console drift
• Better Reliability
• Native AWS integrations (ALB, ACM, health checks)
• Automated failover for critical paths
• Future-Proofing
• Route 53 scales automatically: No need to pre-purchase massive plans

Key Learnings from the Migration

• Data beats assumptions
• Always analyze real traffic before choosing enterprise plans.
• TTL tuning is powerful
• One config change reduced risk across the entire migration.
• DNS deserves IaC: IAAC isn’t just for servers; DNS is infrastructure too.
• Validation > Execution
• The safest migrations are the most boring ones.

Conclusion

This ad tech client discovered that moving from NS1 to Route 53 had a major business impact, including lower costs, increased reliability, and simpler operations, despite the fact that DNS migrations may not seem glamorous.

At To The New, we look for these opportunities where small infrastructure decisions have big effects. This migration was a reminder that even the quietest layers of the stack require careful engineering. For your DNS workloads, contact us!