Why is DNS still hard to learn?

Why DNS Remains Hard to Learn

DNS has been around since the 1980s and powers every website on the internet. It’s remarkably stable—in many ways it works today much as it did three decades ago. Yet even experienced programmers often struggle to debug DNS issues. Many smart engineers admit they don’t feel comfortable making simple DNS changes to their own websites, are confused about basic facts (like that records are pulled, not pushed), or have gaps in knowledge such as negative caching or how dig queries differ from browser queries.

Interestingly, when programmers finally learn how to troubleshoot DNS problems, their reaction is often “that’s it? That’s not that hard!”. So if DNS isn’t inherently complicated, why does it take so many years to grasp? Several factors seem to be at play.

Much of the System Is Hidden

When your computer makes a DNS request, the basic flow is: your machine asks a resolver, which checks its cache and then queries authoritative nameservers. But several parts of that process remain invisible to you:

• The resolver’s cache contents—you can’t see what’s in there.
• Which library code is actually making the request. Is it libc getaddrinfo from glibc, musl, or Apple? Is it your browser’s own DNS implementation? Each behaves slightly differently, with its own configuration and caching rules. For example, musl DNS didn’t support TCP until early 2023.
• The conversation between the resolver and authoritative nameservers. If you could magically see a trace of exactly which nameservers were queried and what they replied, many DNS issues would become obvious. For instance, what if dig +debug google.com gave you that sort of extra debugging information?

Simply teaching people what these hidden systems are is a huge help. Some tools try a “fishbowl” approach—like Mess With DNS—which reveals parts of the system that are normally obscured.

Extended DNS Errors Show Promise

There is an emerging mechanism, called Extended DNS Errors (EDE), that lets DNS servers attach extra debugging information to responses. Here’s an example:

$ dig @8.8.8.8 xjwudh.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39830
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
;; QUESTION SECTION:
;xjwudh.com.			IN	A

;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1690634120 1800 900 604800 86400

;; Query time: 92 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Sat Jul 29 08:35:45 EDT 2023
;; MSG SIZE  rcvd: 161

The output above shows a response for a nonexistent domain, including the extended error EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a). Although the exact meaning (something related to DNSSEC) isn’t immediately obvious, seeing these extra messages is encouraging. Note that you may need a newer version of dig to see EDE output.

The Tools Themselves Are Confusing

Despite the hidden layers, dig does offer ways to probe what’s going on. For example, dig +norecurse can tell you whether a given resolver has a record cached. Here’s what that looks like for two domains using 8.8.8.8:

$ dig +norecurse  @8.8.8.8 google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11653
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		21	IN	A	172.217.4.206

;; Query time: 57 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 28 10:50:45 EDT 2023
;; MSG SIZE  rcvd: 55

$ dig +norecurse  @8.8.8.8 homestarrunner.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55777
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;homestarrunner.com.		IN	A

;; Query time: 52 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 28 10:51:01 EDT 2023
;; MSG SIZE  rcvd: 47

The first query for google.com returns a normal NOERROR response (cached), while homestarrunner.com returns SERVFAIL (not cached). That doesn’t mean the second domain has no DNS records—it just isn’t cached yet.

But reading dig output is far from intuitive if you’re not used to it. A few quirks that stand out:

1. The headings are odd—there’s ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, and ANSWER SECTION:.
2. The spacing is inconsistent; for example, there’s no newline between the OPT PSEUDOSECTION and QUESTION SECTION.
3. Fields like MSG SIZE rcvd: 47 seem cryptic. Are there other fields under MSG SIZE besides rcvd?
4. The output says there’s 1 record in the ADDITIONAL section but doesn’t display it unless you know the “OPT PSEUDOSECTION” record is the one in question.

Overall, dig’s output feels like a script that grew organically over time rather than something deliberately designed.

Possible Fixes for Confusing Tools

A few approaches could make DNS tooling more approachable:

• Explain the output. Guides like how to use dig decode the format and show how to configure shorter default outputs.
• Create friendlier alternatives. Tools such as dog and doggo aim to be more user-friendly. However, they may lack some advanced features like +norecurse, meaning many people stick with dig because they prefer one tool for everything. Replacing the full functionality of dig is a massive undertaking.
• Make dig output more readable. A potential +human flag could format the long-form output in a more structured and clear way, for example:

$ dig +human +norecurse  @8.8.8.8 google.com 
HEADER:
  opcode: QUERY
  status: NOERROR
  id: 11653
  flags: qr ra
  records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

QUESTION SECTION:
  google.com.			IN	A

ANSWER SECTION:
  google.com.		21	IN	A	172.217.4.206
  
ADDITIONAL SECTION:
  EDNS: version: 0, flags:; udp: 512

EXTRA INFO:
  Time: Fri Jul 28 10:51:01 EDT 2023
  Elapsed: 52 msec
  Server: 8.8.8.8:53
  Protocol: UDP
  Response size: 47 bytes

This structured view would make the header, question, answer, and additional sections immediately obvious. It wouldn’t remove any data—it would just present the exact same information more clearly. A common complaint with alternative DNS tools is that they often omit information in the name of simplicity. There’s a place for such tools, but knowing what’s being left out matters too.

It’s worth noting that newer versions of dig offer a +yaml output format, which feels clearer to many people—though it can be too verbose for practical use, with even a simple response not fitting on one screen.

DNS’s Weird Gotchas

DNS is full of quirks that are common to run into but difficult to learn about on your own. Some notable examples:

• Negative caching. If you visit a domain before its DNS record exists, the nonexistence of that record gets cached—sometimes for hours. It can take years to realize you shouldn’t test a domain until its records are fully set up.
• Differences in getaddrinfo implementations. For instance, musl lacked TCP DNS support until early 2023.
• Resolvers that ignore TTLs. even if you set a TTL of, say, 5 minutes, some resolvers may cache records for up to 24 hours despite your settings.
• Misconfigured nginx. If nginx is set up incorrectly, it can cache DNS records indefinitely.
• Kubernetes ndots. The ndots option can cause DNS resolution to be unexpectedly slow in Kubernetes clusters.

Knowledge of these gotchas is extremely hard-won—negative caching alone can take five years to discover. It feels wasteful that each generation of engineers has to rediscover these lessons independently.

Several strategies can help:

• Call out gotchas explicitly when explaining a topic. For example, Josh Comeau’s Flexbox introduction highlights the well-known minimum size gotcha that trips people up repeatedly.
• Build more community collections of known pitfalls. For bash, shellcheck serves as an excellent reference of common bash mistakes.

One complication is that different people hit different gotchas. Someone configuring their personal domain once every few years will encounter very different issues than an engineer managing DNS for a high-traffic service.

Infrequency and Fear of Experimentation

Many people only touch DNS occasionally—every three years, perhaps. That makes it naturally harder to build expertise. Cheat sheets, such as step-by-step guides for changing nameservers, can help bridge those long gaps.

DNS is also intimidating to experiment with. Nobody wants to accidentally break their own domain. Tools like Mess With DNS exist to provide a safe sandbox for exploration.

If you’ve worked with another technology that feels similarly mysterious to learn, patterns like those above probably sound familiar. Hidden components, opaque tooling, unexpected gotchas, and infrequent usage form a potent mix.