What Is a Name Server and How Does It Resolve Domain Names?
A name server is a server that answers DNS queries — it translates domain names into the records (IP addresses, mail targets, and so on) that other systems need. There are two roles to keep separate: authoritative name servers hold the definitive records for a zone and answer queries about it, while recursive resolvers do the legwork of looking those records up on a client's behalf. You point a domain at authoritative name servers via NS records at your registrar; you (or your ISP) point clients at recursive resolvers. If you only remember one thing: the NS records in your registrar's panel decide who is authoritative for your domain, and nothing else will resolve correctly until those are right.
The two kinds of name server
| Authoritative name server | Recursive resolver | |
|---|---|---|
| Holds | The actual zone data for specific domains | A cache of answers it has looked up |
| Answers | Queries for zones it is configured for | Queries from clients (browsers, apps, OS) |
| Typical software | NSD, BIND, Knot | Unbound, BIND, dnsmasq |
| Who runs it | Domain owner or DNS host | ISP, network admin, or public resolver |
| If it fails | Your domain stops resolving | That client's lookups fail or slow down |
NLnet Labs, a nonprofit foundation focused on DNS and routing, maintains examples of both: NSD, described as a "fast and robust authoritative DNS nameserver," and Unbound, a "lean and versatile recursive DNS resolver." Both are open source, so you can run either yourself or rely on a hosting provider that does.
How a lookup actually flows
- A client asks its configured recursive resolver for
www.example.com. - If the resolver has no cached answer, it asks the root servers.
- The root refers it to the TLD servers for
.com. - The TLD servers return the NS records for
example.com— the delegation. - The resolver queries one of those authoritative name servers directly.
- The authoritative server returns the record (for example, an A record), and the resolver caches it and hands it back to the client.
The NS records are the handoff points. They don't contain the website's IP address; they name the servers that do.
Pointing a domain at name servers
At your registrar (or DNS provider), you set the name servers for the domain, usually as a pair or set for redundancy:
ns1.yourprovider.netns2.yourprovider.net
Two conditions must both hold:
- The registrar's NS records must list the servers you intend to use.
- Those servers must actually be configured to serve your zone.
If only one is true, resolution breaks. A common mistake is changing the registrar's NS records to a new provider before the zone exists on the new provider's servers — the result is a domain that stops resolving entirely.
Checking name servers and verifying they respond
Look up the delegation:
dig NS example.com +short
Expected output is a list of hostnames, e.g. ns1.example.com. and ns2.example.com.. To confirm a specific server is authoritative and answering:
dig @ns1.example.com example.com SOA +short
A returned SOA record means that server is serving the zone. A timeout or REFUSED means it is not — check the server's configuration or whether you queried the right hostname.
To see the full path a resolver takes, including delegation:
dig +trace example.com
Common failure symptoms
- NXDOMAIN — the name does not exist. Often a typo, or a record missing from the zone on the authoritative server.
- SERVFAIL — the resolver could not get a usable answer. Frequently caused by broken delegation, an unreachable authoritative server, or DNSSEC validation failing.
- Timeout / no response — the authoritative server is down, firewalled, or not listening on port 53.
- Stale answers after a change — the old record is still cached. This is the "propagation delay" people refer to; it is really cache expiry, bounded by the record's TTL.
- Works for some people, not others — usually inconsistent NS records across the parent zone, or one of several authoritative servers misconfigured.
Choosing between running your own and using a host
- Run your own authoritative server (for example, NSD) if you need full control over zone data, want to avoid a third party in the resolution path, or are operating infrastructure where you already manage DNS.
- Use a DNS hosting provider if you want managed redundancy and don't want to operate servers — you still set NS records at your registrar, but the provider runs the authoritative side.
- Run your own recursive resolver (for example, Unbound) if you want to control caching, filtering, or privacy for a network you manage. Most end users should simply use the resolver their OS or network provides.
The deciding factor is operational responsibility: authoritative servers are part of your domain's availability, so whoever runs them owns a piece of your uptime.