DNS Records & Concepts
What is a DNS resolver?
A DNS resolver is a server that performs DNS lookups on behalf of browsers, applications, and other networked clients. When a browser needs to translate a domain name into an IP address it sends a query to a DNS resolver. The resolver does the work of finding the answer, querying root nameservers, TLD nameservers, and authoritative nameservers in sequence, and returns the result to the browser.
The resolver is the client-facing component of the DNS infrastructure, the server that end users and their devices interact with directly for DNS resolution. It sits between the client, the browser or application, and the authoritative nameservers that hold the actual DNS records. The resolver handles the complexity of the full DNS resolution process transparently, presenting a simple interface, send a domain name, receive an IP address, to the clients it serves.
DNS resolvers are also called recursive resolvers, recursive nameservers, or full-service resolvers. The word recursive reflects how they work, they recursively query the DNS hierarchy, root nameservers, then TLD nameservers, then authoritative nameservers, until they find the answer. This recursive process is what distinguishes them from authoritative nameservers which only answer queries about the specific zones they hold.
How a DNS resolver works
When a browser sends a DNS query to a resolver the resolver follows a specific process to find the answer, either from its cache or through the full recursive resolution sequence.
Cache check: the resolver first checks its local cache. If it recently resolved the same domain and the cached result has not expired it returns the cached IP address immediately. The cache hit rate for popular resolvers is very high, most queries for common domains are served from cache without any external queries.
Root nameserver query: if the resolver has no cached result it queries a root nameserver. The resolver maintains a built-in list of root nameserver addresses, the hints file, that it uses to bootstrap resolution. Root nameservers do not have specific domain records but they hold NS records for every TLD, telling the resolver which nameservers are authoritative for .com, .net, .org, and every other extension.
TLD nameserver query: the resolver queries the TLD nameserver returned by the root. The TLD nameserver holds delegation records, NS records, for every domain registered under that TLD. It returns the NS records for the specific domain being looked up, the authoritative nameservers for that domain.
Authoritative nameserver query: the resolver queries one of the authoritative nameservers returned by the TLD. The authoritative nameserver holds the zone data, the actual DNS records configured by the domain owner. It returns the requested record, A record, CNAME record, MX record, or any other type, along with its TTL value.
Caching and response: the resolver caches the response for the TTL duration and returns the result to the browser. Future queries for the same record within the TTL period are served from cache without repeating the full resolution sequence.
The full recursive resolution process, steps 2 through 5, typically completes in 20 to 100 milliseconds for a cold lookup. Most lookups are served from cache in microseconds.
Types of DNS resolvers
DNS resolvers come in several forms, each serving different audiences with different performance, privacy, and feature characteristics.
ISP resolvers: internet service providers operate recursive resolvers for their customers. When a device connects to an ISP network it receives the addresses of the ISP’s resolvers through DHCP, the protocol that assigns IP addresses and network configuration to devices. By default most devices use their ISP’s resolvers for DNS.
ISP resolvers vary widely in performance and quality. Some ISPs operate fast well-maintained resolvers with good cache efficiency. Others run slower resolvers with poor reliability. Some ISPs engage in DNS hijacking: modifying responses for non-existent domains to serve advertising pages rather than returning standard NXDOMAIN responses.
Public resolvers: alternative recursive resolvers operated by companies and organisations for anyone to use. Public resolvers are configured manually on devices or routers in place of ISP resolvers. They typically offer better performance reliability and privacy than many ISP resolvers.
Google Public DNS, 8.8.8.8 and 8.8.4.4: one of the first and most widely used public resolvers. Fast global anycast infrastructure. Google logs query data as part of its operations.
Cloudflare DNS, 1.1.1.1 and 1.0.0.1: consistently among the fastest resolvers globally. Privacy-focused, Cloudflare commits to not logging personally identifiable query data. Supports DNS over HTTPS and DNS over TLS.
Quad9, 9.9.9.9: operated by a non-profit. Blocks queries for domains known to be associated with malware, phishing, and other threats using a threat intelligence database. Does not log personally identifiable information.
OpenDNS, 208.67.222.222 and 208.67.220.220: operated by Cisco. Offers optional content filtering and parental controls. Provides security filtering blocking known malicious domains.
Corporate and enterprise resolvers: organisations operate their own recursive resolvers within their networks for control and security. Corporate resolvers enforce content policies, blocking access to categories of websites. They resolve internal domain names, hostnames for internal services that are not published on the public internet. They log DNS queries for security monitoring and compliance. They can apply security filtering, blocking resolution of known malicious domains.
Browser-integrated resolvers: modern browsers increasingly implement their own DNS resolution using DNS over HTTPS, querying a specific DoH resolver directly from the browser rather than using the OS-configured resolver. Chrome Firefox and Edge all support DoH with configurable resolver endpoints. This bypasses the OS resolver and any network-level DNS policies entirely.
Resolver caching and performance
DNS resolvers maintain caches of recently resolved DNS records, one of the most important performance mechanisms in the DNS system. Caching allows resolvers to serve the vast majority of queries from local memory without making any external network requests.
A large public resolver serving millions of users caches records for popular domains continuously, any query for google.com, facebook.com, or any other frequently resolved domain is almost always served from cache. The cache hit rate for popular resolvers is typically 80 to 95 percent, meaning only a small fraction of queries require external resolution.
Resolver caching behaviour is governed by the DNS TTL: Time To Live, value on each cached record. The resolver stores the record value and an expiry time calculated from the TTL. While the cached copy is fresh the resolver serves it without querying authoritative nameservers. When the TTL expires the resolver fetches a fresh copy from the authoritative nameserver.
Resolver cache size limits mean that less frequently queried records may be evicted before their TTL expires, particularly for large resolvers handling enormous query volumes. Cache eviction policies, typically LRU, least recently used, determine which records are evicted when the cache is full.
The interaction between resolver caching and DNS propagation is the reason DNS changes do not take effect immediately everywhere. Resolvers continue serving cached records until their TTL expires regardless of what changes have been made on authoritative nameservers. The DNS TTL set on records before changes are made determines the maximum propagation window.
Resolver privacy
DNS queries reveal significant information about user behaviour, every website visited, every service used, every connection made involves a DNS lookup. The resolver receives all these queries and, depending on the resolver operator, may log them store them and use them for various purposes.
Traditional DNS privacy risks: standard DNS queries are sent in plaintext over UDP port 53. Anyone on the network path between the client and resolver can observe the queries, including ISPs routers and any eavesdropping party. The resolver itself receives all queries and has complete visibility into browsing behaviour.
DNS over HTTPS: DoH encrypts DNS queries in HTTPS traffic. Queries are sent to the resolver over an encrypted connection indistinguishable from regular HTTPS traffic. Network observers cannot see the DNS queries, only that the client is making HTTPS connections to the resolver’s IP address. DoH is supported by Cloudflare 1.1.1.1 Google 8.8.8.8 and other major public resolvers. Modern browsers support DoH natively.
DNS over TLS: DoT encrypts DNS queries using TLS on a dedicated port, port 853. Less widely supported than DoH but provides equivalent privacy protection. Some operating systems, Android in particular, support DoT natively.
Resolver logging policies: different resolver operators have different policies about what query data they log and for how long. Cloudflare commits to not logging personally identifiable query data. Google logs query data for 24 to 48 hours before anonymising. ISPs typically log DNS queries for extended periods and may share them with third parties or authorities.
Oblivious DNS over HTTPS: an emerging protocol that adds another layer of privacy by routing queries through a proxy server that separates the client IP address from the query content. The resolver sees the query but not who made it. The proxy sees who made the query but not what the query was. Neither party has the full picture.
Resolver security
DNS resolvers are targets for various attacks, both attacks on the resolvers themselves and attacks that use resolvers as vectors.
DNS hijacking at the resolver level: attackers who compromise a resolver or position themselves to intercept resolver queries can return fraudulent DNS responses, redirecting users to malicious servers. Large public resolvers are particularly attractive targets because compromising them affects millions of users simultaneously.
Cache poisoning: attackers send forged DNS responses to resolvers attempting to inject fraudulent records into the cache. A successfully poisoned resolver serves incorrect IP addresses to all its clients until the poisoned cache entry expires. Randomised source ports, a standard mitigation, make cache poisoning significantly harder by increasing the number of combinations an attacker must guess correctly.
DNSSEC validation: resolvers that validate DNSSEC signatures verify that DNS records have not been tampered with in transit. Forged records without valid cryptographic signatures from the authoritative nameserver are rejected rather than cached and served. DNSSEC-validating resolvers provide strong protection against cache poisoning and man-in-the-middle attacks on DNS responses.
Amplification attacks: DNS resolvers are used in DDoS amplification attacks, small queries to open resolvers that return large responses are sent with spoofed source addresses pointing to the attack victim. The resolver sends large responses to the victim overwhelming its bandwidth. Rate limiting and access controls on resolvers mitigate amplification attack participation.
Choosing a DNS resolver
For most users the default resolver provided by their ISP works adequately. Switching to an alternative resolver offers potential benefits in performance privacy and security depending on the choice.
Performance: public resolvers with global anycast infrastructure typically offer lower latency than many ISP resolvers, particularly for users whose ISP operates fewer resolver locations. Testing resolver performance from a specific location using tools like DNS Benchmark or namebench identifies which resolver provides the best response times from that network.
Privacy: users concerned about DNS query logging should choose resolvers with strong privacy commitments. Cloudflare’s 1.1.1.1 and Quad9’s 9.9.9.9 both commit to not selling or sharing query data. Using DoH or DoT additionally encrypts queries in transit.
Security: resolvers that provide threat blocking, Quad9 OpenDNS NextDNS, add a layer of protection against malicious domains. Queries for known phishing malware and tracking domains are blocked at the resolver level without requiring browser extensions or other client-side tools.
Reliability: large public resolvers with multiple global locations provide higher reliability than single-location ISP resolvers. Geographic redundancy means a regional outage at one resolver location does not affect users who are automatically served by other locations.
DNS resolvers and redirect management
DNS resolvers interact with redirect management in several ways that affect how quickly redirect configurations take effect and how they are experienced by visitors.
Resolver caching affects redirect propagation: when a domain is connected to redirect infrastructure by updating DNS records the change propagates to resolvers worldwide as their cached copies of the old records expire. Resolvers with cached old records continue routing visitors to the old server. Resolvers that have fetched the updated records route visitors to the redirect infrastructure. The DNS TTL on the changed records determines the maximum propagation window.
Testing redirects requires accounting for resolver caching: testing redirect configuration from the same device that previously visited the domain may use cached resolver results showing the old pre-redirect DNS values. Flushing the local DNS cache, at both the browser and OS levels, ensures tests use fresh resolver results. Testing from multiple devices on different networks and using different resolvers provides a more complete picture of redirect propagation.
Resolver selection affects perceived propagation speed: different resolvers may have cached the old DNS records at different times and with different TTLs. A resolver that cached the record immediately before the change was made continues serving the old value for the full TTL duration. A resolver that had not recently cached the record fetches the updated value immediately. Checking propagation across multiple resolvers, 8.8.8.8, 1.1.1.1, 9.9.9.9: shows the range of experiences different visitors have during propagation.
Public resolver behavior for new domains: when a domain is newly registered or newly connected to redirect infrastructure some public resolvers pre-fetch or pre-cache popular domains. Newly registered or newly configured domains start with cold caches everywhere, the first query from any resolver requires the full recursive resolution process before the redirect infrastructure can serve a response.
Checking which resolver a device uses
Understanding which resolver a device is using helps diagnose DNS issues and understand propagation behaviour.
Checking configured resolver: the configured DNS resolver addresses are visible in network settings on any device.
On macOS, System Settings → Network → select the active connection → Details → DNS tab shows the configured DNS server addresses.
On Windows, Control Panel → Network and Sharing Center → change adapter settings → right-click the active connection → Properties → Internet Protocol Version 4 → Properties shows the DNS server addresses.
On Linux, the /etc/resolv.conf file lists the configured nameserver addresses.
Querying to identify the resolver: several DNS providers operate special hostnames that return information about the resolver being used. Querying these reveals which resolver is actually handling the response:
Online resolver identification tools: services like 1.1.1.1/help: Cloudflare’s resolver diagnostic page, and similar tools show whether the request is being handled by the expected resolver and provide information about DoH and DoT support.