Skip to content
DevOps devops domains 5 min read

Nameservers & DNS Propagation

When you buy a domain name, the registrar (the company you bought it from, like Namecheap or GoDaddy) needs to know who is in charge of answering questions about that domain. That “who is in charge” is decided by nameservers — special servers that hold your DNS records (the entries that map your domain to IP addresses). This page explains what nameservers are, how to point your domain at a managed DNS provider like Cloudflare or AWS Route 53, and why changes can take hours to take effect (a process called propagation).

What is a nameserver?

A nameserver (often shortened to NS) is a server whose entire job is to answer DNS questions about a domain. DNS, short for Domain Name System, is the internet’s phone book: it turns human-friendly names like devcraftly.com into machine IP addresses like 203.0.113.10.

Every domain points to two or more nameservers. When someone’s browser wants to find your site, it eventually asks one of your nameservers: “What is the IP address for www.devcraftly.com?” The nameserver looks up its records and replies. Whoever controls those nameservers controls where your domain points.

You almost never run your own nameservers. Instead you use a managed provider (Cloudflare, AWS Route 53, Google Cloud DNS, your registrar’s own DNS). They give you a fast, reliable set of nameservers and a dashboard to edit records.

Delegation: how the internet finds your nameservers

Delegation means handing control of a domain’s DNS to a specific set of nameservers. It works as a chain from the top down:

  1. The root nameservers know who runs each top-level domain (TLD) like .com, .org, .io.
  2. The TLD nameservers (for .com) know which nameservers are responsible for devcraftly.com.
  3. Your authoritative nameservers (e.g. Cloudflare’s) hold the actual records.

The registrar’s only DNS job is to tell the TLD operator, “for this domain, go ask these nameservers.” That single instruction is the delegation. Once it is set, all DNS edits happen at your DNS provider, not at the registrar.

Pointing your domain at Cloudflare or Route 53

To move DNS to a managed provider, you change the nameservers listed at your registrar. The steps below are done in a web dashboard, not the terminal.

Cloudflare

  1. Sign up at Cloudflare and choose Add a site, then type your domain.
  2. Cloudflare scans your existing records and shows you the two nameservers it assigned you, for example dana.ns.cloudflare.com and rob.ns.cloudflare.com.
  3. Log in to your registrar (where you bought the domain), find the nameserver setting, remove the old ones, and paste in Cloudflare’s two.
  4. Save. Back in Cloudflare, click Done, check nameservers.

AWS Route 53

  1. In the AWS console, open Route 53 → Hosted zones → Create hosted zone and enter your domain.
  2. Route 53 creates an NS record with four nameservers, for example ns-1234.awsdns-56.org, ns-789.awsdns-01.com, and two more.
  3. Copy all four into your registrar’s nameserver settings.

Always copy nameservers exactly as the provider lists them, including all four for Route 53. Leaving one out, or mixing providers, can cause intermittent failures that are very hard to debug because some lookups succeed and others fail.

When to use which

ProviderBest whenCostNotes
CloudflareYou want free DNS, CDN, and DDoS protectionFree tierProxying hides your origin IP
Route 53Your stack is on AWS~$0.50/zone/monthTight integration with ELB, S3
Registrar DNSTiny static site, no extras neededFreeFewer features, slower edits

When NOT to switch nameservers: if you only need to change one record occasionally and your registrar’s DNS is fine, you do not need a third-party provider at all. Switch only when you want a real DNS dashboard, faster propagation, or extra features.

Propagation and TTL: why changes aren’t instant

When you change nameservers or edit a record, the new value is not seen everywhere at once. This delay is called propagation. It happens because DNS answers are cached (stored temporarily) all over the internet — in your operating system, your router, and your internet provider’s resolvers — to make lookups fast.

How long a cached answer is kept is controlled by the TTL, short for Time To Live. It is a number in seconds attached to every record. A record with TTL 3600 may be cached for one hour before resolvers ask again.

There are two different waits to understand:

  • Record edits (changing an A record’s IP, for example) clear within the record’s TTL — often 5 minutes to a few hours.
  • Nameserver changes (delegation) are different. They depend on the TLD’s NS TTL, which is often 24–48 hours, and registrar processing time. This is why moving to Cloudflare can take up to two days.

Lower a record’s TTL to 300 seconds (5 minutes) a day before a planned change. Resolvers will then re-check quickly, so your switch goes live fast. Raise it back to 3600 afterwards to reduce DNS traffic.

Checking delegation with dig +trace

dig is a command-line DNS lookup tool. Install it on Ubuntu and use +trace to follow the chain from the root down, which is the best way to see which nameservers are actually answering for your domain.

sudo apt update
sudo apt install -y dnsutils
dig +trace devcraftly.com

Output:

.                       518400  IN  NS  a.root-servers.net.
com.                    172800  IN  NS  a.gtld-servers.net.
devcraftly.com.         172800  IN  NS  dana.ns.cloudflare.com.
devcraftly.com.         172800  IN  NS  rob.ns.cloudflare.com.
devcraftly.com.         300     IN  A   203.0.113.10
;; Received 49 bytes from 173.245.59.31#53(dana.ns.cloudflare.com) in 12 ms

The last lines confirm Cloudflare’s nameservers are now authoritative and the A record resolves to 203.0.113.10. To check just the nameservers, run:

dig NS devcraftly.com +short

Output:

dana.ns.cloudflare.com.
rob.ns.cloudflare.com.

If this still shows your old nameservers, propagation is not finished — wait and check again. Querying a public resolver directly with dig @1.1.1.1 devcraftly.com lets you compare what different resolvers see.

Best Practices

  • Lower TTLs to 300 seconds a day before any planned DNS or server move, then raise them afterward.
  • Copy every nameserver your provider gives you — all four for Route 53 — exactly as shown.
  • Never split DNS between two providers for the same zone; pick one authoritative provider.
  • Use dig +trace and dig NS to confirm delegation before assuming a change is live.
  • Plan for up to 48 hours when changing nameservers, and avoid doing it right before a launch.
  • Keep a record of your old DNS entries so you can recreate them at the new provider before switching.
Last updated June 15, 2026
Was this helpful?