7 ms·
[flagged]
by NoWayDude1 5y ago
[flagged]
- taeric 5y agoMore than a little unfair when the following is in the article: I’m not going to write this completely from scratch – I think parsing DNS packets is really interesting, but it’s definitely more than 80 lines of code, and I find that it kind of distracts from the algorithm. Which, seems legit to me. This article was a fun read to refresh on exactly what goes on in resolving basic records.
- dixie_land 5y agoI agree it’s a fun article but you can’t deny the title is at the very least clickbait-ish
- tptacek 5y agoI hereby do fully deny that there is anything the least bit clickbait-ish about this article, which is super interesting and all the more an achievement for its brevity. It demystifies what is the most annoying thing about trying to code the client side of DNS, and the fact that it uses the same DNS message parsing library every other Go programmer does isn't of the slightest import --- if the article hadn't used miekg/dns, some other lowbrow comment would be taking the author to task for reinventing the message codec wheel. The world needs more simple recursive lookup examples, and absolutely does not need more explication of DNS message parsing, any more than than an article talking about etcd's Raft implementation would benefit from a hand-rolled implementation of Protobufs. Yikes, everybody.
- tedunangst 5y agoIt's (sadly) telling that all the dismissals are focused on packet parsing, and not like, bailiwick checking, which is understandably missing, but also really important.
- zamadatix 5y agoThis is the key case I wish HN allowed editorializing the title. Regardless how good the article is (or isn't) when they have titles like this it's inevitable the conversation will be about how the title was overreaching. If people were encouraged to make titles like this into something like "Making a simple DNS resolver with miekg/dns in Go" or even just "A DNS resolver in Go" when posting we'd avoid this multiple times a day recurring problem. Or maybe it already is encouraged and people just aren't aware this counts as "misleading" or "linkbait" since it's not well described what the cutoff point is. Either way both titles like this one and discussions of have long gotten old. Edit: looks like the article moved to "A toy DNS resolver", excellent choice of wording IMO.
- justsomehnguy 5y ago> This is the key case I wish HN allowed editorializing the title The ability to leave a short (less than 100? 140?) description would be one the ways which would allows not to clickba^W editorialize the titles. Or the submission author can do the same by leaving the comment about it in the first comment.
- throwaway1777 5y agoLeaving description opens up other bad avenues though. Like posting an article with a description about how stupid the article or the author is.
- zamadatix 5y agoThe more general take I have seen is that it would give a "priority comment". That can result in problems like that but also more commonly just cause the comments to all act like a response to the "main" comment rather than general discourse on the topic. I can definitely see that though I also see the poster having a large amount of that control already in most cases since they get to pick the source they post.
- airstrike 5y ago> Like posting an article with a description about how stupid the article or the author is. The community can moderate that, though
- userbinator 5y agobut it’s definitely more than 80 lines of code To this old demoscener, that sounds like a challenge...
- silisili 5y agoI 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 agoI think the line count was just to emphasize simplicity and accessibility, rather than to brag.
- djur 5y agoI 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 agoCannot 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 agoSeems 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 agoIt 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..
- chomp 5y agoI smiled at this, though the Sagan quote "If you wish to make an apple pie from scratch, you must first invent the universe" springs to mind. At some point to be reasonable you have to cut off the lower layers of abstraction or else it's madness. Unbound leans on libresolv, so I don't think it's cheating to lean on external libraries - most of the hard part about resolvers is all the crufty RFCs you have to support anyway, not the basic nuts and bolts of resolving an A record.
- LinuxBender 5y agoSomewhat off-topic: Adding song [1] for completeness sake and so that it is stuck in other peoples heads too. [1] - https://amorningfilledwith400billionsuns.ytmnd.com/ https://amorningfilledwith400billionsuns.ytmnd.com/
- whimsicalism 5y agoAgree only because of how the post was titled.
- dapids 5y agoI guess we are calling paths to executables "bash code" now.
- tptacek 5y agoThis is a surpassingly facile putdown. `miekg/dns` is being used here as a DNS request/response parser library. There's almost nothing interesting about parsing DNS messages. The interesting logic in the DNS is the recursive lookup, which is the part this post captures. As far as I know (we use the same library for our authority servers) `miekg/dns` doesn't even do recursive lookups. It's not just that, though. It's also that recursive lookups are the probably the most mystifying aspect of DNS. DNS message parsers are straight-line code; there are lots of them, including in POSIX libc. What you don't have in POSIX libc is a function that does a complete from-the-root recursive lookup for a name; most DNS "client" implementations stop at "send the request to the local recursive cache". To see that function implemented in such a tiny amount of code is itself super interesting. Essentially, what you're saying is that the article disappointed you because it purported to be about making pizza, but didn't first specify how to make the oven.
- BeefWellington 5y agoI disagree. The entire client connection is being handled by the imported DNS library: func dnsQuery(name string, server net.IP) *dns.Msg { fmt.Printf("dig -r @%s %s\n", server.String(), name) msg := new(dns.Msg) msg.SetQuestion(name, dns.TypeA) c := new(dns.Client) reply, _, _ := c.Exchange(msg, server.String()+":53") return reply } func main() { name := os.Args[1] if !strings.HasSuffix(name, ".") { name = name + "." } fmt.Println("Result:", resolve(name)) } While I agree it's impressively simply laid out and as an exercise good to see people getting hands-on with underpinning protocols (I'm a fan of this), it also does its job as a follow up to her previous blog post on the subject. People taking umbrage with the title as posted here (and the original site title) are IMO not wrong. The article title has been changed to "A toy DNS resolver" now, so obviously it was contentious enough that she thought to change it.
- tptacek 5y agoWhat do you think an "entire client connection" is? It's a read and a write from a net.Conn. Read client.go's (c *Client) exchange() (the lowercase one). It's 30 lines of code, and that includes stuff like EDNS0, TSIG, and read deadlines that have nothing to do with the functionality the author is demonstrating. If the author took the time to write a 15 line roundTrip() function that called m.Pack(), udpConn.Write(), udpConn.SetDeadline(1s), and udpConn.Read(), would your argument here evaporate? Then it's not a very good argument, is it?
- deleted 5y ago[deleted]
- dang 5y ago"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- takeda 5y agoI know it starts like a shallow dismissal, but mentioning that code uses another DNS package as a dependency (miekg/dns) has a point. I originally missed that, and I believe many probably too. I don't think author can claim "in 80 lines of code" when the code depends on a much bigger library than itself.
- comonoid 5y agoIt's just a generic DNS packet parser, it has no any resolving logic (or it is not used). For learning the resolving process, it is a perfect combo.
- chlorion 5y agoThe original title was "Writing a DNS resolver in 80 lines of Go". The comment might seem like its being dismissive with the current title "A toy DNS resolver", but at the time of writing it was not just a shallow dismissal.
- tptacek 5y agoIt was a shallow dismissal then too.