Two Very Different Roles in DNS
The DNS system involves many types of servers, but two are most commonly confused: the recursive resolver and the authoritative nameserver. They serve opposite roles in the lookup process. The recursive resolver is a client-side agent — it exists to find answers on your behalf. The authoritative nameserver is a server-side authority — it holds the definitive records for a specific domain and answers queries about it with finality.
Confusing the two leads to misunderstandings about what you can change on your own device versus what is controlled by domain owners. When you switch your DNS to 8.8.8.8 or 1.1.1.1, you are changing your resolver — not any authoritative nameserver. The IP addresses that websites resolve to remain completely unaffected by your resolver choice.
What a Recursive Resolver Does
A recursive resolver (also called a full-service resolver or recursive nameserver) is the DNS server your device sends queries to. It receives your question — "What is the IP address of www.example.com?" — and takes on the responsibility of finding the answer by navigating the DNS hierarchy. It queries root nameservers, TLD nameservers, and finally the authoritative nameserver for the domain in question, assembles the answer, caches it for future use, and returns it to you.
The recursive resolver maintains a large shared cache across all users who use it. When Cloudflare's 1.1.1.1 has already resolved a popular domain for another user moments ago, your query for the same domain hits the cache and returns instantly. This shared caching is one reason large public resolvers deliver fast responses — they see enormous query volume, keeping their caches warm for nearly every popular domain.
Your ISP assigns you a recursive resolver by default via DHCP. You can override this in your router, operating system, or individual device settings to use any public resolver. Common choices include Cloudflare (1.1.1.1 / 1.0.0.1), Google (8.8.8.8 / 8.8.4.4), and Quad9 (9.9.9.9 / 149.112.112.112).
What an Authoritative Nameserver Does
An authoritative nameserver holds the actual DNS zone data for specific domains. When queried about a domain it is authoritative for, it returns a definitive answer marked with the AA (Authoritative Answer) flag in the DNS response. It does not guess, forward, or cache — it is the source of truth.
The domain owner controls which nameservers are authoritative for their domain by setting NS records at their registrar. The registrar publishes those NS records in the TLD zone, so that any recursive resolver navigating the hierarchy can find which servers to ask for that domain's records. The authoritative nameserver is typically operated by a DNS hosting provider (Cloudflare DNS, AWS Route 53, Google Cloud DNS), a CDN, or the organization's own infrastructure.
Authoritative nameservers do not perform recursive lookups. If queried about a domain they are not authoritative for, they return a REFUSED or SERVFAIL response rather than going off to find the answer. This separation of roles — resolvers ask, authoritative servers answer — is fundamental to how DNS scales.
How Registrar NS Records Link Everything Together
The connection between a domain and its authoritative nameservers is established through NS records at the registrar. When you register example.com through a registrar and set your nameservers to ns1.dnsprovider.com and ns2.dnsprovider.com, the registrar submits those NS records to Verisign (the .com registry operator), which publishes them in the .com TLD zone.
When a recursive resolver needs to resolve www.example.com, it queries the .com TLD nameserver and receives a referral: "Ask ns1.dnsprovider.com or ns2.dnsprovider.com." The resolver then queries one of those nameservers, which — being authoritative for example.com — returns the actual A record.
Glue Records and the Circular Dependency Problem
A subtle problem arises when a domain's authoritative nameserver is within the same domain it serves. If example.com uses ns1.example.com as its nameserver, a resolver cannot find ns1.example.com's IP address without querying the authoritative server for example.com — which it cannot reach without knowing ns1.example.com's IP address first. This is a circular dependency.
Glue records solve this. The registrar publishes the IP address of ns1.example.com directly in the parent TLD zone, outside of example.com's own zone data. The resolver receives both the NS referral and the IP address in the same TLD response, breaking the circularity. Glue records are required whenever a nameserver hostname falls within the domain it serves.
Primary vs Secondary Nameservers
Most domains publish multiple NS records pointing to multiple authoritative nameservers. One is typically designated the primary (master) and the others are secondary (slave) nameservers. The primary holds the writable copy of the zone data. Secondary nameservers synchronize their copies from the primary through zone transfers — either a full transfer (AXFR) or an incremental transfer (IXFR) that sends only changed records.
From a resolver's perspective, primary and secondary nameservers are equivalent — both are authoritative and both can answer queries. The distinction matters only for zone management. ICANN requires at least two NS records per domain to ensure that a single server failure does not make a domain unresolvable. Managed DNS providers routinely operate four or more globally distributed nameservers per zone.
How CDNs Use Authoritative DNS for GeoDNS
Content delivery networks exploit the authoritative nameserver layer to route users to geographically nearby servers. When a recursive resolver queries a CDN's authoritative nameserver for www.example.com, the CDN's nameserver examines the resolver's IP address to estimate the user's geographic region and returns a different A record depending on that location — for example, a data center IP in Frankfurt for European resolvers and a Los Angeles IP for US West Coast resolvers.
This technique — called GeoDNS or Anycast DNS routing — is why the same domain resolves to different IP addresses in different countries. Because the routing decision happens at the authoritative nameserver level, your choice of recursive resolver does not affect which CDN node you reach. What matters is where the authoritative nameserver thinks your resolver is located.
Recursive Resolver vs Authoritative Nameserver Compared
| Property | Recursive Resolver | Authoritative Nameserver |
|---|---|---|
| Who controls it | ISP or public DNS provider (user can choose) | Domain owner / DNS hosting provider |
| What it stores | Cached answers for any domain it has resolved | Zone records for specific domains it serves |
| Caching TTL | Respects record TTL; shared across all users | Does not cache; is the authoritative source |
| Example operators | Cloudflare, Google, Quad9, your ISP | Cloudflare DNS, AWS Route 53, self-hosted BIND |
| Can you change it? | Yes — in router, OS, or device settings | Only if you own the domain |
Frequently Asked Questions
What happens when I change my DNS server to 8.8.8.8?
When you change your DNS server to 8.8.8.8, you are switching your recursive resolver from your ISP's server to Google Public DNS. Your device now sends all DNS queries to Google's resolver instead of your ISP's. Google's resolver then navigates the DNS hierarchy on your behalf and returns answers. The authoritative nameservers for every domain remain completely unchanged — you have only changed who is doing the asking, not who holds the answers.
Who controls the authoritative nameserver for a domain?
The domain owner controls which authoritative nameservers are used for their domain. They set this by configuring nameserver (NS) records at their domain registrar. The registrar then publishes those NS records in the TLD nameserver for the relevant top-level domain. The authoritative nameserver itself is typically operated by a DNS hosting provider, CDN, or the domain owner's own infrastructure — whoever the owner has chosen to host their DNS zone.
Can I run my own authoritative nameserver?
Yes. Running your own authoritative nameserver requires DNS server software (such as BIND, NSD, or PowerDNS), a publicly reachable IP address, and NS records at your registrar pointing to your server. Most domain owners delegate to a managed DNS provider instead because authoritative nameservers must be highly available — any downtime means the domain becomes unresolvable for visitors whose cached records have expired.
What are glue records in DNS?
Glue records are A records that provide the IP address of a nameserver when that nameserver's hostname is within the same domain it is authoritative for. For example, if example.com uses ns1.example.com as its nameserver, the TLD server cannot resolve ns1.example.com without already knowing example.com's nameserver — a circular dependency. The registrar breaks this loop by publishing the IP address of ns1.example.com directly in the TLD zone as a glue record, outside of example.com's own zone.
What is a secondary nameserver?
A secondary nameserver is an additional authoritative nameserver that holds a read-only copy of a zone's DNS records, synchronized from the primary nameserver via a process called zone transfer (AXFR or IXFR). Secondary nameservers provide redundancy: if the primary is unreachable, the secondary continues to answer queries. ICANN requires at least two authoritative nameservers for every registered domain. Most managed DNS providers operate many nameservers globally to provide both redundancy and low-latency resolution worldwide.
Why do some domains have multiple NS records?
Multiple NS records provide redundancy and geographic distribution. If one authoritative nameserver is unreachable, resolvers automatically try the others listed in the NS record set. Multiple nameservers also allow DNS providers to place servers in different regions so that resolvers worldwide each reach a nearby instance, reducing authoritative lookup latency. ICANN's registry policies require at least two nameservers per domain for this reason.