Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Josip Rodin (joy@entuzijast.net):
> Why is this phrased in a way that it prefers BIND as a recursive resolver,
> when that same software was *only just* patched to be acceptable for the
> same purpose?
Although I'm not much of a BIND9 fan -- it remains RAM-hogging, slow,
overfeatured, and questionably architected (monolithic) -- but it _was_
a good, from-scratch rewrite of the awful spaghetti code that was BIND8.
My understanding is that the resolver in glibc is the last piece of
BIND8 code in standard Linux and BSD systems, so the current meltdown
doesn't surprise _me_, one bit. (For years, I've been saying on
http://linuxmafia.com/faq/Network_Other/dns-servers.html that "Some BIND8
code still lives on, in the DNS resolver library shipped with typical
Linux and BSD distributions. This is regrettable, but the occasional
security failures in that codebase should not be attributed to BIND9.")
When I last researched alternative resolver libraries, I turned up:
o adns http://www.chiark.greenend.org.uk/~ian/adns/ GPL, C
o Ares ftp://athena-dist.mit.edu/pub/ATHENA/ares/ MIT/X, C
o FireDNS http://firestuff.org/projects/firedns/ GPL, C
o ldns http://www.nlnetlabs.nl/ldns/ new-BSD, C
o Net::DNS http://www.net-dns.org/ GPL, Perl
o Poslib http://posadis.sourceforge.net/poslib/ GPL, C++
Reply to: