What Are Nameservers? How They Work and How to Change Them

The Fundamental Role and Hierarchy of Nameservers

A nameserver is a DNS server that holds the authoritative records for a specific domain. When the global DNS system needs to resolve example.com, it ultimately asks example.com's nameservers — and only those nameservers' answers are considered authoritative. Other DNS servers in the chain (recursive resolvers, ISP caches) may have cached copies of the answers, but the nameservers are the definitive source. They function as the primary database of record for your domain's identity on the internet.

Nameservers are identified by hostname rather than IP address — for example, ns1.exampledns.com and ns2.exampledns.com. They are assigned to a domain through the domain registrar, and the assignment is recorded in the registry for the domain's top-level domain (TLD). When you "change nameservers" for a domain, you are telling the TLD registry to update this assignment so that the rest of the world knows who to ask for your records.

DNS resolution is strictly hierarchical. When a recursive resolver needs to find your domain's records, it works down through layers of the hierarchy, starting from the root and moving toward the specific authoritative source. This process ensures that no single server has to store every record for every domain, distributing the load across millions of servers globally.

1. Root Servers: These 13 logical root server clusters sit at the top. They don't know your IP address, but they know who handles .com domains and will point the resolver in the right direction.

2. TLD Nameservers: Operated by registries like Verisign, these servers handle extensions like .net or .org. They store the NS (delegation) records that point to your specific authoritative nameservers.

3. Authoritative Nameservers: This is the server you control (or your DNS provider controls). It holds the actual A, MX, and TXT records. This is where the resolver finally gets the answer it needs to connect.

4. Recursive Resolver: The resolver (like Google DNS or Cloudflare) caches the authoritative answer it received so that it doesn't have to repeat the entire hierarchical journey for the next user.

The critical step is the delegation at the TLD level. Your registrar communicates with the TLD registry on your behalf to maintain this link. If this link is broken or points to the wrong servers, your domain will appear non-existent to the rest of the internet, regardless of how perfectly your zone files are configured.

Technical Mechanisms: NS Records and Glue Records

NS (Name Server) records are the DNS record type that implements nameserver delegation. They exist in two places, which is a common source of confusion for administrators. The first is at the TLD level (the delegation), where the registry holds NS records pointing to your nameservers. These are set by your registrar and can only be changed through your registrar's interface.

The second location is within your own zone file. Your DNS provider publishes NS records inside your zone that should match the delegation at the TLD. While it might seem redundant, this is required by DNS specifications and helps recursive resolvers confirm they have reached the correct authoritative source.

; NS records as they appear at the TLD (delegation)
; These carry a high TTL (usually 48 hours)
example.com.  172800  IN  NS  ns1.exampledns.com.
example.com.  172800  IN  NS  ns2.exampledns.com.

; NS records inside your own zone file
; You can control this TTL (e.g., 3600s)
example.com.  3600  IN  NS  ns1.exampledns.com.
example.com.  3600  IN  NS  ns2.exampledns.com.

The high TTL at the TLD (typically 48 hours) is why nameserver changes take so long to propagate. You cannot lower this value because it belongs to the registry, not your zone. This is a fundamental safety mechanism of the global DNS infrastructure, ensuring that delegation data remains stable and caches are not cleared too frequently.

A circular reference problem arises when your nameservers are subdomains of the domain they serve. If example.com's nameservers are ns1.example.com, resolving the domain requires the IP of the nameserver, but finding that IP requires querying the domain itself. This "chicken and egg" problem is solved by glue records. These are A records for the nameserver hostnames published directly in the TLD's registry.

💡 Tip: If your nameservers are provided by a third-party (e.g., Cloudflare), you don't need glue records. Glue records are only necessary if you are running your own nameservers on hostnames that belong to the same domain they are managing.

Classifications of Nameservers and Deployment Models

When selecting a DNS architecture, you must choose between registrar-provided infrastructure and custom (third-party) nameservers. Registrar nameservers are the default servers assigned when you register a domain. They are convenient for simple setups but often lack the advanced features and global performance of dedicated DNS platforms.

Custom nameservers point to a specialised DNS provider like Cloudflare, AWS Route 53, or NS1. These providers operate massive global anycast networks, where the same IP address is advertised from hundreds of locations. This ensures a user in London queries a server in London, while a user in Tokyo queries one in Tokyo, dramatically reducing latency.

As shown in the table above, custom nameservers are the preferred choice for production environments. They offer better redundancy and security features, such as rate-limiting and DDoS protection, which are rarely available on basic registrar-provided servers.

The terms "primary" and "secondary" nameservers represent the traditional redundancy model. In a classic setup, the primary nameserver holds the editable master copy of the zone, while secondary nameservers receive read-only copies via zone transfers (AXFR). In modern managed DNS, this distinction is often hidden—the provider handles the synchronisation across their entire network automatically.

Regardless of the underlying model, the golden rule of nameserver deployment is to always use at least two nameservers. For critical infrastructure, it is common to use four nameservers spread across different Top-Level Domains (e.g., .com, .net, and .org) to ensure that even a major TLD failure or provider outage doesn't take your domain offline.

Identifying and Updating Your Nameserver Configuration

Before making any changes to your infrastructure, you must be able to identify your current authoritative sources. You can find this information using command-line tools like dig or through WHOIS lookups. WHOIS is particularly useful because it shows the "source of truth" registered at the TLD level, bypassing any intermediate caching.

