I 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.
What 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?
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.