Stackvora.tech

How DNS Really Works: Recursive vs Authoritative

The Domain Name System (DNS) is a foundational component of modern internet infrastructure, translating human-readable domain names into machine-readable…

The Domain Name System (DNS) is a foundational component of modern internet infrastructure, translating human-readable domain names into machine-readable IP addresses. While often abstracted, understanding the interaction between recursive and authoritative DNS servers is crucial for network engineers, system administrators, and developers to diagnose connectivity issues, configure services, and optimize performance. This article details the query resolution process, distinguishing between the roles of these server types.

The DNS Query Lifecycle

A DNS query begins when an application or operating system needs to resolve a domain name. This process involves a series of interactions between various DNS server types, culminating in an IP address.

1. Client-Side Resolution

When a client (e.g., a web browser, a command-line tool) attempts to connect to a domain name:

  • The application first checks its own internal cache for a cached IP address for the requested domain.
  • If not found, the operating system's DNS client cache (e.g., systemd-resolved on Linux, DNS Client service on Windows) is consulted.
  • If still not found, the query is forwarded to the configured local DNS resolver, often provided by a router, ISP, or a public DNS service like Google Public DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1). This resolver is known as a recursive resolver.

2. The Recursive Resolver's Role

The recursive resolver is responsible for finding the answer to the client's query. It performs the iterative queries on behalf of the client. This typically involves the following steps:

  1. Querying a Root Name Server: The recursive resolver starts by querying one of the 13 logical DNS root name servers (e.g., a.root-servers.net through m.root-servers.net) for the top-level domain (TLD) of the requested domain (e.g., .com for example.com). The root server does not know the IP address for example.com, but it knows which servers are authoritative for the .com TLD. It responds with a list of TLD name servers.
  2. Querying a TLD Name Server: The recursive resolver then queries one of the TLD name servers (e.g., a.gtld-servers.net for .com) for the requested domain (e.g., example.com). The TLD name server does not know the IP address for example.com, but it knows which servers are authoritative for the example.com domain. It responds with a list of authoritative name servers for example.com.
  3. Querying an Authoritative Name Server: Finally, the recursive resolver queries one of the authoritative name servers for example.com (e.g., ns1.example.com). This server holds the actual DNS records for example.com and will provide the requested A (IPv4) or AAAA (IPv6) record.
  4. Caching and Response: Upon receiving the answer, the recursive resolver caches it for the duration specified by the record's Time-To-Live (TTL). It then returns the IP address to the original client. Subsequent queries for the same domain from other clients will be served from the recursive resolver's cache until the TTL expires.

Authoritative vs. Recursive DNS Servers

Recursive DNS Servers

A recursive DNS server is the intermediary that takes a DNS query from a client and performs all the necessary steps to resolve it. Its key characteristics include:

  • Query Flow: Accepts recursive queries from clients.
  • Responsibility: Fully resolves the query, performing iterative requests to root, TLD, and authoritative servers on the client's behalf.
  • Caching: Aggressively caches responses to reduce latency and load on upstream servers. Cache size and eviction policies vary by implementation (e.g., BIND, Unbound, PowerDNS Recursor, dnsmasq).
  • Examples: ISP DNS servers, public DNS services (e.g., 1.1.1.1, 8.8.8.8, 9.9.9.9), enterprise internal DNS resolvers.
  • Typical Ports: Listens on UDP port 53 and TCP port 53 for queries.

For instance, an enterprise might run an internal recursive resolver using BIND:

// named.conf options snippet
options {
    directory "/var/cache/bind";
    recursion yes; # Enable recursion
    allow-query { any; }; # Allow queries from any client, typically restricted to internal networks
    forwarders {
        1.1.1.1;
        1.0.0.1;
    }; # Optional: forward queries to upstream resolvers
    dnssec-validation auto; # Enable DNSSEC validation
    listen-on { 192.168.1.10; }; # IP address to listen on
    // ...
};

The forwarders directive tells the BIND resolver to send queries it cannot answer locally to 1.1.1.1 and 1.0.0.1 first, rather than performing the full root-to-authoritative lookup itself. This can be useful for security, policy enforcement, or performance.

Authoritative DNS Servers

An authoritative DNS server holds the original, definitive DNS records for one or more specific domains (zones). It only provides answers for domains it is configured to host. Its key characteristics include:

  • Query Flow: Accepts iterative queries from recursive resolvers.
  • Responsibility: Responds directly with resource records (A, AAAA, MX, CNAME, etc.) or delegates authority to another server (e.g., NS records). It does not perform lookups for other domains.
  • Data Source: Serves records directly from its zone files (e.g., /etc/bind/db.example.com).
  • Examples: Name servers registered with a domain registrar (e.g., ns1.nameserver.com, ns2.nameserver.com), internal DNS servers hosting corporate domains.
  • Typical Ports: Listens on UDP port 53 and TCP port 53 for queries and zone transfers.

