In the previous article we built our own authoritative DNS server with BIND9. That works well — but for production public-facing domains, most organisations use a managed DNS provider. This article explains when to self-host, when to outsource, how to compare providers, and the exact procedure for migrating nameservers.

Self-Hosted vs Managed DNS

When to Self-Host

• You need full control over zone data, including custom record types or non-standard TTL ranges.
• You run internal DNS for a private network not exposed to the internet.
• You are learning DNS internals (the motivation for Article 6).
• You want to avoid vendor lock-in and provider dependency.
• You operate an enterprise environment where the DNS server must be on-premises for compliance.

When to Use Managed DNS

• Production public-facing domains with traffic from multiple geographic regions.
• You need anycast without managing BGP peers and multiple VPS instances.
• You want built-in DDoS protection at the DNS layer.
• You manage many domains and need API-driven automation.
• You want one-click DNSSEC without key management overhead.

Reference: “DNS and BIND” by Cricket Liu (5th Ed., O’Reilly) — Chapter 11 covers DNS security, including the risks of running authoritative servers without DDoS protection.

Managed DNS Provider Comparison

Cloudflare DNS — Most Popular Choice

Cloudflare operates one of the largest anycast networks globally — 330+ cities in 120+ countries. Their DNS is free, fast, and includes DDoS protection (both DNS-layer and HTTP-proxy). Most domains using Cloudflare DNS also proxy HTTP traffic through Cloudflare’s CDN, which hides the origin IP.

For rootlog.in, Cloudflare would be the simplest option:

1. Sign up for Cloudflare
2. Add rootlog.in — Cloudflare automatically scans existing DNS records
3. Verify domain ownership (via TXT record, email, or upload)
4. Replace current nameservers at the registrar with Cloudflare’s:

Current:  dns1.p01.nsone.net, dns2.p01.nsone.net
New:      dave.ns.cloudflare.com, meera.ns.cloudflare.com

5. All records are served via Cloudflare’s anycast network

Reference: Cloudflare DNS documentation — https://developers.cloudflare.com/dns/ Reference: Cloudflare API — https://api.cloudflare.com/

AWS Route53 — Best for AWS-Integrated Infrastructure

Route53 is tightly coupled with AWS services. If your infrastructure runs on EC2, ALBs, and S3, Route53 is the natural choice. It supports health checks that automatically fail over DNS records when an endpoint goes down — for example, routing traffic away from a failed AZ.

Route53 charges per hosted zone ($0.50/month per zone) and per million queries ($0.40/M for standard queries). The free tier covers 50 zones and 1M queries per month.

Pro tip: Route53 Alias records (a Route53-specific extension) let you point a zone apex to an AWS resource (ELB, CloudFront, S3 bucket) without using a CNAME. This is not standard DNS — it works only because Route53 is both the DNS provider and the AWS resource operator.

Reference: AWS Route53 documentation — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/

NS1 — Best for Traffic Steering

NS1 offers filter chains that let you route traffic based on geolocation, ASN, latency, or custom metadata. This is useful for global applications that need to direct users to the nearest datacenter or apply blue/green deployments at the DNS level.

Registrar vs DNS Provider — Why They Are Separate

This is one of the most misunderstood concepts in DNS. They serve different roles.

You buy the domain from the registrar. You point it to your DNS provider by setting the nameservers. The DNS provider hosts the actual records (A, MX, TXT, etc.).

You can and should use different companies for registration and DNS. For example:

• Register with Porkbun (cheap, privacy-focused registrar)
• Host DNS with Cloudflare (free, fast, anycast)

This separation means your DNS is not affected if your registrar has an outage. A registrar outage takes down the management interface, but the NS records in the TLD are already set to point to your DNS provider — those do not change until you explicitly update them.

Real-world context: In 2021, a major registrar experienced a multi-hour outage that prevented customers from logging into their control panel. Customers who used the registrar’s own DNS had their domains go unresolvable. Customers who used separate DNS providers (Cloudflare, Route53) had no interruption — their nameservers were already delegated and continued serving normally.

How to Switch Nameservers (8-Step Migration)

