Slashdot Mirror

The real answer (that can't be implemented because nobody will put in the effort) is that messages should be stored and kept on the senders side. Push technology died ages ago, except for email/usenet. It should die for email as well (don't know so much for usenet, though).

If the 0.1 GB of photos you want to send from work to someone's dialup (I'm in tech support, this happens at least a few hundred times a day) had to be stored by your company, your ass would get fired once you filled up the email server with that trash. And the dialup user on the other end would just laugh and not care. If the message you sent were actually important, the receiver could actually decide to... (gasp!) archive it!

Of course, this means spammers have to keep a server running constantly to serve spam. As you can imagine, they would try to use botnets. But these are always moving targets, most people infected are only online for an hour or two a day. Then the spam goes away. As you can imagine, this shrinks the window of opportunity down significantly for spammers and it means they will have to root actual 24/7 boxes. This usually involves some actual skill, and is usually detected, and will often result in prosecution (depending on their location, of course).

Basically, as usual, djb is right, but we can't use his ideas, again, because people are lazy. :-(

According to DJB, you don't even have to do that in a lot of cases:

Please don't sign any contracts that prevent you from authorizing these activities! In several cases I've said something like

IPv4 packets would be turned into IPv6 packets in the IPv4 subset of the IPv6 address space when they left the IPv4 endpoints, and then turned back to IPv4 if the destination didn't support IPv6.

Unfortunately the IPv4 address space isn't embedded in the IPv6 address space in the way that you suggest. Dan Bernstein pointed out many years ago that this was a mistake.

"I think this article by Dan Bernstein is a pretty good read regarding this subject - http://cr.yp.to/djbdns/ipv6mess.html"

Bernstein is quite right as always, but you don't care and unlike Bush, don't need to panic. There's lots of milage left in the protocol and those that think we're running out of addresses just aren't looking at the packet headers. They're in meetings instead.

http://rs79.vrx.net/interests/computers/net/v6failure/

This is a non-issue.

DJB said it best at http://cr.yp.to/djbdns/ipv6mess.html Why switch from an Internet with a billion people on it to one that has nobody on it that can't be reached by IPv4?

I think this article by Dan Bernstein is a pretty good read regarding this subject.

I noticed that you were careful to refer specifically to "consumer" CPU manufacturers. However, 8-bit, 16-bit, and 32-bit CPUs are still in widespread use in both consumer and industrial (embedded) electronics, and there's no reason to expect that electronics manufacturers will start using 64-bit processors exclusively, when 32 (or-fewer) bits-per-word will suffice.

Prof. Daniel Bernstein came up with a decent integer time representation called TAI64, and a public-domain library for using this representation. Using it requires getting over one's dislike of his personality, but would mostly solve the 2038 problem long before the year 2038 hits.

I noticed that you were careful to refer specifically to "consumer" CPU manufacturers. However, 8-bit, 16-bit, and 32-bit CPUs are still in widespread use in both consumer and industrial (embedded) electronics, and there's no reason to expect that electronics manufacturers will start using 64-bit processors exclusively, when 32 (or-fewer) bits-per-word will suffice.

Prof. Daniel Bernstein came up with a decent integer time representation called TAI64, and a public-domain library for using this representation. Using it requires getting over one's dislike of his personality, but would mostly solve the 2038 problem long before the year 2038 hits.

The talk referenced by Schneier in his essay as being the one that publicly disclosed the backdoor was given by two Microsoft researchers. So all the "OMG micro$oft iz so stoopid" posts might be a bit .... misdirected.

A link to DJB's essay on the issues of IPV6 adoption feels obligatory here.

That appears to be his take on 'software law', his own page at http://cr.yp.to/softwarelaw.html shows his position. Hoever, from an open-source point of view, notice how how he doesn't allow for distributions of modified versions of his software?

"Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use ... As long as you're not distributing the software, you have nothing to worry about. ".

Right, really open source that. He's asserting the absence of a license allows only the distribution of patches (which could well be true) but not particuarlly open-source like! Critically, you have no redistribution rights to the program itself from the absence of a license. Indeed, I think DJB and RMS are in agreement on this point.

