Re: [go-nuts] dns package
Andrew Gerrand
> Hello,
>
> I've, well, forked the DNS code contained in the net package, because I
> wanted to add more functionality to it.
>
> I've created a new namespace 'dns' and added stuff.
>
> o More supported records: AAAA and DNSSEC records
> o Created a Resolver structure (instead of DNSConfig)
> o More 'dig' like output in the String functions.
> o A Query() function (instead of Exchange)
> o uint8, hex, base64 unpacking
> o started with EDNS0 support
>
> The code is on github: http://github.com/miekg/godns
> Project page (which is pretty empty atm): http://miek.nl/projects/godns/
>
> A lot of stuff still needs to be done. One the things would be
> validating DNSSEC responses. But I get the feeling I'm on the right
> track.
>
> It may be a bit early to ask, but is this a worth while addition to
> the standard Go library?
I haven't had a good look at the code, but at least some of this
functionality is desirable for the standard library. (support for
additional record types, for one)
The best way to approach integrating it is (at some point) to break
your changes down into the smallest parts and submit them as CLs.
You can also start a discussion in golang-dev about specific
implementation details.
Andrew
Russ Cox
standard library. Depending on scope it might make
sense for you to just have a separate DNS library, like
there is a separate readline library.
The long term plan is to throw away the DNS code and
replace it with calls to the host C library getaddrinfo and such,
because it's just too complicated to try to recreate ourselves.
We're getting particularly burned on OS X, where the firewall
doesn't even let us receive the UDP responses from the DNS
servers, but there are problems on Linux and FreeBSD too,
especially with not being able to resolve non-DNS names.
Using the host library will solve all of that.
The DNS code was a good bootstrap mechanism that let
us get programs running before it was possible to link with
the standard libraries in any way, but now that we have
the necessary mechanisms in place, it's a fool's errand to
try to keep up with the churn in typical host networking libraries.
We might keep the DNS code around for things
like embedded but networked systems without C libraries,
but it won't be linked in by default.
(I plan to delete it and bring it back if necessary.)
Russ
Miek Gieben
> The long term plan is to throw away the DNS code and
> replace it with calls to the host C library getaddrinfo and such,
> because it's just too complicated to try to recreate ourselves.
> We're getting particularly burned on OS X, where the firewall
> doesn't even let us receive the UDP responses from the DNS
> servers, but there are problems on Linux and FreeBSD too,
You mean TCP responses here? But still, that should all be
contained in the net package. Not in a dns package.
> especially with not being able to resolve non-DNS names.
> Using the host library will solve all of that.
I'm not sure what you mean with resolving non-DNS names?
Using getaddrinfo() will help, but stuff like DNSSEC is still
a pain.
Regards,
Miek
Russ Cox
> [ Quoting Russ Cox in "Re: [golang-dev] Re: [go-nuts] dns "... ]
>> The long term plan is to throw away the DNS code and
>> replace it with calls to the host C library getaddrinfo and such,
>> because it's just too complicated to try to recreate ourselves.
>> We're getting particularly burned on OS X, where the firewall
>> doesn't even let us receive the UDP responses from the DNS
>> servers, but there are problems on Linux and FreeBSD too,
>
> You mean TCP responses here? But still, that should all be
> contained in the net package. Not in a dns package.
No, I mean UDP responses. DNS requests are typically
made using UDP, and the Snow Leopard firewall blocks
the responses.
The functionality of the net package won't change - you'll
still be able to Dial "www.google.com:http" - but the translation
of www.google.com will rely on system-provided libraries.
Package net is about networks in general; not all the world
is IP and not all the IP world is DNS.
But if you rely specifically on DNS - for example, you need
to look up MX records because you're an SMTP client -
then it seems fine to need to import a separate package.
>> especially with not being able to resolve non-DNS names.
>> Using the host library will solve all of that.
>
> I'm not sure what you mean with resolving non-DNS names?
Bonjour, /etc/hosts, and so on.
> Using getaddrinfo() will help, but stuff like DNSSEC is still
> a pain.
Wouldn't getaddrinfo be in charge of validating DNSSEC
signatures? I'm just a lowly application and want to know
an IP address for www.google.com. If some protocol that
getaddrinfo uses happens to have cryptographic signatures
as part of its implementation, I expect getaddrinfo to take
care of checking them for me.
Russ
Miek Gieben
> > contained in the net package. Not in a dns package.
>
> No, I mean UDP responses. DNS requests are typically
> made using UDP, and the Snow Leopard firewall blocks
> the responses.
Really? Wow.
> >> especially with not being able to resolve non-DNS names.
> >> Using the host library will solve all of that.
> >
> > I'm not sure what you mean with resolving non-DNS names?
>
> Bonjour, /etc/hosts, and so on.
Ah, ok.
> > Using getaddrinfo() will help, but stuff like DNSSEC is still
> > a pain.
>
> Wouldn't getaddrinfo be in charge of validating DNSSEC
> signatures? I'm just a lowly application and want to know
> an IP address for www.google.com. If some protocol that
> getaddrinfo uses happens to have cryptographic signatures
> as part of its implementation, I expect getaddrinfo to take
> care of checking them for me.
The DNS gods have not yet figured out how that would work. Previously
(RFC2535) you would not get an answer if the validation failed. The
current school of thought is that applications may want to validate
the chain-of-trust themselves.
I will continue to develop a dns package and will try to submit small
fixes to the current net/dns package included in Go.
Thanks for the answers,
grtz MIek