Switching DNS providers is a controlled process. Here is the exact procedure:

Step 1: Export Existing Records

Before touching anything, dump all records from your current provider:

# Zone transfer if allowed
dig @dns1.p01.nsone.net rootlog.in AXFR
 
# Alternatively, query each record type
dig @dns1.p01.nsone.net rootlog.in A +short
dig @dns1.p01.nsone.net rootlog.in MX +short
dig @dns1.p01.nsone.net rootlog.in TXT +short
dig @dns1.p01.nsone.net rootlog.in NS +short

If AXFR is blocked, manually list all records from the provider’s dashboard.

Step 2: Create the Zone at the New Provider

Add all records to the new provider’s DNS console. Match TTLs exactly. Export the zone to a scriptable format for repeatability.

Step 3: Reduce TTLs (48+ Hours Before Switch)

Set all TTLs to 300 seconds (5 minutes) on the current provider. This ensures that when you switch, old cached records expire quickly. Wait at least 48 hours for all resolvers to pick up the new low TTL.

# Verify the new TTL is served by authoritative servers
dig @dns1.p01.nsone.net rootlog.in A +ttlid

Step 4: Verify the New Zone

Query the new provider’s nameservers directly:

dig @dave.ns.cloudflare.com rootlog.in A
dig @dave.ns.cloudflare.com rootlog.in MX
dig @dave.ns.cloudflare.com rootlog.in TXT

Every record must match the current authoritative server exactly. Pay special attention to MX priorities and TXT record quoting.

Step 5: Change Nameservers at the Registrar

Log into your registrar and replace the old nameservers with the new ones:

Old:  dns1.p01.nsone.net
      dns2.p01.nsone.net
New:  dave.ns.cloudflare.com
      meera.ns.cloudflare.com

Step 6: Verify Delegation

Check that the TLD has picked up the new nameservers:

dig rootlog.in NS +short
dig @a.gtld-servers.net rootlog.in NS +additional

The TLD query confirms the delegation has changed. The +additional flag shows glue records.

Step 7: Wait and Monitor

Due to the low TTLs set in Step 3, most recursive resolvers will pick up the new NS records within minutes. Monitor resolution from multiple public resolvers:

dig @1.1.1.1 rootlog.in
dig @8.8.8.8 rootlog.in
dig @9.9.9.9 rootlog.in

Use global DNS checkers for geographic verification:

• https://dnschecker.org/
• https://www.whatsmydns.net/

Step 8: Restore TTLs

After confirming that all resolvers serve the new data, increase TTLs back to their original values.

Zone Transfer Between Providers

Most managed DNS providers support incoming zone transfers (AXFR) from your self-hosted BIND server. This lets you manage the zone locally and automatically sync to the cloud.

BIND as Hidden Master, Cloudflare as Secondary

On your BIND server, allow Cloudflare’s IPs to transfer:

zone "rootlog.in" {
    type master;
    file "/etc/bind/zones/db.rootlog.in";
    allow-transfer { 103.21.244.0/24; };   # Cloudflare transfer IPs
    also-notify { 103.21.244.0/24; };
};

In Cloudflare, enable zone transfer and enter your BIND server IP. Cloudflare will pull the zone automatically when the serial increments. This setup is called a hidden master — the BIND server is not publicly resolvable as an NS, but it is the source of truth for the zone.

Route53 as Secondary

AWS Route53 does not support secondary DNS via AXFR. You must use the Route53 API (via AWS SDK, CLI, or cli53 tool). For automated sync, write a script that:

1. Runs dig AXFR from the BIND master
2. Parses the zone data into Route53’s change-resource-record-sets format
3. Pushes via aws route53 change-resource-record-sets

Dynamic DNS with Managed Providers

Managed DNS providers offer APIs that let you update records programmatically. This is useful for:

• Home servers with dynamic public IPs
• Automatic failover between datacenters
• CI/CD pipelines that update DNS as part of deployment

Cloudflare API

curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"home.rootlog.in","content":"203.0.113.42","ttl":120,"proxied":false}'

Route53 CLI

