DNS Records & Concepts
What is an NS record?
An NS record, Nameserver record, is a DNS record that specifies which nameservers are authoritative for a domain. It is the record that tells the global DNS system where to find the definitive DNS information for a domain, which servers hold the actual A records, CNAME records, MX records, TXT records, and all other DNS records for that domain.
NS records are the delegation mechanism of DNS. They answer the question “who is in charge of DNS for this domain?” The answer, the authoritative nameservers specified in the NS records, is where all DNS lookups for the domain ultimately end up. When a DNS resolver needs to look up any record for example.com it finds the NS records for example.com, identifies the authoritative nameservers, and queries those servers directly for the specific record it needs.
Without NS records the DNS system has no way to locate the authoritative source of information for a domain. Every DNS lookup for the domain would fail. NS records are not optional, every domain must have them. They are created automatically when a domain is registered and updated whenever DNS authority is transferred to a different provider.
How NS records work
NS records are the foundation of the DNS delegation hierarchy. Understanding how they work requires understanding the layered structure of DNS and how authority is passed down from the root to individual domains.
When a DNS resolver needs to look up a record for example.com and has no cached information it begins at the top of the DNS hierarchy, the root nameservers. The root nameservers do not hold records for individual domains. They hold NS records for every TLD: .com, .net, .org, and hundreds of others. They point the resolver to the TLD nameservers.
The resolver queries the .com TLD nameservers. The TLD nameservers hold NS records for every .com domain registered in the .com zone. They return the NS records for example.com: the specific nameservers that are authoritative for that domain, and point the resolver there.
The resolver queries one of the authoritative nameservers for example.com. This server holds all the actual DNS records for the domain, A records, CNAME records, MX records, TXT records, and others. It returns the specific record the resolver requested.
The NS records at the TLD level, stored in the .com zone, were created when example.com was registered. The domain registrar submitted the nameserver information to the TLD registry during registration. Every time NS records change, when DNS authority is transferred to a new provider, the registrar updates this information at the TLD registry.
NS record format and values
NS records have a simple format. The name is the domain they apply to. The value is the hostname of an authoritative nameserver.
These two records say that ns1.registrar.com and ns2.registrar.com are authoritative nameservers for example.com. All DNS lookups for example.com and its subdomains query these nameservers.
Every domain has at least two NS records, typically more, to provide redundancy. If one nameserver is unreachable resolvers try another. DNS providers typically operate multiple nameservers across different geographic locations and network providers to ensure authoritative DNS responses are always available regardless of regional outages.
NS record values must be hostnames, domain names that themselves resolve to IP addresses. They cannot be IP addresses directly. The IP addresses of nameservers are typically published as glue records, A records for the nameserver hostnames stored at the parent zone alongside the NS records. Glue records are necessary when the nameserver’s hostname is within the same domain it is authoritative for, without glue records the resolver would have a circular dependency trying to look up the nameserver’s IP address.
NS records and domain registrars
NS records sit at the intersection of two systems, the DNS system that uses them for resolution and the domain registration system that creates and maintains them.
When a domain is registered the registrar creates NS records pointing to nameservers where the domain’s DNS will be managed. By default this is typically the registrar’s own nameservers, the domain is registered and DNS is hosted in the same place.
The registrar stores two copies of the NS records. One copy lives in the domain’s own DNS zone, the NS records visible when querying the authoritative nameservers for the domain. The other copy, the delegation records, lives at the TLD registry and is what the TLD nameservers return when resolvers ask where to find example.com. Both copies must match for DNS resolution to work correctly.
When a domain owner wants to move DNS to a different provider, Cloudflare, Route 53, or a custom DNS solution, they update the NS records through their registrar’s control panel. The registrar updates the delegation records at the TLD registry. The new DNS provider’s nameservers become authoritative. All DNS lookups for the domain begin querying the new nameservers.
This process, changing nameservers, is one of the most impactful DNS changes possible because it changes where all DNS records for the domain are managed. Every A record, CNAME record, MX record, and TXT record must be correctly configured at the new provider before the nameserver change is made, or all of those services break when the new nameservers take over.
NS records and DNS propagation
Changing NS records involves a DNS propagation process that is typically slower and more complex than changing individual records like A records or CNAME records.
When NS records change the update must propagate through multiple layers of the DNS hierarchy, from the TLD registry to TLD nameservers to resolvers worldwide. The TTL on NS records at the TLD level is set by the TLD registry and is typically 172800 seconds, 48 hours. This means resolvers that have cached the old NS records may continue querying the old nameservers for up to 48 hours after the change.
During propagation some visitors, those using resolvers with cached old NS records, receive DNS answers from the old nameservers while others receive answers from the new nameservers. This split-brain state during propagation is why preparing both old and new nameservers to serve the same records during the transition window is important.
In practice propagation often completes faster than the maximum TTL, many resolvers have shorter cache times or are configured to check more frequently, but planning for up to 48 hours of propagation time for nameserver changes is prudent.
NS records and redirect management
NS records interact with redirect management in several important ways that anyone managing domain redirects should understand.
Nameserver changes for redirect infrastructure: some redirect management approaches involve changing the domain’s nameservers entirely, moving DNS to a provider like Cloudflare that provides both DNS management and redirect capabilities. When nameservers are changed all DNS records must be present at the new provider before the change is made. Missing records, particularly MX records for email delivery, cause service disruptions during the transition.
NS records survive redirect rule changes: NS records are not affected by changes to redirect rules, A records, or CNAME records. Connecting a domain to redirect management infrastructure by updating A or CNAME records does not change NS records. The domain’s nameservers remain the same, only the specific records within the zone change.
Subdomain delegation: NS records can delegate authority for a specific subdomain to different nameservers than those authoritative for the parent domain. shop.example.com NS ns1.shopplatform.com delegates DNS authority for the shop subdomain to the shopping platform’s nameservers. This allows different parts of a domain to be managed by different DNS providers, the root domain at one provider, a subdomain at another.
Subdomain delegation is relevant in redirect management when a specific subdomain needs to be managed by a different service than the parent domain. The NS records for the subdomain point to the service’s nameservers while the parent domain’s NS records remain unchanged.
Verifying NS records during setup: when troubleshooting why a domain is not connecting to redirect infrastructure correctly verifying that NS records are pointing to the expected nameservers is an important diagnostic step. If NS records are pointing to old nameservers from a previous provider that still exists but has outdated A or CNAME records the redirect rules may not be applied correctly even after the DNS records appear to be updated, because the records are being updated at a provider whose nameservers are no longer being queried.
Checking NS records
NS records are checked using the same DNS query tools as other record types.
dig command: on Linux and macOS:
Returns the NS records for example.com showing the authoritative nameserver hostnames. Adding +short returns just the nameserver hostnames:
Checking the TLD delegation: to see the NS records as stored at the TLD registry rather than the domain’s own authoritative nameservers query the TLD nameservers directly:
This bypasses the domain’s own nameservers and shows what the TLD registry currently has on file. Useful for verifying that a nameserver change has propagated to the TLD level.
nslookup: on Windows and other platforms:
Verifying nameserver consistency: NS records should be consistent between the domain’s own zone and the TLD registry delegation. Checking both confirms the delegation is correctly set up and there are no discrepancies between the zone NS records and the registry delegation that could cause resolution problems.
Online tools: web-based DNS analysis tools show NS records and often check for common issues, nameservers returning inconsistent answers, nameservers unreachable from certain locations, NS records not matching the TLD delegation, and missing glue records for in-zone nameservers.
Common NS record issues
NS records not matching at TLD and zone level: the NS records stored in the domain’s own DNS zone should match the delegation NS records stored at the TLD registry. Mismatches can cause resolution failures or inconsistent behaviour where some resolvers find different answers. This typically occurs after a nameserver change where one set of records was updated but not the other.
Too few nameservers: having only one NS record creates a single point of failure. If the single nameserver is unreachable DNS resolution for the entire domain fails. Best practice is at least two nameservers from different providers or network locations. Most DNS providers supply two or more nameservers by default.
Old nameservers still receiving queries: after a nameserver change old nameservers continue receiving queries from resolvers with cached NS records during the propagation window. If the old nameservers are decommissioned immediately after the change resolvers still pointing to them receive errors. Keep old nameservers active and serving correct records until propagation is complete.
Missing records at new nameservers: the most disruptive nameserver change mistake. Moving DNS to a new provider without recreating all existing records, particularly MX records for email and A records for web services, at the new provider causes those services to break immediately when resolvers start querying the new nameservers. Always audit and recreate all records before changing nameservers.
Nameserver hostnames without glue records: when a domain uses nameservers whose hostnames are within the same domain, ns1.example.com as a nameserver for example.com: glue records are required. Without glue records resolvers face a circular dependency trying to look up ns1.example.com to query the nameserver for example.com. The registrar must be informed of the glue records, the IP addresses of the in-zone nameservers, when this configuration is used.
TTL too low on NS records: very low TTLs on NS records cause resolvers to recheck authoritative nameservers frequently, increasing query load on both the resolvers and the nameservers. NS records change rarely, a TTL of 86400 or higher is appropriate for stable configurations.