Hi Steve,
There was an interesting paper at Usenix Security on the effects of deploying DNSSEC; see https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impac... . The difference in geographical impact was quite striking.
George Michaelson and I have been undertaking similar work in DNSSEC, using an advertisement to enrol users' browsers to perform a set of URL loads that tests their ability to perform DNSSEC validation. Our methodology differed from that in the Usenix paper - we worked hard at setting up name structures that eliminated any benefits from DNS caching as well as web caching. We presented on this work at the IEPG meeting at IETF 87 a couple of weeks ago. The bottom line: around 8% of clients across the Internet will perform DNSSEC validation - i.e. they are seen to fetch the DS and DNSKEY RRs for the signed objects, and will fetch the object that is correctly signed, and will not fetch the object that is badly signed. A further 4% of clients appears to use a set of resolvers where there is a mix of validating resolvers and non-validating resolvers. What we see is that the client's resolver will perform a set of fetches of the DS and DNSKEY records for the badly signed onject, then ask for the A record a second time (generally using a different resolver) and then fetch the object anyway - i.e. the original SERV FAIL response causes the client to turn to another resolver in its list, and use that result. 87% of clients only ask for A records - no signs of DNSSEC life for them. We did some basic mapping of client to country (there is a LOT of DNSSEC validation in Sweden!) and network service provider bu origin AS, and also looked at the performance implications, both if you serve a zone thats signed, and if you serve a zone that is signed badly. The presentation is at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf if you are interested. Geoff