Just a quick note. This person (Thierry M.) is pushing his own patented technology, called "TAKREM", in the IETF working group that deals with DNSSEC protocol development. Please don't take his article as "the" view of the working group as a whole.

There is also the issue of who might make money off it. I've commented that ssl server certification authority industry have somewhat backed DNSSEC ... but it represents a significant catch-22 for them
http://www.garlic.com/~lynn/subpubkey.html#catch22

currently ssl domain name server digital certificates represents binding between domain name and public key. the authoritative agency for domain names is the domain name infrastructure. ssl domain name server digital certificates where (at least partially) justified by perceived vulnerabilities in the domain name infrastructure (the same domain name infrastructure that is the authoritative agency for domain names).

the root trust for domain names is the domain name infrastructure ... so part of DNSSEC could be viewed as improving the integrity of the domain name infrastructure as part of eliminating systemic risk for ssl domain name server digital certificates. This can be achieved by having public key presented as part of registering domain name ... and then future communication with domain name infrastructure needs to be digitally signed ... which can be verified with the previously registered, onfile public key.

This can also be used to reduce the cost of ssl domain name digital certificates. Currently certification authorities require a ssl digital certificate application to include a whole lot of identification information. Then the certification authority has to perform error-prone, expensive and time-consuming identification matching process with the information on file (for the domain name) with the domain name infrastructure.

With an on-file public key, certification authorities can just require that ssl domain name digital certificate applications be digitally signed ... then the certification authority can replace the time-consuming, expensive, and error-prone identification process with a much more reliable and inexpensive authentication process ... verifying the digital signature with the public key on-file with the domain name infrastructure.

the catch-22 for the ssl domain name certification authority industry

1) improvements in integrity of domain name infrastructure mitigates some of original justification for ssl domain name digital certificates

2) if general public can also start doing trusted real-time retrieval of on-file public key ... it further eliminates need for ssl domain name digital certificates as well as general demonstration about not needing digital certificates for trusted public key operations.

There is something wrong with the link , check your markup .. you added an extra ..(the marc.info link)

Anyone interested in DNSSEC problems should look at Thomas Ptacek's series of articles on this, which seems to be pretty much the final word on DNSSEC issues, and specifically "why don't we have DNSSEC deployed yet?". It's at http://www.matasano.com/log/case-against-dnssec/ (although the final parts have been in preparation for quite some time now).

http://ds9a.nl/secure-dns.html and http://ds9a.nl/dnssec/
may also shed some light on the issue.