Many people use an IM add-on called Off-the-Record. On top of encryption, it also provides deniability by not proving any digital signatures for the other party to present to a court, and the procol ensures everyone can make false messages in the past. How strong do you this technical protection would be from a legal perspective if one of the two parties has a logfile with all messages?

I strongly recommend using GKG.net, as they have the best (automated) XML interface that I know of. See their documentation

InternetX also has a good interface, but it is a little more complex to get going.

Those, as well as GoDaddy, which you can only process using ugly web scraping with BeautifulSoup and Mechanize, were the first ones we supported in our DNSSEC Signer product.

Paul Wouters, DNSSEC Evangelist at Xelerance

It's 4 out of 7 to get the key that can decrypt the backup. The backup is not in the hands of the 7,so they cannot do anything by themselves!

Three years to deploy RFC 4956 is not "technical reasons"

Powerdns was vulnerable to the Kaminsky attack, but in a different way. It was actually easier to spoof the server due to its more actively dropping certain DNS packets. So while it did perform source port randomization, it was not totally immune to the attack either.

http://doc.powerdns.com/security-policy.html itself states:

All versions of PowerDNS before 2.9.21.1 do not respond to certain queries. This in itself is not a problem, but since the discovery by Dan Kaminsky of a new spoofing technique, this silence for queries PowerDNS considers invalid, within a valid domain, allows attackers more chances to feed *other* resolvers bad data.

Though it is phrased as "someone elses problem", in the DNS word of course nothing is "someone elses problem". DNS servers are chained in hierachies and one problem somewhere leads to problems elsewhere. DNS is all about protocol compliance to ensure interoperability. With the "someone elses problem" approach, we would have had no "reflection attack" and "amplification attack" problems either, it being "someone elses problem". Despite the nice phrasing, powerdns caused cache poisoning problems as a result of the Kaminsky attack that needed to be addressed.

In general, I have a problem with bug reports and changelogs writing things as "improved error handling", "made more robust" or "add security to" which are too often used to hide the real security impact of certain bugs. DJB's policy of "it is not my bug to fix, because it is an operating system bug" is also completely bogus from a system administrator point of view who still ends up with a security problem.

that sounds more like Guild Heighliner technology where they Fold Space.

"travel to any part of the universe, without moving".

It also avoids the acceleration/deceleration with WARP speeds :P

I was not here, I did not say this.....

indeed. you can ignore what you want. You can only create your own "secure entry point" that override a parental DNSKEY if you would want to (Think China removing .tw entries). Anyone who controls a resolver can do this. It's a one line configuration change.

The root key is not Sauron's Ring

you want a 3-way handshake per dns lookup? Are you crazy? Do you even know how many dns lookups your browser creates on average.

You'd be looking at 10 seconds delay for a webpage like slashdot easilly

Stupid sensationalism.

You can right now use draft-vixie-dnsex-dns0x20 to protect against the kaminsky bug. This option is already available in the unbound nameserver.

Talking about totally talking out of context. Fools!

If IETF does something to mitigate, the unbelievers scream "see we dont need dnssec"

If IETF does not do something, the unbelievers scream "you're blackmailing us into dnssec"

Stop whining and put your foot where your mouth is.