proposal: x/net/dns, vendor/golang.org/x/net/dns: new package

[iangudger]

We currently have the startings of a nice DNS parsing and packing library in net/dnsmsg.go. This is useful for building custom DNS clients and servers in Go, but is not currently exported. I would like to propose moving this functionality to x/net/dns and vendoring it so that the same version can be used in the net package.

[iangudger]

/cc @mikioh @bradfitz

[bradfitz]

Per discussion earlier, I'm okay with this.

[iangudger]

/cc @mdempsky

[mdempsky]

I'm also fine with adding/maintaining an x/net/dns package based on the internal DNS code.

I'm somewhat hesitant about vendoring it for package net though. Package net's DNS needs are pretty minimal, and the internal API is already overkill for what it needs. Simplifying/redesigning the API would let us eliminate unnecessary heap allocs.

[bradfitz]

Simplifying/redesigning the API would let us eliminate unnecessary heap allocs.

Which API? The proposed x/net/dns one or the existing internal one?

[mdempsky]

I suppose both, but I'm more interested in reworking the internal one.

[bradfitz]

As background, we have a number of forks of various DNS packages (some forked from the Go net internals) inside Google. There's increasing pushback to unify them both for sanity and security, so there's only one correct one to maintain.

I think we can make a good one that's also fast.

[mdempsky]

The main thing I want for package net is an API to incrementally walk over a DNS packet without needing to fully unmarshal it and incur unnecessary heap allocs. The current dnsmsg API could then be implemented on top of that, while package net could use it directly.

This is similar to how djbdns's client library is implemented: a low-level abstraction for treating packets as sequences of packed names and raw byte strings (used by djbdns's dnscache server), and a higher-level abstraction that understands the encoding of different RR formats (intended for use by end user applications).

[mikioh]

I'm not sure whether this proposal covers #8540 and #11160. My concerns about having a new package related to DNS stuff are simply 1) Will the package be able to support any DNS transport including plain UDP, TCP through TLS/DTLS and 2) Will the package be able to interact with the net, crypto/tls and crypto/x509 packages of standard library seamlessly and without any API breaking changes.

If this proposal covers the existing issues, in other words this proposal keeps some blueprint on good DNS package separation for avoiding circular dependency and complexity, I'd like to accept this proposal and want to merge #8540 and #11160 into this.

[iangudger]

@mdempsky: I am open to implementing that.

@mikioh: I was only proposing DNS packet packing and unpacking for now. The code in question is mostly in net/dnsmsg.go and only depends on the net package for stringifying IP addresses. I think it would probably be worth duplicating that small amount of code to allow this new package to stand on its own.

[mikioh]

@iangudger,

Thanks. I think it's fine either the new package just focuses on DNS messages and RRs as a first step, or dnsmsg as the package name for clarification.

[dgryski]

Where does https://github.com/miekg/dns fit in to this?

@miekg @FiloSottile

[miekg]

miekg/dns was forked from the std lib for this reason and was then extended to support the rest of the DNS specification. EDNS0, DNSSEC, etc. etc. Just exposing the parsing bits from std lib covers a fraction of the spec - but I can see it being useful for some people.

As for incrementally walking a message - there is no support for that in the miekg/dns although I'm happy to take patches for that.

I'm wondering about this feature request in the first place. Is the only reason for it to not depend on the 3rd party package?

[bradfitz]

@miekg, what's the CLA story for your 78 contributors? I suspect we couldn't vendor it into the standard library even if we wanted to.