The "packets of 576 bytes can't be fragmented" is a commonly stated reason, but it is wrong. It is a myth/misunderstanding. It is, in practice, true has has been true since probably the late 1980s, but DNS was around long before that. Indeed, if you read some of the earlier RFCs, it is quite clear that packets of any size could be fragmented, down to something like 16 bytes of payload per fragment. No,the reason for the 512 byte payload size is much more basic than that. Back in the early 80s, memory was tight, you could have mainframes supporting dozens of users on a machine with maybe 1MB of memory, each of user could have more than one active network connection. IP supports packets sizes up to around 64k, but it would be unreasonable to expect every host to be able to accept such a large packet size. It would mean that they could get fragments from all those packets piecemeal and out of order, so reconstructing each packet would require holding lots of 64k buffers, each of those buffers would be 6% of all available memory. It would be very unreasonable to expect every host on the internet to be able to accept any size packet, even if those packets came in fragment that wouldn't saturate your connection. Now, protocols like TCP have the ability to negotiate the packet size, but for UDP, it gets messy and slow. So, it is a *requirement* that each host on the internet can accept a packet with 512 bytes of payload. That packet can be fragmented, but it has to be accepted.

Intelligence as a requirement for voting has been fought for a long time see voting tests.

There is a certain amount of irony with you saying this, followed by your .signature of:

Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make

This "joke" is clearly aimed at people who think they understand math/physics/science, so it won't be funny to most people. But, it also shows a complete lack of understanding about how equations should be interpreted. What the formula "money = work/knowledge" says to increase the amount of worked done, you need either more money or more knowledge. In other words, "the only substitute for knowledge is money", or "a fool and his money are soon parted". You are a case of "a little knowledge is a dangerous thing". By your own statments, you shouldn't vote.

The big problem with DNSSEC, if widely used, is that it prevents forgery of DNS responses. ISPs and internet cafes will not like this, since that means they can no longer forget DNS replies to missing domains or to force people through registration pages. I can see a *LOT* of push-back from having end-users using DNSSEC.

DNSCurve does not require you to pay any third parties, it is like DNSSEC where you publish your own information. Both technologies are (or in the case of DNSCurve, will be) free.

DNSSEC has many years of actual deployment, not as wide spread as it needs to be, but it has been out there and tested.

Can you point me to a single implementation of DNSCurve? Can you even point me to a specification of what exactly it is? I've looked, and the best that I can tell, there aren't any. More over, it doesn't appear that DJB's website has been updated since he proposed DNSCurve last year.

DNSCurve is interesting technology, but it has many problems, not the least of which is that it is mostly hype right now. It does not really replace DNSSEC in functionality, but rather, it is closer to TSIG. That is, instead of securing the actual DNS records, it secures the communication between name servers and resolvers. With DNSSEC, you can get your DNS records for a totally untrustworthy server, and yet be able to prove if they are valid or not, but there isn't any form of encryption so there isn't any privacy. DNSCurve encrypts the transactions, but you can often figure out what is there anyway by watching which name servers you are contacting and monitoring other things to figure out what you were looking up. I like DNSCurve, I hope it goes some where, but I also hope that DNSSEC takes off soon.

To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra. I'm a layman here, but glancing at how DNSSEC works, I see no obvious way selectively signing some but not the rest of entries could work. This means, DNSSEC would provide a more secure way to give the public key to a viewer.

You may be a layman, but you appear to have far more clue about this stuff than most. Yes, once DNSSEC is deployed, anyone with a domain name can publish CERT records and have about the same security as a paid-for CERT. Granted the cert authorities right now require you to give your name and address and such, which publishing CERT records in the DNS won't require so they aren't exactly the same, but close enough considering how little checking the cert authorities do on such information

SPF policies apply only to the envelope sender address, not the message's From: header.

Most of the time, the email address in the "From:" header gets copied to the envelop "from". And, most importantly in this case, the envelop "from" is where bounces get sent to, so the bounces he receive could have been stopped if he had published an SPF record *and* everyone checked it.

Mind you don't step in the FUD.

For *possible* prior art, see keylaunch
Released on June 12, 2002, you can launch an app by pressing an application button twice within a limited time.

Also see slowlaunch
Released on May 20, 2002, you can launch an app by holding an application button for a specified length of time.

Neither half of the patent (hey, I read only the abstract, but that's more than you did!) seems to have been novel at the file date, and it's easy to imagine that keylaunch and slowlaunch could have coexisted on the same palm, giving the full functionality described in the patent abstract.