Introduction: The “It’s Always DNS” Meme#

In ops circles, there’s a long-running self-deprecating joke: It’s always DNS. A service goes down, a deployment becomes unreachable, half your users report errors after a CDN switch—and after a full round of troubleshooting, the culprit is usually this system we almost never pay attention to.

DNS gets “blamed” so often because it’s the first link in the entire internet access chain, yet it’s also the link with the most cache layers and the hardest-to-observe state. This article starts from the resolution chain, takes apart how DNS works, and then lands on concrete troubleshooting techniques.

1. What Exactly Is DNS#

DNS (Domain Name System) is essentially a globally distributed key-value database that maps human-readable domain names to machine-routable IP addresses. Its design has two key points:

1. Tree-like hierarchical structure

Domain names are read from right to left, forming an inverted tree:

1
                    . (root domain)
2
                 /     |     \
3
             com      org     cn
4
            /   \             |
5
       google  example      com
6
                  |           |
7
                www         baidu

www.example.com. The trailing dot represents the root domain, which browsers normally omit. Each level is managed by a different organization: the root domain is handled by 13 sets of root servers (a.root-servers.net to m.root-servers.net), .com is managed by Verisign, and example.com is hosted by your own domain registrar.

2. Authorization and delegation

Each level doesn’t store all records of the level below it—it only stores a pointer (NS record) to “who is responsible for the next level.” This delegation mechanism allows DNS to carry billions of domain names without any single point holding the full dataset.

2. The Chain of a Complete Resolution#

Suppose you type www.example.com into your browser. What happens behind the scenes, in order, is:

1
Browser cache → OS cache (hosts + stub resolver)
2
    → Recursive resolver (usually ISP DNS or 8.8.8.8)
3
        → Root server: "`.com` is managed by these NS"
4
        → .com TLD server: "`example.com` is managed by these NS"
5
        → example.com authoritative server: "the A record for `www` is 93.184.216.34"
6
    ← Returned and cached layer by layer

There’s an easily confused concept here: recursive query vs. iterative query.

• What your device sends to the recursive resolver is a recursive query: “You’re responsible for giving me the final answer, don’t make me look it up myself.”
• What the recursive resolver sends to authoritative servers at each level is an iterative query: “If you know, give me the answer; if not, tell me who to ask.”

The one actually doing the work and traversing the globe is the recursive resolver—your device only sent a single packet.

3. Common Record Types Quick Reference#

4. TTL and Caching: The High-Risk Zone for Failures#

Every DNS record carries a TTL (Time To Live) in seconds, telling downstream “how long you may cache this answer.” TTL is the most counterintuitive part of DNS—just because you changed a record doesn’t mean users will see it immediately.

For a DNS change to truly take effect across the internet, you need to wait for all cache layers along the chain to expire:

1
Authoritative server (takes effect immediately)
2
  → Recursive resolver cache (wait for TTL)
3
    → OS cache (wait for TTL)
4
      → Browser cache (Chrome defaults to about 60s, and does not always respect TTL)

So the correct switching approach is: lower the TTL to 60 seconds 24–48 hours in advance, and after the switch is complete and observed to be stable, set it back to 3600. Many people only remember to change the TTL on the day of the switch—by then the old high TTL has already been cached out, and it’s too late.

Another pitfall is negative caching: when resolution fails and returns NXDOMAIN, this “does not exist” conclusion is also cached, for a duration determined by the last field of the SOA record. This is why “the record is clearly added, but it still won’t resolve”—the failed query you made before adding the record cached the NXDOMAIN.

5. Hands-On Troubleshooting: dig Is the Right Tool#

ping can only tell you whether it’s reachable, and nslookup outputs too little information. For DNS troubleshooting, go straight to dig.

Basic query:

1
# Query A record
2
dig example.com A +short
3
# 93.184.216.34
4

5
# Full output, check TTL and response source
6
dig example.com A

Pay attention to three key points in the output:

1
;; ANSWER SECTION:
2
example.com.    3600    IN    A    93.184.216.34
3
                 ↑ remaining TTL; decreasing on each query indicates a cache hit
4

5
;; SERVER: 8.8.8.8#53      ← the resolver that actually answered
6
;; flags: qr rd ra;        ← ra means the server supports recursion

Bypass the cache and ask the authoritative server directly:

This is the decisive method for determining “is the record misconfigured, or has the cache not expired”:

1
# 1. First find the authoritative server
2
dig example.com NS +short
3
# ns1.example.com.
4

5
# 2. Query it directly, bypassing all recursive caches
6
dig @ns1.example.com example.com A

If the authoritative server returns the correct result but 8.8.8.8 doesn’t, then it’s purely a caching issue—just wait for the TTL.

Trace the complete delegation chain level by level:

1
dig example.com +trace

This command starts from the root servers and prints out every level of delegation in full. When you suspect the NS records are misconfigured, or the domain is “disconnected” between the registrar and the DNS provider, +trace can immediately pinpoint which layer the break is at.

Compare different resolvers (troubleshoot DNS poisoning / split-horizon resolution):

