Potential 0-Day Vulnerability For BIND 9 187
Morty writes "BIND, the popular DNS server software, has been crashing all over the Internet. The root cause is believed to be a 0-day vulnerability in BIND's resolver. The ISC has issued an alert. Quoting: 'An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit.'"
To the Red Phone! (Score:4, Funny)
Alert DJB at once!
10 years ago (Score:4, Informative)
Re:10 years ago (Score:5, Informative)
Another small DNS server is MaraDNS. It's considered a good alternative to BIND [google.com].
Being a lot smaller, it's easier to secure.
If you're just running a DNS cache on your desktop, check out dnsmasq. Click to install [deb](Deb/Mint/Ubuntu)
Re: (Score:2)
etckeeper (Score:5, Informative)
By the way, another thing people who are wont to mess with their /etc should keep in mind is etckeeper. It versions your /etc, by default in bazaar, but it's also supposed to work with git, hg, etc. It has triggers set so every time you install something, it does an automatic checkin.
You can also manual commits, too, along with a message.
Good for people who want to know what the config files looked like when they were working a week ago.
Click to install [deb] (Debian and friends)
Re:etckeeper (Score:4, Interesting)
Awesome!!
I've been known to keep subdirectories of /etc as SVN repository checkouts, but that grabs the whole thing!
The only thing I'd be worried about is accidentally uploading sensitive data (hashes and such).
Re: (Score:2)
Yeah, I used to use the old-school ci and co commands from rcs [deb] (anybody remember that?).
In fact, you can still use it to version specific files you care about without pulling in everything.
One thing which is an annoyance for me is the huge lines of binary represented as text in Virtualmin config files. Haven't found a solution to that.
You're right about the sensitive data. Anybody have a good solution?
Re: (Score:1)
I thought it was quite pleasant to setup.
I use it at work, where we have 2 sites connected with VPN (and each site with dnsmasq), and it works fantastically as a DHCP server, and dns server, allowing all computers to be accessed as computer.sitename
Re: (Score:2)
Re: (Score:2)
Better yet use Unbound resolving only nameserver since it supports signed zones.
Re:10 years ago (Score:4, Informative)
And, of course, there is Power DNS [powerdns.com], another excellent DNS server.
Then again, there's something to be said for being able to set things up using only a three-line configuration file [maradns.org] and a 64k binary works nice for embedded places like OpenWRT where Unbound and PowerDNS won't fit.
- Sam
Re: (Score:3, Interesting)
Your information is out of date; I completely, from scratch, rewrote the recursive code of MaraDNS starting four years ago with far cleaner code.
That code was declared stable over a year ago and looking at its source code [maradns.org] won't make you blind.
- Sam
Re:10 years ago (Score:4, Funny)
It's hard to go wrong with DJB*.
Re:10 years ago (Score:5, Funny)
Re: (Score:2)
Glad to know I'm not the only one who thinks DJB makes no sense at all. Every time I see it it takes me half a freaking hour to figure out how to update a zone.
Re: (Score:2)
I think GP was referring to how inflexible DJB the person can be. But certainly their comment could be used to refer to the software as well.
Not only did DJB reject the design and development practices that left BIND such a threat but he also rejected a number of usual conventions around software management/installation/licensing. In his defense, he did it because he believed the conventions were bad. His own version of things makes sense and works well, but it's definitely weird if you're coming new to
Re: (Score:2)
Re: (Score:2)
Yea, convention is overrated. We should all do things the way we want, back like the good old early 90s! Clearly things were better that way. Fuck standards and conventions.
Re: (Score:2)
Wasn't there some sort of license problem with DJB stuff? Like the slowness of Java applets in the early 1990s, I don't think Slashdotters will let him live that down.
Re: (Score:2)
I don't know about his DNS server, but qmail had some goofy license that meant everything was just a series of patches.
He's since released it into the public domain though.
Re: (Score:1)
He had no license, believing that having no license and no copyright meant it was in the public domain. US law says otherwise, and DJB disagreed. Unfortunately, that put the software in limbo.
Eventually, a license permitting distribution of unmodified source was added. This, of course, meant compiled versions and built-in tweaks to make it work with certain compilers (like GCC) and distributions were not permitted to be distributed. Patches were granted as an exception. Distributors were too lazy to bu
Re: (Score:3)
Re:10 years ago (Score:5, Informative)
The major problem with Qmail was it's design simply didn't take into account the possibility of a bad return address. The downside was that it couldn't bounce during reception and so was forced to generate a bounce message instead and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers. The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.
In short: it was secure for only some definitions of secure and for everything else DJB ignored the problem.
Re:10 years ago (Score:4, Insightful)
and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers.
Theoretically, that is possible. In practice I haven't seen spammers use that mechanism.
I used to run qmail and I have seen it used for that.
The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.
A lot of people are irrationally against djb in any way. He's become like the president, every time something goes wrong people blame him. Those blacklists you speak of are less about addressing an operational problem and much more about irrational dick waving.
It's not irrational if you observe a problem only to be ignored. As I said earlier I used to run Qmail and I did so because of it's security benefits and while Qmail didn't get my box rooted the same way sendmail did, it still had it's problems. I have since moved to postifx and now have a que of 0 to 10 messages instead of the 300 to 1000 I had under Qmail despite the fact that I have 3x the number of domains and 5x the number of messages than I did before.
qmail backscatter (Score:4, Interesting)
Did a little looking into it and, though I'm generally a fan of DJB's wares, unpatched qmail does indeed have the problem of accepting all mail for configured domains, regardless of localpart (box) validity. Which means DSNs will be sent for bad addresses, and since SMTP provides no way of validating senders, backscatter occurs. This is the term for it, by the way.
I've seen plenty of spam using the mechanism. It's a real problem.
Patches are available. But, yeah, DJB's licensing made even patching problematic for the longest time. Thankfully, he's conceded on that point. Which suggests to me he's not dogmatic or unreasonable, just rigidly principled.
I run Postfix, too. Love it. The licensing limbo was part of my decision to go with Postfix, though there were a number of factors. But I still run DJB's tinydns and dnscache.
Re:10 years ago (Score:4, Interesting)
Don't get me wrong, djbdns is an excellent DNS server. Unfortunately, it hasn't been updated for over 10 years and, since then, three different security holes have been discovered the djbdns package, the root server list has been updated, errno has been changed to make Linux more thread safe (requiring a patch to compile it), and so on.
djbdns can work -- but it requires patching by hand or using an unofficial fork like Zinq [sourceforge.net] (which appears to still be supported -- the last release was done this year).
(I can also murmur darkly about the fact that djbdns uses a circular queue instead of a LRU for its cache, its lack of a Windows port, its need to use external helper programs to configure the server, etc., but, then again, its core recursive binary is even smaller than MaraDNS 2.0's tiny recursive binary. And three security bugs in the last decade is better than the 13 security issues in MaraDNS I have had to patch against.)
Re: (Score:3, Informative)
Please stop spreading FUD. There have been 0 remote security holes discovered in djbdns.
Please lay off the crack, wake up, and smell the coffee. This kind of denial is flat-out dangerous.
I have a blog entry detailing the three security holes in djbdns [samiam.org] and DJB paid the $500 security hole prize [gmane.org] for djbdns years ago.
The most dangerous hole in an unpatched djbdns 1.05 install is the TCP "packet of death" that forces dnscache to restart (since SIGPIPE isn't caught by dnscache). I really should file a CV
Re:10 years ago (Score:5, Informative)
This particular vulnerability applies only to BIND9 operating as a recursive resolver. BIND9 operating in authoritative mode, similar to how TinyDNS operates, is unaffected. Had you properly deployed BIND9 for the same purposes you are using TinyDNS you would not had been impacted by this issue.
Re: (Score:1)
NSD (Score:4, Informative)
A confusing summary on /., let me try to do better (Score:5, Informative)
BIND [isc.org] is written by Internet Systems Consortium [isc.org] aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center [sans.edu] aka ISC, a project of the SANS Technology Institute [sans.edu]. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.
The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313 [isc.org].
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.
Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.
This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.
Internet Software Consortium also offers support [isc.org] for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.
Re:A confusing summary on /., let me try to do bet (Score:4, Funny)
Your understated discretion just takes my breath away.
Re: (Score:2)
when ever I think of BIND8, I think of my .sig:
Re: (Score:3)
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something,
Something like cause a denial of service?
Re:A confusing summary on /., let me try to do bet (Score:4, Interesting)
yes yes, but thats very limited. Yes, you can deny service.... but it can be started back up. The only loss is availability of the service, the integrity of the service is uncompromised. It isn't allowing someone to make you serve up their data, it isn't allowing anyone to dump data they shouldn't have, it isn't allowing them to change, erase or anything your data.
Essentially... a DDOS means you are hosed until they stop or you can upgrade... the term 0-Day tends to be used to refer to actualy security issues, where the denial of the service is the least of your worries. Patching isn't good enough because, they got a window in, and could have installed a root kit.
Re: (Score:2)
Re: (Score:1)
That's an excellent post, Above.
thanks!
Re:A confusing summary on /., let me try to do bet (Score:5, Interesting)
Thanks for the clear explanation.
If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.
Very true. Its funny, that this morning I had applied security patches to a debian stable box and thought "hmm, looks like BIND is getting fixed, wonder what thats about" before this even got posted to slashdot.
Re: (Score:2)
Its funny, that this morning I had applied security patches to a debian stable box and thought "hmm, looks like BIND is getting fixed, wonder what thats about" before this even got posted to slashdot.
Same here. Debian rules! :)
Re: (Score:1)
Re: (Score:3)
I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.
If you go back to ISC's Software Support [isc.org] page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went ou
Re: (Score:1)
Re: (Score:2)
To be honest I completely hate ASSERT-style checks, particularly in multi-user systems. One single logic mistake and boom goes the whole server. With exceptions you can at least have a gradual panic. But when you so often resort to pointer-magic and any unterminated string is a recipe for chaos, well... Though it would be nice if exceptions actually worked, which they don't in C++. Try/catching into some third party code and it'll still segfault on you, completely ignoring your attempt to catch any and all
Re: (Score:2)
More to the point, since we have an advisory about it and there's a patch, it can no longer be considered zero day. A true zero day vulnerability is one that only the blackhats know about. Expanding that to include a vulnerability that the vendor doesn't yet understand well enough to patch makes sense. But anyone using the term for a bug that has a patch out to fix it is just being over-dramatic.
Re: (Score:2)
Submitter here. Comments:
0-day refers to the time when the bug is first exploited relative to when it is patched by the vendor. It has nothing to do with whether or not the exploit yield unauthorized access. It is entirely possible to have a 0-day DoS attack.
There was no evidence on whether or not the bug was triggered deliberately. Hence why the summary referred to it as a "potential" 0-day, and said the problem "is believed to be" a 0-day vulnerability.
At the time crashes were initially occuring, no p
Re: (Score:1)
Yeah, but only the sheer incompetence a multi-billion dollar corporation like Microsoft could produce the level of spectacular FAIL needed to let the following kind of vulnerability go unaddressed for DECADES..
http://www.kb.cert.org/vuls/id/951982
Microsoft Windows UDP packet parsing vulnerability
You have to admit being able to get root by sending malicious packets to a CLOSED port on a machine is just so awesomely FAIL, BIND's little DOS exploit pales in comparison.
Re: (Score:2)
that link you posted says it was patched 2 weeks ago. It makes no mention of the date the exploit was found. How do you know this was part of the software for decades?
meaning of zero-day (Score:2)
Different from my understanding. You're thinking of 0-day warez. Here, WP explains it pretty well [wikimedia.org]:
Re: (Score:2)
I've never known 0-day to mean that. 0-day has to me always meant an exploit in the wild before the author is aware of it vs. an exploit taking advantage of a bug that was fixed a month ago but people haven't applied the patch.
isc.org Slashdotted. Good job! (Score:2)
Someone want to set up some mirrors?
Re: (Score:1)
Just updated my Debian boxes with apt a few minutes ago... I suppose you could always grab the source from a distro and compile.
Re: (Score:2)
Hurrr, well done guys. Now nobody can download the patches.
Right now the ISC website is still responding.
At least some distributions have already incorporated the patches; for instance, for Debian upgrading simply involves doing an 'apt-get update', 'apt-get upgrade'.
If updated packages are available, it's generally better to get the packages for Bind9 from the distribution rather than recompiling.
However the "fix" in this case may not entirely fix the problem; the current repair withholds the DNS response and will keep Bind9 from crashing and shutting down, but th
Re: (Score:3)
Sounds like a GRAND idea...
APK's monolithic hosts file (Score:5, Funny)
Re: (Score:2)
lol, +1 funny.
I'm actually kind of surprised he hasn't stopped by to grace us with his randomly spaced and bolded wealth of knowledge...
Re: (Score:2)
Re: (Score:2)
I actually went and downloaded a 16k line hosts file and started using that after seeing that post, you know just for trying it out.
some sites load up faster. I just googled for some file that had been updated last month.
Re: (Score:1)
monolithic hosts file is looking pretty good at the moment
Yeah, and when my car runs out of gas I'll just push it wherever I want to go.
ZOMFG the internets are all crashed? (Score:2)
Tip of the iceberg (Score:5, Insightful)
The "assertion"-problem is only tip of the iceberg.
If an assertion fails, this usually means that someone managed to make the code behave in an unintended way. Since the affect occurred simultaneously at several providers all over the world, this indicates a coordinated attack. The chances are real, someone managed to exploit a buffer overflow (or similar) in BIND.
So we have to look seriously into the possibility that people have a way to execute code with the same permissions as BIND has.
When i got the information this morning, this was an alert topic.
Yours, Martin
Re:Tip of the iceberg (Score:5, Informative)
The "assertion"-problem is only tip of the iceberg.
If an assertion fails, this usually means that someone managed to make the code behave in an unintended way.
Except that the assertion isn't the problem. The problem is that BIND allows bad data into its cache. The assertion detects this and crashes BIND before the bad data becomes an exploit.
Now, there still may be a way to execute code using this method, but the assertion has alerted everyone to this problem so I expect this particular problem to be solved quickly. And thanks to the assertion-crashes, people will be forced to upgrade rather than running a vulnerable version for the next 5 years.
I'd prefer software without bugs, but since that's impossible, I'll happily take BIND.
Re: (Score:2)
The assertion is a problem.
Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.
At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.
Re: (Score:2)
The assertion is a problem.
Deployed code with asserts in it is crap, and would violate any contract I've worked to since 1995.
At least this was just teh interwebs that it broke. If it had been safety-related, someone would be ducking under their desk trying to call their lawyer.
So your code, that you make sound more important and/or safety related than DNS, doesn't have any failsafes? Really?
Re: (Score:2)
My code, which sometimes is the difference between life and death, considers all possibilities to be nominal cases, and deals with each equivalence class accordingly.
People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.
why? (Score:2)
People who use asserts in fielded code are either (1) lazy or (2) dumb or (3) cheating their employers.
Assuming performance isn't a problem, why wouldn't you leave them in on the off chance that you made a mistake in a corner case somewhere?
Re: (Score:2)
The fact that they're even there means you know there's a vulnerability, and you know you don't have a viable way to deal with it, and that your users will, eventually, run into it, probably in a situation where it causes them way more grief than the rest of your code is worth.
Just using NDEBUG to turn them off is passing the buck to the rest of the code to crash cryptically instead of crashing identifiably, so it's even worse.
Re: (Score:2)
So you think assert() is a substitute for proper exception handling? Really?
In this case specific case, sure, why the hell not? Its DNS, and you've found that you're in an impossible state. What else are you supposed to do? Even if the process hasn't been compromised, by the nature of the assert you've failed and don't know how to recover. Do you want to keep on serving DNS, assuming the process is in a state where it is fine to keep on trucking? Or maybe enter a do-nothing failure mode, which is just as useful as going down hard, but with the added bonus that the process is ex
Re: (Score:3)
>exceptions you haven't prepared for
there's your problem right there.
when you go through your code and you see an assert, or something that does the same thing, you're not done coding.
Open resolvers (Score:2)
Re:Open resolvers (Score:5, Insightful)
More likely, the unusual TXT lookups were someone streaming IP over DNS.
Re: (Score:1)
someone streaming IP over DNS
If I owned a gun...
Re: (Score:1)
Re: (Score:2)
Might have been a cached data block for a botnet payload. as a DDOS, it doesn't make any sense, because you'd have had to put that TXT record on the retrieved host in the first place.
I don't get it... (Score:1)
Re: (Score:2)
In this case, it's a simple as not using an assert, particularly as an input validator...
Seriously, are they fucking kidding with that? Do they also hardcode backdoor passwords?
Grep all your code for assert, and, if they aren't wrapped in #ifdef DEBUG or something similar, replace them with something useful.
Re: (Score:2)
How hard is it to write a DNS server without any vulnerabilities? I know it's complex, but still, come on. It's only the backbone of the Internet we're talking about.
The usual suspects: enterprise and legacy. Rather than just being a passive lookup engine, BIND has all kinds of extra interfaces and message-passing schemes that keep secondaries in sync with the master and allow automated processes to update and reload zones semi-automatically. I suspect there are also a bunch of legacy record types and zone file syntaxen that need to be supported.
It's similar to (but not as bad as) the problem with mail transport agents (MTAs aka SMTP servers). To be feature-complete and
Security tip of the day: Do not use BIND (Score:2, Informative)
It has an atrocious security history. Seems the rewrite did not accomplish much. Or if you have to use it, lock it into a VM, preferably qemu, so that you get at least some level of isolation.
Re:Security tip of the day: Do not use BIND (Score:5, Informative)
There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.
ISC is also completely open about security issues [isc.org], listing them all on the web site and registering them with the CVE Registry [mitre.org].
As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.
BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.
I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10 [isc.org], which should be yet another large leap forward.
Re: (Score:2)
Well, as the current problems show, BIND9 still does not get it quite right. I agree that it is better. If BIND10 can make the same step as was made from 4/8 to 9, then BIND10 will finally be a good piece of mission-critical server software. And, yes, that is what is it and has to be. So comparing it to "most other open source projects" is bogus. Not even apache is that critical. Maybe OpenSSH, but it has a truly amazing security record, which certainly is no accident. BIND still has to get there.
I am not s
Re: (Score:2)
I'm confused why BIND would be more critical than Apache (to use your example).
DNS is, from the start, a robust, distributed system. If you have 4-6 name servers for your domain (as you should) and one is down for any reason (network unreachable, server dead, BIND crashed, whatever) users _should not notice_. Caching resolvers will automatically query other name servers, life will move on. Compare with widely used software such as Apache, Sendmail, Firefox, when those fail typically a user notices.
Indeed
TreeWalk (Score:3)
I use TreeWalk. Since it's an implementation of BIND, do I need to apply this patch to it, and if so how?
Re: (Score:3)
Re:Impossible! (Score:5, Insightful)
It's open source, and has had years to mature...so many eyes on it that this couldn't possibly happen.
We don't even know what is happening yet. Maybe it's just a DOS, maybe it's a potential exploit. What we do know is that no-one has any need to put recursive DNS servers on the internet unless they are running an ISP or a DNS service.
Re: (Score:2)
Re: (Score:1)
Although we do know that if this was in a Microsoft product you wouldn't be making such an excuse.
No excuse. This is a disaster and I'm not excusing it. However it doesn't affect most people who setup their systems right. ISPs, DNS service providers, and anyone who has to let random strangers on their network may well be in trouble with this.
Of course if this was Microsoft it would no doubt be an easy remote execution of arbitary code but only crazy people trust windows with something as critical as DNS in the first place.
Re: (Score:2)
No, we don't.
Re: (Score:2)
As opposed to the years of paid professionals eyes on Windows?
Re: (Score:3)
Re: (Score:3)
Re:Open sores == fail (Score:5, Insightful)
Re: (Score:2)
I am confused - which was it designed to do: allow invalid data in the cache, or die when it found said invalid data in the cache? One or the other of those is a bug, not a design choice.
Re:Open sores == fail (Score:4, Insightful)
Microsoft code would typically leave out the assert, and happily stumble along. At least with the assert, you know what AND WHERE the Bad Thing (TM) happened, and have a clue as to where to look to fix it.
Re:Open sores == fail (Score:4)
First, this has nothing to do with Microsoft, so there is no need to drag them into it.
Second, I am not questioning the need to test for errors, or that sometimes the correct thing to do when an error is encountered is die. I am challenging your position that overall the software is doing what it was designed to do and this is not a bug. The assertion itself is fine - there are reasons why the cache may have been corrupted and you want to kill the program (hardware error, tampering with files, etc). However, in this case the check should have been done BEFORE the data was put into the cache, when the correct response would have been to simply reject the message. Failure to do that check is a bug.
Re: (Score:2)
Also, note that in this case the assert did NOT tell them 'where the bad thing happened'. If it did, it would not be 'an as-yet unidentified network event'. The assert, in this case, is simply saying 'at some point in the past a bad thing happened, and I just figured that out now'.
Re: (Score:2)
Re: (Score:2)
So you're releasing your debug version of the code as a product? Nice.
Re: (Score:2)
Repeat after me:
"There are no impossible conditions in input."
"There are no impossible conditions in input."
"There are no impossible conditions in input."
"There are no impossible conditions in input."
. . .
Re: (Score:3)
Open sores software == fail. Once again full of security holes that the "many eyes" failed to spot.
Unlike windows which never has remote crashes or remote execution of arbitary code problems. Tell me does microsoft.com still block ping? Why is that again?
Re: (Score:2)
Hilarity ensues [netcraft.com] :P
I'm joking though... because that's just one tiny piece. The rest of the infrastructure is indeed eating it's own dogfood - either directly, or via "citrix netscaler"
Unbound, not NSD (Score:2)
Unbound, also from NL Netlabs, is a recursive resolver. NSD is an authoritative server.
The problem is with Bind as a recursive resolver, not as an authoritative server.