I don't agree with this article. I think DNS is something few people take the time to learn, but it's not actually hard to learn. One of the great things about DNS is that the system itself will tell you about it's internal state in response to queries. It's very easy to inspect a DNS server for a known zone and understand how it works, and there's very good tooling that's free and widely available to do this (like dig).

It's always been a big surprise to me that my DNS expertise is what seems to be most memorable for a lot of folks I've worked with through my career, when I don't believe I know anything mystical or special. DNS is extremely well standardized, the most common server and client implementations rigorously follow the standard, and it's very easy to inspect with free tooling. It just takes some effort and time to learn, but it's not really hard.

I think it is hard to learn... using the tools people used to learn DNS with.

BIND is great at what it does, but its configuration files suck and its manual is long, terse, and unnecessarily complex sometimes. Dig is powerful, but abbreviates everything like we're on an 80 column terminal. At times Wireshark was a better tool debugging DNS issues than Dig was.

Give someone PowerDNS or another modern DNS server and I think they'll have a much better time configuring a working DNS server. I don't know a good modern DNS client, so I've learned to deal with Dig instead. As a user of the "--color" flag for the `ip` command, I'd love to see tools like dig produce more modern output (I'll alias the command line flags, just add it to the command!)

Seriously, "MSG SIZE rcvd: 71" did not need abbreviation. "flags: qr rd ra" could've been full words as well. I don't know what the semicolons before the lines are supposed to convey but they're only making things confusing.

I find it no wonder people get confused learning DNS with the materials provided to them.

https://github.com/ogham/dog is pretty good in that regard