DJB did, however, allow limited redistribution, so long as the tar.gz's were the specific tar.gz's that he distributed with that exact MD5 checksum. The only precompiled binaries you were permitted to distribute "if (1) installing the package produces exactly the same /var/qmail hierarchy as a user would obtain by downloading, compiling, and installing qmail-1.03.tar.gz, fastforward-0.51.tar.gz, and dot-forward-0.71.tar.gz;" (same page).

Again, no redistribution of modified source or binaries derived from modified source - definintly not open-source.

(That same page, now, merely states the final .tar.gz (1.03) is in the public domain)

That appears to be his take on 'software law', his own page at http://cr.yp.to/softwarelaw.html shows his position. Hoever, from an open-source point of view, notice how how he doesn't allow for distributions of modified versions of his software?

"Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use ... As long as you're not distributing the software, you have nothing to worry about. ".

Right, really open source that. He's asserting the absence of a license allows only the distribution of patches (which could well be true) but not particuarlly open-source like! Critically, you have no redistribution rights to the program itself from the absence of a license. Indeed, I think DJB and RMS are in agreement on this point.

DJB did, however, allow limited redistribution, so long as the tar.gz's were the specific tar.gz's that he distributed with that exact MD5 checksum. The only precompiled binaries you were permitted to distribute "if (1) installing the package produces exactly the same /var/qmail hierarchy as a user would obtain by downloading, compiling, and installing qmail-1.03.tar.gz, fastforward-0.51.tar.gz, and dot-forward-0.71.tar.gz;" (same page).

Again, no redistribution of modified source or binaries derived from modified source - definintly not open-source.

(That same page, now, merely states the final .tar.gz (1.03) is in the public domain)

From http://cr.yp.to/qmail/dist.html:

I hereby place the qmail package (in particular, qmail-1.03.tar.gz, with MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) into the public domain. You are free to modify the package, distribute modified versions, etc.

Mail: qmail pretty much rocks. Problems with Exchange start with the JET DB it is built on, and go downhill from there. (Note that this is from the view of operations/support, not so much users unless they need support)

Any iCal standard server is better as they're not running in the "integrated" Exchange JET DB. (did I mention that Exchange's problems start with the JET DB?)

Clients, that's MS's strong point. They managed to put some integration on the client side for proprietary (of course) data and create an interaction between calendaring, email, and address books (the lynch pin). No other client I'm aware of has combined LDAP (address book) with mail and iCal support that I'm aware of, except maybe Apple which still has separate apps.

And you need other nameservers to implement it, but the authors of at least two of those (djbdns and PowerDNS) don't think it's worth the effort.
You can read their motivations here and here.

You're not the only one that's been faced with the prospect of swallowing the end result of some dumb/greedy corporate lawyers. You can "comply" with the agreement, if you have to, and possibly keep your job while showing them how idiotic the policy is — especially if you can convince some coworkers to do the same.

Dear Ms. Tarzian

As an academic with publications, I find
the quality of the proofreaders and of the typesetters to be
abyssimal. I can accept that from a non profit journal that lacks manpower
but not from well known publishers (Elsevier cough Elsevier) that are sitting
on a pile of gold but are too cheap to hire good proofreaders and good typesetters.
Of course it is cheaper to hire monkeys typesetters and not to hire proofreaders.

Just read http://cr.yp.to/bib/20050504-copyediting.txt
to see what kind of work knowned publishers do. And it is a best case scenario:
cosmetic changes that neither add nor remove anything. In many cases, the typesetters
destroy the paper while editing it and since he doesn't indicate his changes, you have to reread
it line by line.

Slide 10: http://cr.yp.to/talks/2007.11.02/slides.pdf 2007.11: $500 ! $1000; qmail placed into public domain.

Security at any cost? Easy. Unplug your computer. Done.

Getting the job done actually counts for a lot, you know.

Also, "security at any cost" would mean it wouldn't be a leading source of backscatter spam. Security at any cost would also mean that his array handling code would be very throughly checked to be secure no matter what enviroment it was running in. However:

"In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits. " -- http://cr.yp.to/qmail/guarantee.html

(in reply to http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html )