# Method 1: Check what the TLD currently shows (authoritative)
dig NS example.com @8.8.8.8 +short

# Method 2: WHOIS lookup (shows registrar-level data)
whois example.com | grep -i "name server"

# Method 3: Trace the full delegation path
# This is the best way to see the root -> TLD -> Authoritative flow
dig NS example.com +trace

The output of these commands tells you exactly where your records are living. If dig NS and WHOIS disagree, it indicates that a previous change is still in the middle of the propagation window. Use our NS Lookup to confirm what resolvers worldwide are seeing in real-time.

When you are ready to update your configuration, the process must be handled with extreme care. Changing nameservers essentially hands over the "keys" to your domain. If the new nameservers are not ready when the switch happens, your website and email will stop working entirely for users who pick up the update.

1. Audit and Replicate: Documentation is the most important step. Export every single record from your current provider and recreate them exactly at the new provider. Do not forget "hidden" records like verification TXT tags or SRV records for services like Microsoft 365.

2. Verify the New Zone: Before changing anything at the registrar, query the new nameservers directly. Use dig A example.com @ns1.newprovider.com to ensure the new server is already responding with the correct data.

3. Update at the Registrar: Log in to your registrar's control panel and replace the old nameserver hostnames with the new ones. This action initiates the delegation update to the TLD registry.

4. Monitor Propagation: Use the DNS Propagation Checker to watch the change spread globally. Because of the 48-hour TLD TTL, you should keep your old DNS zone active for at least 72 hours even after you think propagation is finished.

⚠️ Warning: Never delete your records from the old DNS provider immediately after switching nameservers. Resolvers will continue to query the old servers for up to 48 hours. If the old zone is deleted prematurely, those queries will fail.

Transition Dynamics and Post-Change Verification

A nameserver change is a gradual process, not a sudden switch. Because different resolvers refresh their caches at different times, the world will be in a "split" state for up to 48 hours. Some users will reach your new nameservers, while others will still be directed to your old ones.

The transition timeline typically follows a predictable curve. Within the first two hours, most major public resolvers (like Google and Cloudflare) will pick up the change. Within 24 hours, the vast majority of ISP resolvers will update. The final 24 hours are usually reserved for the most stubborn or non-compliant caches in distant regions.

During this window, it is critical to verify the health of the new delegation. You can bypass local caches and query the TLD nameservers directly to confirm that the registry has correctly updated your information to point to the new provider.

# Query the GTLD servers directly for your domain
# This confirms the registrar successfully updated the registry
dig NS example.com @a.gtld-servers.net +short

# Confirm your new provider is responding with Authority bit set
dig A example.com @ns1.yournewprovider.com

If the TLD query returns the new nameservers but your site still isn't loading, the issue is likely with the configuration at the new provider, not with the propagation process itself. Check for missing A records or SSL certificate mismatches that might be preventing successful connections to your new hosting environment.

💡 Tip: If you see any errors during the transition, do not try to "fix" it by switching back and forth. This resets the TTL timers and can lead to even longer outages. If you must roll back, do it once and wait for the old records to propagate again.

Managing Common Nameserver Risks and Failures

Nameserver management involves several high-stakes risks that can take a domain offline if handled incorrectly. The most common failure point is the nameserver mismatch, where the NS records in your zone file do not match the delegation records at your registrar. While DNS will often "find the way," this mismatch causes increased latency and can lead to resolution failures for stricter resolvers.

Another critical risk involves DNSSEC (Domain Name System Security Extensions). If you have DNSSEC enabled and you change nameservers without first removing the old DS (Delegation Signer) record from your registrar, your domain will break. This is because resolvers will try to validate the signatures on the new server using the old keys, which will fail and result in a global outage for validating resolvers.

• Missing Email Records: MX records are frequently forgotten during migrations. Without them, inbound email is essentially suspended.
• Glue Record Errors: If you change the IP address of a host used for a nameserver but forget to update the glue record at the registrar, the delegation will point to a "dead" IP.
• TTL Stale Entries: High TTLs on records before a migration ensure that users stay on the old server longer. Always lower A/CNAME TTLs to 300s several days before a planned nameserver change.
• TLD Unreachability: Though rare, choosing nameservers all on the same TLD (e.g., all .com) means a catastrophic failure of that TLD registry takes your domain with it. Diversity is best practice.

One final common mistake is confusing the Registrar with the DNS Provider. Your registrar manages the "link" to your nameservers, while your DNS provider manages the records stored on those servers. If you are trying to add a new subdomain, you do it at the DNS Provider. If you are moving to a new DNS Provider, you do it at the Registrar.

Always verify your final configuration using a comprehensive DNS Zone Health Check. This will flag technical issues like "lame delegations" (where a nameserver is listed but doesn't have the zone), serial number mismatches, and incorrect NS record counts that could compromise the stability of your production domain.

Frequently Asked Questions

Next Steps

Use our NS Lookup tool to check your current nameserver delegation from multiple resolvers worldwide, or run our DNS Check for a full zone health audit.

If you are planning a migration, see our DNS Migration Without Downtime guide for the complete record audit and cut-over sequence.

Browse all DNS guides on DNSnexus for related topics.

Related Guides

• How DNS Propagation Works: TTL, Resolvers & the Global Timeline
• DNS Propagation Still Pending After 24 Hours? Here's Why
• How to Migrate DNS to a New Host Without Downtime
• DNS TTL Explained: What It Is, How to Set It, and When to Lower It