x/net/dns/dnsserver: new package

[iangudger]

x/net/dns/dnsmessage contains a DNS library (proposal #16218). A DNS server based on it would be very useful. In addition to the more traditional uses for a DNS server, having one in x/net would improve the story around using net.Resolver.Dial to do custom DNS.

[bcmills]

CC @mikioh @bradfitz @ianlancetaylor for x/net

[andybons]

This seems reasonable.

[gopherbot]

Change https://golang.org/cl/107306 mentions this issue: dns/dnsresolver: new package

[gopherbot]

Change https://golang.org/cl/51631 mentions this issue: dns/dnsserver: new package

[gopherbot]

Change https://golang.org/cl/197897 mentions this issue: dns/dnscache: new package

[FiloSottile]

Implementing a DNS server, cache and resolver can mean a lot of different things, some of which are a major undertaking that would definitely require a design doc. I feel like this proposal lacked the detail to be properly reviewed.

For example, a resolver can be a stub resolver, like what we already have in the standard library, or it can be a full caching and recursive resolver, which needs to handle zone cuts, cache expirations, CNAME logic, and more. A server can be just a skeleton that takes requests and returns answers, or something that constructs answers from a zone file, based on a myriad of rules. Every part of this also has a deep stack of security concerns. DNS has more RFCs than TLS and HTTP put together, as well as a whole catalog of implementation lore and quirks.

At the widest interpretation, this proposal is adding as much scope as a project like Unbound. If the scope is smaller, we need a specific narrative for where the line is, or it will keep getting pushed by every user that needs a little more.

Personally, having worked on an authoritative DNS server before, and having contributed a lot to github.com/miekg/dns, I don't think this should live in the Go project repositories. It's one of those things that we don't have the resources to develop to address every use cases, and that doesn't have a clear-cut subset of functionality we can focus on.