4 ms·

I normally don't like comments like this but I think in this case your point stands. DNS is not 'easy' in that you have troves of RFCs and undocumented but exp

I normally don't like comments like this but I think in this case your point stands. DNS is not 'easy' in that you have troves of RFCs and undocumented but expected behaviors to follow, etc. miekg/dns does all of the heavy lifting here. Writing a resolver in it is a fun project, but bragging about the line count is silly.

wanderer_ 5y ago
I think the line count was just to emphasize simplicity and accessibility, rather than to brag.
djur 5y ago
I didn't read the article as "bragging" about the line count, but saying it was short enough to be read casually as a companion to the comic.
bragr 5y ago
Cannot second this enough. miekg/dns is probably tens of thousands of mature lines of code covering all aspects of the DNS protocol. This feels like bragging about creating an minimal http client but really you just used libcurl to do the heavy lifting.
- djur 5y ago
  Seems more like writing an article where you explain how HTTP caching headers work by using libcurl to write a program to mirror a website. The purpose isn't showing off, it's education.
- tptacek 5y ago
  It is nothing at all like using libcurl to do an HTTP request, as libcurl handles the semantics of the HTTP protocol, and not just marshaling and unmarshaling HTTP requests and responses. miekg/dns is also 20,000 lines of code most of which are not relevant to the task of doing a recursive lookup.
mevdschee 5y ago
>bragging about the line count is silly. and gatekeeping is silly too..
zaphar 5y ago
miekg/dns literally only handles building/parsing the dns packets. Which may be a complicated activity and perhaps for you equals "doing all the heavy lifting" But it is absolutely not doing the "recursive resolve" algorithm at all here. I think parsing network packets is interesting but it's not the point of the article and saying that miekg/dns is doing all the heavy lifting doesn't give the article or it's author enough credit. Honestly the comments of this type on this article sound more like you didn't actually read the article and are just knee jerk putting someone down. I hope that is not the case but maybe it would be good to examine why the message is coming off so distastefully.
tptacek 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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.

wanderer_ 5y ago

I think the line count was just to emphasize simplicity and accessibility, rather than to brag.

djur 5y ago

I didn't read the article as "bragging" about the line count, but saying it was short enough to be read casually as a companion to the comic.

bragr 5y ago

Cannot second this enough. miekg/dns is probably tens of thousands of mature lines of code covering all aspects of the DNS protocol. This feels like bragging about creating an minimal http client but really you just used libcurl to do the heavy lifting.

djur 5y ago
Seems more like writing an article where you explain how HTTP caching headers work by using libcurl to write a program to mirror a website. The purpose isn't showing off, it's education.
tptacek 5y ago
It is nothing at all like using libcurl to do an HTTP request, as libcurl handles the semantics of the HTTP protocol, and not just marshaling and unmarshaling HTTP requests and responses. miekg/dns is also 20,000 lines of code most of which are not relevant to the task of doing a recursive lookup.

mevdschee 5y ago

>bragging about the line count is silly. and gatekeeping is silly too..

zaphar 5y ago

miekg/dns literally only handles building/parsing the dns packets. Which may be a complicated activity and perhaps for you equals "doing all the heavy lifting" But it is absolutely not doing the "recursive resolve" algorithm at all here. I think parsing network packets is interesting but it's not the point of the article and saying that miekg/dns is doing all the heavy lifting doesn't give the article or it's author enough credit. Honestly the comments of this type on this article sound more like you didn't actually read the article and are just knee jerk putting someone down. I hope that is not the case but maybe it would be good to examine why the message is coming off so distastefully.

tptacek 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.