1
for s in 8.8.8.8 1.1.1.1 223.5.5.5 114.114.114.114; do
2
  echo -n "$s => "
3
  dig @$s example.com A +short | head -1
4
done

6. Four Classic Failure Types Comparison Table#

Another high-frequency trap: the apex domain cannot have a CNAME. RFC 1034 stipulates that a CNAME record cannot coexist with other records, and the apex domain must have SOA and NS records. Therefore example.com itself cannot have a CNAME—only www.example.com can. To point the apex domain at a CDN, you need non-standard extensions like ALIAS / ANAME / CNAME flattening provided by cloud vendors.

7. Write a Diagnostic Script#

Node.js’s dns module has two built-in sets of APIs: dns.lookup() goes through the operating system resolver (it reads the hosts file), while dns.resolve*() sends DNS queries directly. When troubleshooting, you must use the latter, otherwise you’re testing the system cache rather than DNS.

1
import { Resolver } from 'node:dns/promises';
2

3
const RESOLVERS = {
4
  Google: '8.8.8.8',
5
  Cloudflare: '1.1.1.1',
6
  AliDNS: '223.5.5.5',
7
};
8

9
async function diagnose(domain) {
10
  console.log(`
11
=== Diagnosing ${domain} ===
12
`);
13

14
  // 1. Query the authoritative server
15
  const base = new Resolver();
16
  base.setServers(['8.8.8.8']);
17
  let authNS = [];
18
  try {
19
    authNS = await base.resolveNs(domain);
20
    console.log(`Authoritative servers: ${authNS.join(', ')}`);
21
  } catch (err) {
22
    console.log(`NS query failed: ${err.code}`);
23
  }
24

25
  // 2. Cross-compare across multiple resolvers to check for consistency
26
  const results = new Map();
27
  for (const [name, ip] of Object.entries(RESOLVERS)) {
28
    const r = new Resolver({ timeout: 3000, tries: 2 });
29
    r.setServers([ip]);
30
    try {
31
      const addrs = await r.resolve4(domain, { ttl: true });
32
      const line = addrs.map((a) => `${a.address}(ttl=${a.ttl}s)`).join(' ');
33
      results.set(name, addrs.map((a) => a.address).sort().join(','));
34
      console.log(`${name.padEnd(11)} ✓ ${line}`);
35
    } catch (err) {
36
      // ENOTFOUND=NXDOMAIN, ESERVFAIL=server failure, ETIMEOUT=unreachable
37
      console.log(`${name.padEnd(11)} ✗ ${err.code}`);
38
    }
39
  }
40

41
  // 3. Determine whether resolution inconsistencies exist
42
  const unique = new Set(results.values());
43
  if (unique.size > 1) {
44
    console.log('\n⚠️  Parser results are inconsistent; the cache may be out of sync or partitions may be parsed separately');
45
  } else if (unique.size === 1) {
46
    console.log('\n✓ Parser results are consistent');
47
  }
48
}
49

50
await diagnose(process.argv[2] ?? 'example.com');

Run node dns-check.mjs example.com, and you can see at a glance both the remaining TTL and consistency across resolvers—these two pieces of information cover eighty percent of everyday DNS fault diagnosis.

8. Encrypted DNS: DoH and DoT#

Traditional DNS queries go over UDP port 53, completely in plaintext. This means any hop along the path can see which domains you’re visiting, and can even forge responses (this is precisely the technical basis for DNS hijacking and poisoning).

Two mainstream encryption schemes:

• DoT (DNS over TLS, RFC 7858): uses port 853, running the standard DNS protocol inside a TLS tunnel. The dedicated port makes it easy for network administrators to manage and control uniformly.
• DoH (DNS over HTTPS, RFC 8484): encapsulates queries as HTTPS requests over port 443, blending in with ordinary web traffic, making it hard to identify and block.

DoH can be verified directly with curl:

1
curl -s -H 'accept: application/dns-json' \
2
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq

It’s worth noting that encrypted DNS solves the privacy and integrity of the transmission link, but does not solve whether the resolver itself is trustworthy—your query records are still fully exposed to that DoH provider. This is a transfer of trust, not an elimination of trust.

Conclusion#

DNS’s complexity doesn’t lie in the protocol itself—its message format hasn’t changed much in decades—but in the multi-level cache chain spanning browsers, operating systems, recursive resolvers, and authoritative servers. When troubleshooting, just remember one main thread:

Query backward from the authoritative server. First use dig @权威NS to confirm whether the source data is correct, then work down layer by layer to determine which level of cache is holding things up.

Once you understand this, “It’s always DNS” goes from being mysticism to an everyday problem that three commands can pinpoint.

References#

• RFC 1034 - Domain Names: Concepts and Facilities
• RFC 1035 - Domain Names: Implementation and Specification
• RFC 2308 - Negative Caching of DNS Queries
• RFC 8484 - DNS Queries over HTTPS (DoH)
• Cloudflare Learning - What is DNS?
• Node.js DNS Module Official Documentation