It only builds the requests, crafts the packets, sends them, receives the reply, and parses it back into useable objects. No heavy lifting at all.
You're not going to win this argument, no matter how many synonyms for "encode" and "decode" you come up with.
If you hold the opinion that a 12 line for loop is heavier lifting than the underlying library doing the aforementioned things, that's your right.
I'm not messing with you; as someone who does an unfortunate amount of DNS hacking, it is crazymaking to see so many people express the opinion that the hard part of doing DNS is just formatting the records. The argument you're presenting is a little like saying that "malloc" would be doing the heavy lifting in a C implementation of a graph minimum cost spanning tree.
This also isn't just an aesthetic argument. There is something profound about it. No language standard library I'm aware of includes a recursive lookup, despite the fact that you've pegged it as a "12 line for loop". They all in some way or other include DNS message codecs, but not the recursive lookup, despite the fact that it would be immensely useful to be able to write programs that did recursive lookups directly rather than relying on the system's configured recursive resolver. The reason for that is at least partly that recursive lookup is mystifying and spooks library implementors.
I've had the displeasure of writing both a series of DNS codecs and a recursive lookup routine. The codecs I've done throughout my career, going back to like 1997 with exploits for the Kashpureff cache poisoning bug. The recursor I finally got around to writing just a couple months ago, because recursive lookups are freaking complicated.
That the author got this recursive lookup so small that it broke everyone's brains is just more reason to be interested in this article. It's certainly not a reason to dismiss it. The reactions on this thread are pretty embarrassing.
I know because I've done it (I wrote a an authoritative DNS server from scratch for a registry platform we did for .name).
To write a full fledged library for it for a resolver (an authoritative server can take plenty of shortcuts depending on purpose) is complex, but I absolutely agree the basics that you'd demonstrate if writing a toy one to demonstrate would be just a distraction.
https://github.com/jvns/tiny-resolver/blob/main/resolver.sh - the recursive lookup is 16 lines for + switch.
I'm sorry to say this, but if the recursive lookup can be implemented with a for and a 3-way switch that a CS 101 student can write, it's really not doing the heavy lifting. It may be interesting to know about it, it may be the case that multiple resolves don't have the implementation, but it's a trivial piece of code, let's not idolize it.
For me personally, having the power of hitting an endpoint and receiving useful information is really satisfying. Creating the request and parsing the reply are probably 90% of that process. And frankly, that was the first think I was looking for when I skimmed the article. "Are DNS replies really that easy to parse?". The fact that I need to make a switch on the reply and potentially make a recursive request somewhere else is trivial once you get the actual useful info from the remote.
I'm not criticising the article or the title. It's my opinion that parsing is more important, I'm not faulting the author. But I'm having a hard time accepting your arguments.
My argument is that DNS codecs are not the interesting or tricky part of writing recursive resolvers.
Having had the pleasure of writing a bunch of DNS codecs, I'm having trouble even conceptualizing what's interesting about writing one. I don't think most people look at DNS and think "I could do this, but for the difficulty of constructing an NS record".