I very much doubt anyone bothers to put limits on processes (we assume that they're secure without relying on operating system features like that! Does DJB's installation instructions say to do this? I doubt it.

Anyway, if it was secure at any cost, why is is reliant on the OS providing that? Qmail on 64 bit with decent amounts of virtual memory available is seemingly easily compromised.

No documentation?? Every executable has a man page, even executables that the system runs (e.g. qmail-local or qmail-remote).
His licensing isn't poorly explained. But then again, you can't run 'man' so no wonder you couldn't Google for "djb licensing" and find http://cr.yp.to/distributors.html
Your third allegation was true until the publication of this PDF which you obviously didn't read since it included a dedication of qmail to the public domain.
The binaries aren't "mixed in with the mail spool". Binaries are in /var/qmail/bin, the queue is in /var/qmail/queue.

1 for 4. 25%. That's a failing grade in every school I know of.

> 1. How do you start / stop your MTA? /etc/init.d/... or delete a file and recreate it to restart.

http://cr.yp.to/daemontools/svc.html

svc -d /service/qmail - stops
svc -u /service/qmail - starts
svc -t /service/qmail - terminates the service and daemontools restart it.

> 2. How do you configure software? Config files or adding and removing files from a magic directory?

http://www.qmail.org/qmail-manual-html/man5/qmail-control.html

> 3. How do you kick the mail queue? Buggered if I can remember.

send ALRM to qmail-send process.

kill -s ALRM `pidof qmail-send`

The bad thing is that the license is NOT FOSS.

Actually, that might be changing in the immediate future. Check out the slides to go with this talk, in particular, page 10 where there's a timeline including:

2007.11: $500 -> $1000;
qmail placed into public domain.

According to one of DJB's slides it might happen this month that qmail will be placed into public domain. I hope this will become true as it might help qmail to get rid of its obsolescence.

We should put Theo and Daniel J. Bernstein (DJB) and see who survives. These so-called 'visionaries' and have a hard time forming an argument without degrading the argument with words like 'stupid'. It's a real shame that men like these are considered leaders the Free Software movement.

After reading vitriolic posts by these two fools, RMS doesn't seem all that bad.

If everybody is going to have to install new software, why not swap protocols?

http://cr.yp.to/im2000.html

Will large quantum computers be built? If so, what will they do to the cryptographic landscape?

Anyone who can build a large quantum computer can break today's most popular public-key cryptosystems: e.g., RSA, DSA, and ECDSA. But there are several other cryptosystems that are conjectured to resist quantum computers: e.g., the Diffie-Lamport-Merkle signature system, the NTRU encryption system, the McEliece encryption system, and the HFE signature system. Exactly which of these systems are secure? How efficient are they, in theory and in practice?

PQCrypto 2006, the International Workshop on Post-Quantum Cryptography, will look ahead to a possible future of quantum computers, and will begin preparing the cryptographic world for that future.

It was presented at the CRYPTO Rump Session: http://rump2007.cr.yp.to/

A rump session is a kind of free podium, meant to announce new results or entertain the audience with jokes (related to the area of research of course).
These guys just combined both: they presented a new result, but did so in an entertaining way.

Obviously they will write a serious research paper about this and publish it, probably at some other conference in the field of cryptography.

Dan's just a contrarian ass; always has been, always will be. For example, here's why he doesn't like IPv6:

Excerpt from a message I sent to the ngtrans mailing list on 2002.03.20:

(1) I'd like to connect my office computers to the IPv6 network, and make their services---the web server, for example, and the mail server---available to IPv6 clients around the world.

(2) I control the operating system and the applications. I am ready and willing to make various changes to the code.

(3) However, I refuse to provide any information to those programs beyond what they already have (such as my IPv4 addresses), and I refuse to do any work outside changing the programs themselves. I'm not going to ask my ISP for an IPv6 address, for example, and I'm not going to touch my DNS data.

Here's the big question: How do I achieve #1, taking advantage of #2, without violating #3?

In other words, "how can I run IPv6 without lifting a finger?" (or "how can I run IPv6 DNS without modifying my precious djbdns so that it supports AAAA records like every other server in the world?", despite what he says in #2). He goes on to explain why his dumb question isn't really dumb, even though it's still dumb.

Sure, you bring up some valid points. Don't make the mistake of bringing in DJB's opinions for support, though. Once he's decided that he doesn't like something, a team of wild horses can't make him change his mind.

It is clear that IPv6 made several basic design decisions that, essentially, made IPv6 impossible to deploy. Prof. Bernstein pointed this out many years ago in http://cr.yp.to/djbdns/ipv6mess.html and there seems to have been no changes to make IPv6 deployable. As other people have pointed out, IEFT saying MUST means nothing - if they had the power, you would be reading slashdot over a IPv6 link already.

Basically, the problem is interoperability between IPv4 and IPv6. IPv6 is completely separate and not compatible with IPv4. This means there is no incentive for any server to go v6-only since there are all clients are v4; the most you can hope for is some servers going dual stack. There is no incentive for clients to go v6 since there will be servers that stay v4 and all severs will be at worst dual-stack, so there is no incentive for clients to go even dual-stack. When you figure in the cost of going dual-stack and the troubles that all ISP's will go through; there is huge incentive to stay v4. So it is surprising that the world has stayed IPv4?

I just wish more places would use djbdns.

I've been using djbdns for years. It takes some getting used to if you're coming from BIND-land but it's worth making the effort.

http://www.openbsd.org/advisories/res_random.txt http://cr.yp.to/djbdns/forgery-cost.txt

2 & 3. it's DJB hasher. it's known to be good for strings. it's probably not nice to force people to google for 5381 to figure that out. you can find it described in DJB's cdb documentation, as well as many of his open source projects.

4. I agree. I couldn't come up with anything interesting for my specific example though, perhaps you can do better?

5. I agree. I certainly hate the repetition, but I did not do that in the comments I presented. I commented at a high level of what the syntax presented. .. do you have a specific example of what would be better?

A few days later I glanced at the Postfix security documentation. ``No Postfix program is set-uid,'' the Postfix author wrote. ``Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
causes more trouble than it is worth.''

This set off alarm bells in my head. ``Does postfix really use a world-writable directory
for people to drop off mail?'' I wrote in a 19981217 email message to another security expert.
``Is there anything that stops a user from making a hard link to another user's message, preventing postfix from delivering the message?''

In fact, when Postfix saw an extra hard link, not only would it fail to deliver the message, but it would actively remove the hard link, Any local attacker could trivially exploit this to anonymously destroy other users' incoming or outgoing messages. There was no way for the system administrator to find the culprit, and no way to recover the messages.

The Postfix author's reaction to my first public comments was outright denial.
``Bernstein is wrong on all points,'' he said in a public statement in response to a summary of the problems. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' He continued by giving an example of how an incompetent attacker might fail to destroy a file.
Several people pointed out his mistake, but he continued to deny the problem. ``In my opinion, no-one has brought forward a vulnerability worth mentioning,'' he said in a bugtraq message titled ``Claimed Postfix Vulnerabilities.''

I sent a detailed description of the vulnerability to bugtraq.
The Postfix author finally admitted that the attack would destroy mail. However, he didn't post a security alert on the Postfix web pages. Instead he added a brief note to the middle of the ``Postfix Errata'' page:

A local user can hard link a maildrop queue file to another
directory within the same file system, causing the mail to not be
delivered. Workaround: chmod 1733 /var/spool/postfix/maildrop, and
edit /etc/postfix/postfix-script, replacing 1777 by 1733.

When I saw this, I posted a note to comp.security.unix, explaining that this ``workaround'' simply didn't work. Any user could still anonymously destroy messages.

The Postfix author followed up, using the subject line of ``DAN BERNSTEIN'S CLAIM'' without admitting that my claims were correct, summarizing the problems as ``local users [can] play games with hard links'' without mentioning that these games

A few days later I glanced at the Postfix security documentation. ``No Postfix program is set-uid,'' the Postfix author wrote. ``Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
causes more trouble than it is worth.''

This set off alarm bells in my head. ``Does postfix really use a world-writable directory
for people to drop off mail?'' I wrote in a 19981217 email message to another security expert.
``Is there anything that stops a user from making a hard link to another user's message, preventing postfix from delivering the message?''

In fact, when Postfix saw an extra hard link, not only would it fail to deliver the message, but it would actively remove the hard link, Any local attacker could trivially exploit this to anonymously destroy other users' incoming or outgoing messages. There was no way for the system administrator to find the culprit, and no way to recover the messages.

The Postfix author's reaction to my first public comments was outright denial.
``Bernstein is wrong on all points,'' he said in a public statement in response to a summary of the problems. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' He continued by giving an example of how an incompetent attacker might fail to destroy a file.
Several people pointed out his mistake, but he continued to deny the problem. ``In my opinion, no-one has brought forward a vulnerability worth mentioning,'' he said in a bugtraq message titled ``Claimed Postfix Vulnerabilities.''

I sent a detailed description of the vulnerability to bugtraq.
The Postfix author finally admitted that the attack would destroy mail. However, he didn't post a security alert on the Postfix web pages. Instead he added a brief note to the middle of the ``Postfix Errata'' page:

A local user can hard link a maildrop queue file to another
directory within the same file system, causing the mail to not be
delivered. Workaround: chmod 1733 /var/spool/postfix/maildrop, and
edit /etc/postfix/postfix-script, replacing 1777 by 1733.

When I saw this, I posted a note to comp.security.unix, explaining that this ``workaround'' simply didn't work. Any user could still anonymously destroy messages.

The Postfix author followed up, using the subject line of ``DAN BERNSTEIN'S CLAIM'' without admitting that my claims were correct, summarizing the problems as ``local users [can] play games with hard links'' without mentioning that these games

A few days later I glanced at the Postfix security documentation. ``No Postfix program is set-uid,'' the Postfix author wrote. ``Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
causes more trouble than it is worth.''

This set off alarm bells in my head. ``Does postfix really use a world-writable directory
for people to drop off mail?'' I wrote in a 19981217 email message to another security expert.
``Is there anything that stops a user from making a hard link to another user's message, preventing postfix from delivering the message?''

In fact, when Postfix saw an extra hard link, not only would it fail to deliver the message, but it would actively remove the hard link, Any local attacker could trivially exploit this to anonymously destroy other users' incoming or outgoing messages. There was no way for the system administrator to find the culprit, and no way to recover the messages.

The Postfix author's reaction to my first public comments was outright denial.
``Bernstein is wrong on all points,'' he said in a public statement in response to a summary of the problems. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' He continued by giving an example of how an incompetent attacker might fail to destroy a file.
Several people pointed out his mistake, but he continued to deny the problem. ``In my opinion, no-one has brought forward a vulnerability worth mentioning,'' he said in a bugtraq message titled ``Claimed Postfix Vulnerabilities.''

I sent a detailed description of the vulnerability to bugtraq.
The Postfix author finally admitted that the attack would destroy mail. However, he didn't post a security alert on the Postfix web pages. Instead he added a brief note to the middle of the ``Postfix Errata'' page:

A local user can hard link a maildrop queue file to another
directory within the same file system, causing the mail to not be
delivered. Workaround: chmod 1733 /var/spool/postfix/maildrop, and
edit /etc/postfix/postfix-script, replacing 1777 by 1733.

When I saw this, I posted a note to comp.security.unix, explaining that this ``workaround'' simply didn't work. Any user could still anonymously destroy messages.

The Postfix author followed up, using the subject line of ``DAN BERNSTEIN'S CLAIM'' without admitting that my claims were correct, summarizing the problems as ``local users [can] play games with hard links'' without mentioning that these games

A few days later I glanced at the Postfix security documentation. ``No Postfix program is set-uid,'' the Postfix author wrote. ``Introducing the concept was the biggest mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
causes more trouble than it is worth.''

This set off alarm bells in my head. ``Does postfix really use a world-writable directory
for people to drop off mail?'' I wrote in a 19981217 email message to another security expert.
``Is there anything that stops a user from making a hard link to another user's message, preventing postfix from delivering the message?''

In fact, when Postfix saw an extra hard link, not only would it fail to deliver the message, but it would actively remove the hard link, Any local attacker could trivially exploit this to anonymously destroy other users' incoming or outgoing messages. There was no way for the system administrator to find the culprit, and no way to recover the messages.

The Postfix author's reaction to my first public comments was outright denial.
``Bernstein is wrong on all points,'' he said in a public statement in response to a summary of the problems. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' He continued by giving an example of how an incompetent attacker might fail to destroy a file.
Several people pointed out his mistake, but he continued to deny the problem. ``In my opinion, no-one has brought forward a vulnerability worth mentioning,'' he said in a bugtraq message titled ``Claimed Postfix Vulnerabilities.''

I sent a detailed description of the vulnerability to bugtraq.
The Postfix author finally admitted that the attack would destroy mail. However, he didn't post a security alert on the Postfix web pages. Instead he added a brief note to the middle of the ``Postfix Errata'' page:

A local user can hard link a maildrop queue file to another
directory within the same file system, causing the mail to not be
delivered. Workaround: chmod 1733 /var/spool/postfix/maildrop, and
edit /etc/postfix/postfix-script, replacing 1777 by 1733.

When I saw this, I posted a note to comp.security.unix, explaining that this ``workaround'' simply didn't work. Any user could still anonymously destroy messages.

The Postfix author followed up, using the subject line of ``DAN BERNSTEIN'S CLAIM'' without admitting that my claims were correct, summarizing the problems as ``local users [can] play games with hard links'' without mentioning that these games

Back in the day, I attended the University of Illinois at Chicago (UIC); Daniel Bernstein is a member of their MSCS department.

In 1995 (IIRC), Bernstein taught a course on cryptography in which a friend of mine had enrolled. Naturally the government (I forget which agency specifically) flipped out and tried to shut him down. I believe this led to Bernstein's lawsuit against the Federal Government. Anyway, students in his class were forbidden from speaking to others about material covered in the course, were forbidden from showing their notebooks to others and also had their notebooks confiscated (okay, turned in) at the end of the semester. I believe the students also underwent background checks prior to their enrollment in the class, but I could be mistaken about that.

I was more than a little surprised about all of the commotion. I mean, this is the United States; aren't we supposed to have academic freedom? I suppose the big concern was that foreign nationals would be taught cryptography, but again, the Constitution guarantees those freedoms.

More information about all of this is available at Berstein's website, linked to above.

I couldn't find any "critical security flaws" for postfix. I did, however, find this: http://cr.yp.to/maildisasters/postfix.html

http://www.securityfocus.com/bid/17192
http://www.securityfocus.com/bid/8641
http://www.securityfocus.com/bid/8649
http://www.securityfocus.com/bid/6991
http://www.securityfocus.com/bid/6548
etc...

I couldn't find any "critical security flaws" for postfix. I did, however, find this: http://cr.yp.to/maildisasters/postfix.html

qmail is way more than non-GPL. It is not free software at all. Not even close.

dig axfr @yournameserver.com yourdomain.com
dig axfr @ns2.gkg.net gkg.net
dig axfr @ns2.bfccomputing.com bfcomputing.com

The reason is that programmers cannot reliably write long running process code. Programs crashed all the time in Multics. Something Multics wasn't very good at handling back in the 1960s. There was some research done and it was observed that programmers could write code for short lived processes fairly well but not long lived.

So, one lessoned learn from from the failure Multics is that programmers do not write reliable, long running code.

By the way, remember that Paul Vixie's BIND is just one implementation and it's considered to be flawed by some wise people:

http://cr.yp.to/djbdns/blurb/unbind.html

tinydns has a nice option to make one address expire at a specific time and another take its place (or just start serving a record at a specific time, or have a record stop working at a specific time). When it gets close to the expiry time, the existing record's TTL is reduced accordingly to prevent problems as well -- its quite a nice feature really for IP changes.

I'd rather say that DNS is damned weak. It's probably the weakest point in the Internet infrastructure as a whole, and that's a lot to say. DNS was chosen by SANS Institute as one of the top 20 Internet vulnerabilities in 2006:

http://www.sans.org/top20/

Last time there was a major DNS failure? The DNS system relies on 13 servers. In 2002 nine of them went down due to a DDoS attack, the whole Internet was very slow or unreachable for an hour. This year in February almost three of the servers crashed due to another DDoS, which moved the Department of Defense to say that next time they will counterattack and even bomb the source of the DDoS, so guess if it was important.

By the way, remember that Paul Vixie's BIND is just one implementation and it's considered to be flawed by some wise people:

http://cr.yp.to/djbdns/blurb/unbind.html

The IPv4 addresses are a subset of the IPv6 space -- you can get to all of the IPv4 systems from an IPv6 network.