DNS NS records tell the internet which name servers are authoritative for your domain.
Let’s say you own example.com. When someone types www.example.com into their browser, their computer needs to find the IP address for that server. To do this, it first needs to find the IP address of a name server that knows about example.com. That’s where NS records come in. They point from your domain name (example.com) to the actual hostnames of your name servers (e.g., ns1.yournameserverprovider.com).
Imagine you’re setting up a new domain, mynewcoolsite.net, and you’ve chosen a DNS hosting provider like Cloudflare.
Here’s what you’d typically see in your domain registrar’s control panel (where you bought mynewcoolsite.net). You’ll look for a section often labeled "Nameservers" or "DNS Management."
You’ll find fields for your NS records. They won’t look like this:
mynewcoolsite.net. IN NS ns1.yournameserverprovider.com.
mynewcoolsite.net. IN NS ns2.yournameserverprovider.com.
Instead, your registrar will ask you to enter the hostnames of the name servers provided by your DNS host. So, you’ll input:
ns1.cloudflare.com
ns2.cloudflare.com
ns3.cloudflare.com
ns4.cloudflare.com
ns5.cloudflare.com
(Cloudflare, for example, uses five name servers).
Once you save these, your domain registrar updates the top-level DNS hierarchy. For mynewcoolsite.net, the .net TLD’s authoritative name servers will now know that if queried for mynewcoolsite.net, they should delegate the request to Cloudflare’s name servers.
This is the crucial delegation step. Your domain registrar doesn’t host your DNS records; it just points to who does. When a browser’s DNS resolver asks for www.mynewcoolsite.net, it first asks the root name servers, then the .net name servers. The .net name servers, now knowing about your NS records, will respond with the IP addresses of Cloudflare’s name servers. The resolver then queries Cloudflare’s name servers to get the IP address for www.mynewcoolsite.net.
The actual NS records are stored with your DNS provider. If you were to dig your domain for NS records after delegation, you’d see them:
dig ns mynewcoolsite.net +short
This would output something like:
ns1.cloudflare.com.
ns2.cloudflare.com.
ns3.cloudflare.com.
ns4.cloudflare.com.
ns5.cloudflare.com.
This command queries the authoritative name servers for mynewcoolsite.net (which, at this point, would be Cloudflare’s if delegation is complete) and asks for the NS records.
The common mistake is confusing the NS records you enter at your registrar with the NS records that are stored at your DNS provider. At the registrar, you’re providing hostnames. At your DNS provider, you’re defining the authoritative DNS zones for your domain, which also include NS records that often point back to the same name servers.
For example, within Cloudflare’s dashboard for mynewcoolsite.net, you might have records like this (though Cloudflare manages this implicitly):
mynewcoolsite.net. IN NS ns1.cloudflare.com.
mynewcoolsite.net. IN NS ns2.cloudflare.com.
... and so on for ns3, ns4, ns5.
These records within your DNS provider’s zone tell other DNS servers that these specific name servers are responsible for answering queries about mynewcoolsite.net. It’s a self-referential system to ensure smooth delegation.
The trickiest part is understanding the two distinct places NS records live and what they signify. The NS records at your registrar are the pointers to your DNS host. The NS records within your DNS host’s zone are the authoritative declarations of your name servers. Both are essential for proper DNS resolution.
The next step after setting up NS records is often configuring A, AAAA, or CNAME records to actually point your domain and subdomains to your web server or application.