[tptacek]

miekg/dns is doing almost none of the heavy lifting here, which you can verify for yourself by counting the number of record types this code actually needs to parse to function, and comparing it to the number of record types miekg/dns supports and how much of the code exists just to dispatch to random record type handlers.

[silisili]

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.

[tptacek]

Correct; none of that is the heavy lifting of a recursive lookup. One way you know that is that similar code lives in every libc, but no libc I know of has a recursive resolver; the pattern of fobbing off complicated recursive queries to cache servers is so common that there's a name for library-style resolvers: "stub resolver".

You're not going to win this argument, no matter how many synonyms for "encode" and "decode" you come up with.

[silisili]

There's no argument I'm trying to win. I've only stated my opinion.

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.

[tptacek]

You have one extra "your" the final clause of that last sentence.

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.

[rootlocus]

> 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.

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.

[tptacek]

It's not my argument that cs 101 students can't write recursive resolvers. Everyone can, and more people should, just like more people should write emulators, compilers, database engines, TCP/IP stacks, ray tracers, and computer algebra systems. Not because writing them is a huge achievement for humanity, but because people writing them and then documenting the process is vitally important for demystifying these things, in an era where most programming is just piping data from one database to another and we've lost touch with so much basic computer science.

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".

[vidarh]

I'd add to this that if you just want to demonstrate the encode/send/receive/decode part, that too can be done in a nearly trivial amount of code.

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.

[dapids]

Okay, now do it recursively for all supported record types. Oh, wait.