Slashdot Mirror
DNS Cache Poisoning Update
dhammabum writes "Todays SANS internet storm handler has put up an excellent update of the DNS poisoning vulnerability currently doing the rounds. The main points are that only Windows DNS servers are vulnerable (degrees of vulnerability depending on patch level), provided you are not running an ancient version of bind. Also bind4 and bind8 do not clean poisoned caches if they receive them from a poisoned Windows DNS server but bind9 does."
"If you don't like windows don't use it"
Or then telling me, when they find out I don't use it, that I've somehow forfeited the right to complain about it anymore; or trying to hold Microsoft blameless for their security holes because the people who run Microsoft software do so by "choice" so its the users own fault, and they are just hurting themselves.
But then I keep finding that despite not using Microsoft software, I get negatively impacted by it anyway. Because the Code Red slaves on the network are bombarding me with a constant light DOS looking for that index server or whatever. Because I get bombarded with email viruses and spam from zombie PCs which, while harmless to me, make my email account less useful. Because my DNS server is running Windows.
Lovely.
So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this?
so much more reliable than BIND
I have never, not once, ever had BIND fail. I doubt I'm the best DNS admin anywhere, so I imagine it works well for a lot of other people as well.
Why am I putting my users at risk?
Because my secondary DNS servers, provided by my registrar, are out of my control. I can't install rsync on them to support the functionality that Dan left out of djbdns.
If you're a DNS admin, don't waste your time with bugs from the 1990's.
I'll agree with that. Upgrade to the most recent version of BIND and get on with life. OpenBSD's support of that policy is a pretty strong endorsement.
Dewey, what part of this looks like authorities should be involved?
Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car.
Nah, It'd be like blaming Ford if they sold all cars without oil in them and had, on page 545 of the 2000 page manual, directions to add oil before use.
Sure, they tell you and it is documented, but you shouldn't have the server install insecurely by default. The default should be secure, and then you need to enable the services you need. Less user friendly, more secure - that is why it isn't adopted by MS. They made a conscious decision to make it insecure (but easier to use). That is why MS bashing is justified.
Learn to love Alaska
In my experience, software issues occur for one of two reasons:
(1) "Broken" code:.....
(2) Bad communication / misuse of code:....
You left one out:
(0) Bad Design: The code does everything you intended it to do and the users are using it properly, but you didn't think of all the possible states in which the code could find itself and decide what to do about them.
This is often lumped in with (1), but shouldn't be IMHO. It's one reason I think that comments in code are valuable (as are formal design documents) since it forces the person, or people doing the design and coding to restate their intentions in at least a couple of different ways.
I have written and worked with well written specs and they tend to reduce the number of pure coding errors by leaving less to the imagination of the coder. Well written specs can still fail to account for all possibilities however and that's a good reason to have meaningful design discussions (rather than the formally mandated ones that people attend these days in body but not mind).
There are many people today who think of themselves as ace coders. The world would do well to have more people who are design experts who don't practice coding at all. The two disciplines complement one another well.