An authoritative zone file for example.com might look like this:

$TTL 3600       ; 1 hour
@ IN SOA ns1.example.com. hostmaster.example.com. (
                2023112001 ; Serial
                7200       ; Refresh (2 hours)
                3600       ; Retry (1 hour)
                1209600    ; Expire (2 weeks)
                3600       ; Minimum TTL (1 hour)
                )
@           IN  NS  ns1.example.com.
@           IN  NS  ns2.example.com.

ns1         IN  A   192.0.2.10
ns2         IN  A   192.0.2.11

@           IN  A   192.0.2.1
www         IN  A   192.0.2.1
mail        IN  A   192.0.2.2
MX          IN  10  mail.example.com.
_spf        IN  TXT "v=spf1 ip4:192.0.2.2 ~all"

In this example, ns1.example.com and ns2.example.com are the authoritative name servers for example.com. They would typically be configured in a named.conf file on the authoritative server to load this zone.

Common DNS Record Types

The authoritative DNS server holds various record types, each serving a specific purpose:

  • A Record: Maps a domain name to an IPv4 address (e.g., example.com to 93.184.216.34).
  • AAAA Record: Maps a domain name to an IPv6 address (e.g., example.com to 2606:2800:220:1:248:1893:25c8:1946).
  • CNAME Record (Canonical Name): Creates an alias from one domain name to another (e.g., www.example.com to example.com). The resolution continues with the aliased name.
  • MX Record (Mail Exchange): Specifies the mail servers responsible for receiving email for a domain, along with a preference value (e.g., mail.example.com).
  • TXT Record (Text): Stores arbitrary text data, often used for verification (e.g., domain ownership), email authentication (SPF, DKIM, DMARC), or other services.
  • NS Record (Name Server): Delegates authority for a domain or subdomain to specific name servers. These are critical for the hierarchical structure of DNS.
  • PTR Record (Pointer): Performs reverse DNS lookups, mapping an IP address back to a domain name (e.g., 34.216.184.93.in-addr.arpa to example.com). Primarily used for spam filtering and logging.
  • SRV Record (Service): Locates specific services (e.g., SIP, XMPP) by specifying hostname and port.

Debugging DNS Queries

Several command-line tools are indispensable for debugging DNS:

dig (Domain Information Groper)

dig is a flexible tool for querying DNS name servers. It can show the full query path:

$ dig +trace example.com
; <<>> DiG 9.16.42 <<>> +trace example.com
;; global options: +cmd
.                       357945  IN      NS      k.root-servers.net.
.                       357945  IN      NS      c.root-servers.net.
; ... (other root servers) ...
.                       357945  IN      NS      a.root-servers.net.
;; Received 489 bytes from 192.168.1.1#53(192.168.1.1) in 15 ms

com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
; ... (other TLD servers) ...
com.                    172800  IN      NS      a.gtld-servers.net.
;; Received 493 bytes from 192.228.79.201#53(d.root-servers.net) in 33 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 170 bytes from 192.33.14.30#53(d.gtld-servers.net) in 36 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 55 bytes from 192.0.32.10#53(a.iana-servers.net) in 38 ms

The +trace option shows the iterative query path from the root servers down to the authoritative servers. To query a specific DNS server:

$ dig @8.8.8.8 example.com A

To query for a specific record type, e.g., MX records:

$ dig example.com MX

nslookup

nslookup is an older tool, still commonly used. Its interactive mode can be useful.

$ nslookup
> server 8.8.8.8 # Set recursive resolver to use
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set type=MX # Set query type
> example.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
example.com	mail exchanger = 0 .

Note: nslookup sometimes performs recursive lookups even when pointed at an authoritative server, which can be confusing for debugging authoritative responses directly. dig is generally preferred for detailed analysis.

Common Pitfalls

  • Incorrect TTL values: Setting a very high TTL (e.g., 1 week) for a record that needs to change frequently can lead to prolonged propagation delays after an update. Conversely, a very low TTL can increase query load on authoritative servers.
  • Mismatched NS records: The NS records at the parent zone (e.g., the .com TLD servers) must match the NS records configured on your authoritative DNS servers. Discrepancies lead to "DNS glue" issues or resolution failures.
  • Firewall blocking port 53: Ensure UDP and TCP port 53 are open bidirectionally between clients and recursive resolvers, and between recursive resolvers and authoritative servers. TCP port 53 is critical for zone transfers and responses exceeding 512 bytes (though often fragmented over UDP with EDNS0).
  • DNSSEC validation failures: Misconfigured DNSSEC records (DS, RRSIG) can lead to resolvers refusing to serve records, resulting in SERVFAIL errors for clients using validating resolvers.
  • Caching issues: A stale entry in a recursive resolver's cache can cause clients to receive old data. Clearing caches (if possible) or waiting for TTL expiry is necessary.

Back to the knowledge base · Ask the AI assistant