aws route53 change-resource-record-sets \
  --hosted-zone-id Z123456789 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "home.rootlog.in",
        "Type": "A",
        "TTL": 120,
        "ResourceRecords": [{"Value": "203.0.113.42"}]
      }
    }]
  }'

Dynamic DNS with RFC 2136 (nsupdate)

The nsupdate utility (part of BIND) sends dynamic DNS update messages per RFC 2136:

nsupdate <<EOF
server 203.0.113.10
zone rootlog.in
update delete home.rootlog.in A
update add home.rootlog.in 120 A 203.0.113.42
send
EOF

This requires the target server to accept dynamic updates, typically restricted via TSIG (shared secret) authentication (RFC 2845).

Reference: RFC 2136 — Dynamic Updates in the Domain Name System (DNS UPDATE). https://datatracker.ietf.org/doc/rfc2136/ Reference: RFC 2845 — Secret Key Transaction Authentication for DNS (TSIG). https://datatracker.ietf.org/doc/rfc2845/

Secondary DNS as Backup

Even with a managed primary DNS provider, you should configure a secondary DNS server on a different provider. This ensures DNS resolution continues if your primary provider has an outage.

# Configure BIND as a slave to Cloudflare
zone "rootlog.in" {
    type slave;
    file "/var/cache/bind/db.rootlog.in";
    masters { 173.245.58.73; };  # Cloudflare NS IP
};

Or use a specialised secondary DNS service:

• BuddyDNS — provides secondary DNS for any primary provider
• dnssecondary.com — dedicated secondary DNS service
• SecondaryDNS — multi-provider secondary DNS

CNAME Flattening and ANAME/ALIAS Records

RFC standards forbid CNAME records at the zone apex. However, many managed DNS providers support CNAME flattening (also called ANAME or ALIAS records), which resolves the CNAME target transparently and serves the resulting A/AAAA records directly.

This is essential when hosting on platforms that provide a single hostname:

• GitHub Pages: username.github.io
• Netlify: site-name.netlify.app
• Vercel: project-name.vercel.app
• AWS CloudFront: d123.cloudfront.net

With Cloudflare, this is called CNAME flattening and is enabled by default for proxied records. With Route53, Alias Records provide the same functionality but only for AWS resources.

Multi-Provider DNS

For maximum resilience, run authoritative DNS across two providers simultaneously:

• Primary: Cloudflare (free, anycast, DDoS protection)
• Secondary: Route53 (AWS integration, health checks)

List both provider’s NS records at your registrar. Recursive resolvers will try one provider, and if it fails, fall back to the other. This is the enterprise-grade DNS architecture.

Key Takeaways

• Managed DNS provides anycast, DDoS protection, and APIs at the cost of some control.
• Cloudflare DNS is the most popular free option with the fastest global anycast network.
• Registrar and DNS provider are separate roles — use the best provider for each.
• When switching providers: reduce TTLs 48+ hours in advance → verify new zone → switch NS → monitor → restore TTLs.
• CNAME flattening (ANAME/ALIAS) allows CNAME-like behaviour at the zone apex.
• Dynamic DNS via RFC 2136 and provider APIs enables automated DNS updates.
• Always run at least two nameservers across different providers for disaster resilience.

Further Reading

• Cloudflare DNS docs — https://developers.cloudflare.com/dns/
• AWS Route53 Developer Guide — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/
• Google Cloud DNS docs — https://cloud.google.com/dns/docs
• NS1 Managed DNS docs — https://docs.ns1.com/
• dnsimple docs — https://dnsimple.com/documentation
• RFC 2136 — Dynamic DNS Updates
• RFC 2845 — TSIG (authentication for dynamic updates)
• RFC 5936 — AXFR (zone transfer)
• RFC 6781 — DNSSEC Operational Practices
• https://dnschecker.org/ — global propagation checker
• “DNS and BIND” by Cricket Liu (5th Ed., O’Reilly) — Chapters 11-13 cover DNS security, DNSSEC, and troubleshooting.

This concludes the DNS Demystified series. You now understand the full stack — from root servers and resolvers to zone files, troubleshooting, self-hosted BIND, and managed DNS migration.