NS Name Server Flagship
Delegates a domain or subdomain to a set of authoritative nameservers.
What it's for
An NS (Name Server) record declares which nameservers are authoritative for a domain — in other words, which servers hold the real, canonical DNS records and should be asked when someone needs to resolve anything under that domain. NS records are the mechanism behind DNS delegation: the entire hierarchical structure of DNS, from the root down to .com down to example.com, works by each level pointing (via NS records) to the servers responsible for the level below it.
When you sign up with a DNS provider (Cloudflare, Route 53, your registrar's default DNS), what you're really doing is telling the domain registry "these are my NS records" — that's the pointer that makes the whole rest of your DNS configuration reachable at all.
Format & syntax
example.com. 86400 IN NS ns1.provider.com.
example.com. 86400 IN NS ns2.provider.com.
- Name — the domain or subdomain being delegated
- TTL — typically long (24 hours / 86400 seconds is common) since nameserver assignments rarely change
- Class —
IN - Type —
NS - Value — the hostname of an authoritative nameserver. Domains almost always have at least two NS records for redundancy, often more.
NS records exist at two levels for any domain: at the registry/parent level (what your registrar tells the .com TLD servers), and inside your own zone file (what your DNS provider serves when asked). These need to match — a mismatch is a real and surprisingly common source of "my DNS changes aren't propagating" issues.
How it's used in practice
- Choosing a DNS provider — updating your domain's NS records at the registrar is literally how you switch DNS providers (e.g., moving from your registrar's default DNS to Cloudflare).
- Subdomain delegation — NS records can delegate a specific subdomain to a completely different set of nameservers than the rest of the domain, useful for splitting management of a subdomain (e.g., a subdomain used by a separate team or a third-party service that needs full DNS control over it).
- Redundancy — every domain should have multiple NS records pointing at genuinely independent nameservers (different networks/providers if possible) so a single nameserver outage doesn't take the whole domain offline.
- Glue records — when a domain's nameservers are themselves subdomains of that same domain (e.g.,
ns1.example.comas a nameserver forexample.com), the registry needs to publish "glue records" — the actual IP addresses of those nameservers — directly at the parent level, because otherwise resolving the nameserver's address would require... asking the nameserver, a chicken-and-egg problem.
Common mistakes & gotchas
- Registrar and zone NS records out of sync — if you change DNS providers, you must update NS records at the registrar level. Forgetting this means the registry keeps pointing resolvers at your old provider, and changes made at your new provider are invisible to the internet no matter how correct they are.
- Too few nameservers or all on one network — using only one NS record, or several that are all hosted by the same underlying network, defeats the redundancy NS records are supposed to provide.
- Forgetting glue records for in-domain nameservers — if your nameservers are subdomains of the domain they serve, missing glue records at the registry can cause resolution to fail entirely for that domain, since resolvers can't find the nameserver's IP without first resolving the nameserver's name — which requires the nameserver.
- Long NS TTLs slowing down provider migrations — NS record TTLs are often set quite high by registries by default; when switching DNS providers, be aware the cutover isn't instant and some resolvers may keep querying the old provider until the previous TTL expires.
- Confusing NS with the general "who owns this domain" question — NS records control DNS resolution authority, not domain ownership or registration — that's a separate concern handled by the registrar/registrant record (WHOIS), unrelated to NS.
Comparison & FAQ
| Type | Purpose | Key difference from NS |
|---|---|---|
| SOA | Metadata about the zone (serial number, refresh timers, admin contact) | One SOA per zone describing the zone itself; NS lists the servers that host it |
| CNAME | Aliases one name to another within the same resolution chain | Doesn't delegate authority — it just points, it doesn't hand off control of a namespace |
| A / AAAA | Address records for nameservers themselves | What an NS record's target hostname ultimately needs to resolve to (often via glue records) |
How do I change my domain's DNS provider?
Update the NS records for your domain at your domain registrar (not inside the old provider's dashboard) to point at your new provider's nameservers. This is the actual mechanism of a DNS provider migration.
What's the difference between NS records at the registrar and NS records in my zone file?
The registrar-level NS records tell the parent TLD servers who's authoritative for your domain. The NS records inside your own zone file (served by your actual DNS provider) should match — a mismatch means some resolvers get directed to the wrong provider and see stale or missing records.
What are glue records and when do I need them?
Glue records are IP addresses for nameservers published directly at the parent/registry level, needed when a domain's nameservers are themselves subdomains of that same domain (e.g. ns1.example.com). Without them, resolving the nameserver's address becomes circular.
Why is my new DNS provider's records not showing up after I switched?
Most likely the NS records at your registrar still point to your old provider, or the previous NS record's TTL hasn't expired yet in caching resolvers. Confirm the registrar-level NS records were actually updated, not just the records inside your new provider's dashboard.