Re: [Cooker] WTF?

[Vincent Danen]

On Thursday, November 14, 2002, at 03:44 AM, Oden Eriksson wrote:

- updated S6 to _show_ a fake version to fool the script kiddies even
  more, root should change this later to maybe 9.2.2?
  updated root cache file from internic

Why? They're not going to scan for a version before trying to exploit.
They're just going to hammer every DNS server they can find. I've
said it before a million times but, let's make it a million and one:
Security through obscurity is no security at all.

Yeah, but I didn't take notice before, but thanks anyway. I had to do
something...

Yeah.. the something is either a) upgrading to BIND9 or b) switching to a different software altogether. Obfuscation like this leads to a false sense of security.

Anyways, bind8 is only in 7.2 and SNF7.2... 8.0+ install bind9 by
default. I'm actually impressed that bind9 isn't affected by any of
this, but it sure makes it easy to support. Why are you still using
bind8 (I'm assuming you're not using a 7.2 box since this is on cooker).

There are people refusing to upgrade, and my bind-chroot packages are for
them. But anyway after a couple of hours fiddling with the conf files I was
able to run one of my clients 2000+ hosts zone files under 9.2.1, so I will
recommend them to upgrade.

Upgrading from BIND8 to BIND9 should be (relatively) painless. IIRC, there are a few changes to the zone files in certain situations, but I think most people shouldn't have this problem.

Actually, the real question, is why are you still using bind at all?
ISC screwed the pooch on this one big time...  I wouldn't touch bind
after this mess with a 10 foot pole.

Because I do not trust tinydns to do the job. I know a guy that has been
working several years with the dot se top domain..., and I do take his word
for it...

Ok... you don't trust tinydns to do the job. Fair enough. Can I ask why?

And, on a side note, I suppose this implies you trust BIND to do it's job. I guess that's valid. But can you trust it to do it's job *well*? And can you trust ISC to have your best interests at heart? Or do you feel comfortable with a company who's sat on a remotely exploitable vulnerability for a month, disclosed it to folks who paid for the privilege, then allowed an advisory to go out to the general public and told that same public "we'll have patches available next week"? And "oh, BTW, join our Bind Forum and you can enjoy 3r33t access to patches and fixes as well"?

Sorry. I'd rather do without some of the new fangled features in BIND and go with a product that a) has a pristine security history, b) is 100% compliant with DNS standards (if not some recently ISC-introduced RFCs which are the new-fangled features), c) has better performance than BIND, d) has an author who unequivocally would *never* bull what ISC pulled this week.

Well..., here's what I plan to do; Implement DLZ for latest bind. Packages
built with MySQL support here:

What's DLZ? And why do you need MySQL support? Isn't BIND slow enough for you as it is? =)

(conditional build, but with mysql enabled in the spec file)

http://d-srv.com/Cooker/RPMS/bind-9.2.2-0.rc1.2mdk.i586.rpm
http://d-srv.com/Cooker/RPMS/bind-devel-9.2.2-0.rc1.2mdk.i586.rpm
http://d-srv.com/Cooker/RPMS/bind-utils-9.2.2-0.rc1.2mdk.i586.rpm
http://d-srv.com/Cooker/SRPMS/bind-9.2.2-0.rc1.2mdk.src.rpm

Hmm..., I better hurry up now pack my bags instead of RPM:s ;)..., I'm bound
for London in two hours.

Have a safe trip.

--
MandrakeSoft Security; http://www.mandrakesecure.net/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}

PGP.sig
Description: PGP signature