DNS Records & Concepts
What is a nameserver?
A nameserver is a server that stores DNS records and responds to queries about those records from other servers and clients on the internet. It is the infrastructure layer that makes DNS work, the servers that hold the mappings between domain names and IP addresses and serve those mappings in response to lookup requests.
When a browser needs to find the IP address for example.com it sends a DNS query to a nameserver. The nameserver either has the answer, because it is authoritative for the domain or has a cached copy of the record, or it knows where to find it and either redirects the query there or performs the lookup on the client’s behalf. The entire DNS resolution process, from typing a domain name to establishing a connection with the correct server, depends on nameservers at every step.
Nameservers are the distributed infrastructure that makes the domain name system possible at global scale. There are tens of thousands of authoritative nameservers worldwide holding the definitive records for every registered domain. There are millions of recursive resolvers, also called recursive nameservers, that perform DNS lookups on behalf of internet users. Together these two types of nameserver handle billions of DNS queries every day, invisibly and instantly translating domain names into the IP addresses that power internet connectivity.
Types of nameservers
Nameservers fall into two fundamental categories, authoritative nameservers and recursive resolvers. Understanding the distinction is essential for understanding how DNS resolution works and how nameservers interact during a lookup.
Authoritative nameservers: servers that hold the definitive, current DNS records for specific DNS zones. When a resolver needs to know the A record for example.com it ultimately reaches the authoritative nameserver for the example.com zone, the server that holds the zone file containing the actual records. The authoritative nameserver answers with the definitive answer, not a cached copy, not an approximation, but the current authoritative value directly from the zone data.
Authoritative nameservers are operated by DNS providers, domain registrars, cloud platforms, and organisations that run their own DNS infrastructure. When a domain is registered the registrar assigns it to a set of authoritative nameservers, typically the registrar’s own nameservers or a DNS provider the domain owner has chosen. The NS records for a domain specify which servers are authoritative.
Recursive resolvers: servers that perform DNS lookups on behalf of clients. When a browser needs to resolve example.com it sends the query to a recursive resolver, typically one provided by the internet service provider or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. The resolver performs the full resolution process, querying root nameservers, TLD nameservers, and authoritative nameservers, to find the answer. It caches the result for the DNS TTL duration and serves it to subsequent queries without repeating the full lookup.
Recursive resolvers are also called recursive nameservers, full-service resolvers, or simply DNS resolvers. They are the nameservers that end users interact with, their devices are configured with resolver addresses rather than authoritative nameserver addresses.
The DNS resolution process and nameservers
The DNS resolution process involves multiple nameservers working together in a hierarchy to translate a domain name into an IP address. Tracing a full resolution shows how each type of nameserver participates.
A user types example.com into their browser. The browser checks its local cache, no result. It queries the operating system DNS cache, no result. It sends the query to the configured recursive resolver at 8.8.8.8.
The recursive resolver checks its cache, no result. It begins the iterative resolution process.
Root nameservers: the resolver queries one of the 13 root nameserver clusters. Root nameservers are the authoritative nameservers for the DNS root zone, the very top of the DNS hierarchy. There are 13 root nameserver addresses, labeled a.root-servers.net through m.root-servers.net: though each address is served by hundreds of servers worldwide using anycast routing. The root nameserver does not know the IP address for example.com but it knows which nameservers are authoritative for .com: the TLD. It returns a referral to the TLD nameservers.
TLD nameservers: the resolver queries the .com TLD nameservers, operated by Verisign for the .com TLD. The TLD nameserver holds the NS records for every .com domain, the delegation records that specify which nameservers are authoritative for each domain. It returns the NS records for example.com: the specific authoritative nameservers for that domain.
Authoritative nameservers: the resolver queries one of the authoritative nameservers for example.com: the servers specified in the NS records returned by the TLD nameserver. The authoritative nameserver holds the zone data for example.com. It returns the A record: the IP address, for example.com.
Response to client: the resolver receives the IP address, caches it for the TTL duration, and returns it to the browser. The browser connects to the IP address and the page loads.
The entire process, from the browser’s query to the IP address being returned, typically takes 20 to 100 milliseconds for a cold lookup with no cached data. Subsequent lookups served from resolver caches take microseconds.
Authoritative nameserver architecture
Authoritative nameservers serve definitive DNS data for the zones they are responsible for. Their architecture and operation directly affects the reliability, speed, and correctness of DNS for the domains they serve.
Primary and secondary nameservers: in traditional DNS architecture a primary nameserver holds the master copy of the zone data and secondary nameservers hold copies received through zone transfers. Changes are made on the primary and propagated to secondaries. The distinction between primary and secondary is an operational one, both serve authoritative answers to queries. Secondary nameservers provide redundancy, if the primary is unreachable queries go to secondaries.
Anycast nameservers: modern DNS providers use anycast routing, the same IP address is announced from multiple geographic locations simultaneously. Queries are automatically routed to the nearest location based on network topology. A query from Europe reaches a European nameserver. A query from Asia reaches an Asian nameserver. Anycast provides both geographic distribution for low-latency responses and resilience, if one location becomes unavailable traffic automatically routes to the next nearest.
Cloudflare, Route 53, Google Cloud DNS, and other major managed DNS providers all use anycast architectures. Their nameservers respond from dozens or hundreds of global locations simultaneously using the same nameserver hostnames.
Hidden primary nameservers: some organisations use a hidden primary architecture where the master copy of zone data is on a server not listed in public NS records. The hidden primary is not reachable from the public internet, it transfers zone data to secondary nameservers that are publicly listed. This protects the primary from direct attack while maintaining a single authoritative source for zone updates.
Recursive resolvers
Recursive resolvers, the nameservers that end users and devices communicate with directly, perform the iterative resolution process on behalf of clients and cache results to avoid repeating full lookups for every query.
ISP resolvers: internet service providers operate recursive resolvers for their customers. Devices obtain resolver addresses automatically through DHCP when connecting to the network. ISP resolvers handle DNS for all devices on the network.
Public resolvers: several public recursive resolver services are freely available for anyone to use by configuring devices or routers to use their IP addresses.
Google Public DNS, 8.8.8.8 and 8.8.4.4: one of the most widely used public resolvers. Fast global response times using anycast infrastructure.
Cloudflare DNS, 1.1.1.1 and 1.0.0.1: known for very fast response times and privacy focus. Cloudflare does not log query data beyond 24 hours.
Quad9, 9.9.9.9: provides security filtering blocking known malicious domains in addition to standard DNS resolution.
OpenDNS, 208.67.222.222 and 208.67.220.220: offers optional content filtering and parental controls alongside standard resolution.
Corporate and enterprise resolvers: organisations run their own recursive resolvers within their networks for security control, filtering malicious domains, enforcing content policies, logging DNS queries for security analysis, and resolving internal domain names not published on the public internet.
DNS-over-HTTPS and DNS-over-TLS resolvers: traditional DNS queries are sent in plaintext, visible to anyone on the network path between the client and resolver. DNS-over-HTTPS and DNS-over-TLS encrypt DNS queries preventing eavesdropping. Major resolvers including Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 support encrypted DNS. Modern browsers can be configured to use DNS-over-HTTPS directly.
Nameservers and domain registration
Every registered domain is associated with a set of authoritative nameservers specified at the domain registrar. The registrar stores these nameserver addresses and submits them to the TLD registry, the operator of the .com, .net, or other TLD zone. The TLD registry publishes NS records in the TLD zone delegating DNS authority for the domain to the specified nameservers.
When a domain is registered the registrar typically assigns it to the registrar’s own nameservers by default. The domain owner can change nameservers at any time through the registrar’s control panel, pointing the domain to a different DNS provider’s nameservers.
Changing nameservers at the registrar is the most impactful DNS change possible because it transfers authority for the entire DNS zone to different infrastructure. All DNS records for the domain must exist on the new nameservers before the change is made, otherwise DNS queries fail for records that have not been recreated.
The nameserver change process involves:
Choosing a new DNS provider and creating the domain’s zone there, adding all existing DNS records.
Identifying the new provider’s nameserver hostnames, typically two or more nameservers like ns1.provider.com and ns2.provider.com.
Updating the nameserver settings at the registrar, replacing the current nameservers with the new provider’s nameservers.
Waiting for DNS propagation: the TLD nameservers cache NS delegation records for an extended period, typically 48 hours for .com domains. During propagation some resolvers continue querying the old nameservers while others have switched to the new ones.
Nameservers and redirect management
Nameservers interact with redirect management at several levels, from the basic DNS changes needed to connect a domain to redirect infrastructure to more advanced configurations involving zone delegation.
Pointing domains to redirect infrastructure via DNS: connecting a domain to redirect management infrastructure requires changes to DNS records in the domain’s zone, typically adding CNAME records for subdomains or A records for root domains pointing to the redirect service’s infrastructure. These changes are made through whatever interface manages the domain’s DNS zone, the registrar’s DNS management or a separate DNS provider’s control panel.
Changing nameservers for redirect-capable DNS providers: some redirect management approaches involve moving DNS to a provider that offers redirect capabilities at the DNS layer, Cloudflare being the most prominent example. Changing nameservers to Cloudflare gives access to Cloudflare’s redirect rules, page rules, and Workers in addition to standard DNS. The nameserver change transfers zone authority to Cloudflare which then manages both DNS and redirect logic.
Nameserver-level redirect limitations: DNS nameservers operate at the network routing layer, they resolve domain names to IP addresses. They cannot issue HTTP redirect responses: the 3xx status codes and Location headers that browsers follow. DNS cannot perform URL redirects directly. A DNS change routes requests to a server or service, the HTTP redirect must be implemented at that server or service level.
Some people attempt to redirect domains purely through DNS, changing A records or CNAME records to point to the destination domain, expecting this to act as a redirect. It does not. A DNS change routes requests to a different server but does not change what URL the browser requests or what the browser displays in the address bar. A proper HTTP redirect requires server-side redirect rules in addition to the DNS routing.
Checking nameservers
Nameserver information for a domain can be checked through several tools.
dig command: on Linux and macOS:
Returns the NS records specifying the authoritative nameservers for example.com. Adding +short returns just the nameserver hostnames:
Checking TLD delegation: to see the nameserver delegation as stored at the TLD registry query the TLD nameservers directly:
This bypasses the authoritative nameservers entirely and shows what the TLD registry has on file, useful for verifying that a nameserver change has propagated to the TLD level.
nslookup: on Windows and other platforms:
WHOIS lookup: WHOIS records for a domain typically include the registered nameservers alongside other registration information. WHOIS tools show the nameservers as stored at the registrar level, the same information submitted to the TLD registry.
Online tools: web-based DNS tools check nameservers from multiple geographic locations simultaneously, useful for verifying that a nameserver change has propagated globally. Checking from multiple locations confirms all resolvers worldwide are seeing the new nameservers rather than the old ones.
Common nameserver issues
Nameservers not matching between registrar and zone: the nameservers listed at the registrar must match the NS records in the zone. Mismatches cause resolution failures or inconsistent behaviour. After changing nameservers verify that both the registrar and the new provider show the same nameserver hostnames.
Missing records after nameserver change: changing nameservers without recreating all existing DNS records at the new provider. Records not present at the new provider, particularly MX records for email delivery, stop working immediately when the new nameservers take over. Always audit and recreate all records before changing nameservers.
Only one nameserver: having a single authoritative nameserver creates a single point of failure. If that nameserver is unreachable DNS resolution fails for the entire domain. All domains should have at least two nameservers from different network locations.
Nameserver hostnames not resolving: an NS record pointing to a nameserver hostname that has no A record: or an incorrect A record, causes resolution failures. Resolvers cannot query a nameserver they cannot connect to. Verify nameserver hostnames resolve correctly after configuration.
Slow nameserver response times: authoritative nameservers that respond slowly add latency to DNS resolution for every visitor. Using a managed DNS provider with anycast infrastructure minimises response times by serving queries from geographically distributed locations close to the resolver.