I realized last week that I'd never actually traced all the queries sent and responses received by a recursive name server resolving a domain name in a zone signed with DNSSEC.  I decided to trace the
recursive resolution of an RRset in a signed top-level domain, since I
wanted to see the "chain of trust" in action.  I knew .org was signed
and figured isc.org (the Internet Systems Consortium's domain) would
probably already have a DS (Delegation Signer) record.  Sure enough, a
quick query using dig verified that:

% dig ds isc.org. +dnssec

I chose www.isc.org/IN/A as the RRset I'd look up.

I started by clearing the cache on my BIND name server (running BIND 9.7.0rc1), so that I could watch my name server query the .org name servers and see the records returned:

% sudo rndc flush

Then I fired up tcpdump to capture DNS traffic:

% sudo tcpdump -w www.isc.org.cap port 53

And then sent the query:

% dig www.isc.org. +dnssec

This turned out not to capture enough data when the responses were long, so I refined my tcpdump command by specifying the option "-s 4096".  Then I found out I wasn't catching all fragments of really long
responses, so I dumped the "port 53" argument (since fragments don't
carry port information) and used Wireshark to filter out all the non-DNS
traffic.  Now I actually had a complete record of the queries my name
server sent and the responses it received.

The results surprised me:  I saw five queries and five resulting responses, when resolution of a domain name from an unsigned zone, such as www.cert.org, would usually require at most just three roundtrips. 
And, of course, the signed responses were much larger than most unsigned
responses.

Here's a short comparison of resolution of www.isc.org and www.cert.org:

This isn't a perfect comparison--isc.org has four authoritative name servers, while cert.org only has two, which would make isc.org responses larger even without DNSSEC--but it gives you a sense of how much more
traffic DNSSEC will use:  In this case, over 6.5 times as much!

Now, not all resolutions of RRsets in signed zones will require this many roundtrips:  Once our name server has validated the signature of www.isc.org's A record, as well as the public keys for isc.org and org,
it'll cache those results.  Still, even the individual response that
contained www.isc.org's A record (Response 3) was a whopping 17 times as
large as the response containing the address of www.cert.org, and that
record's TTL is just ten minutes, so we might have to look it up
frequently.

Of course, the workload involved in sending and receiving those UDP datagrams pales in comparison with all the hashing and decryption that needs to be done to validate the records received.  Here's what those
five responses contained:

• Response 1:  6 NS records, 6 A records, 6 AAAA records
• Response 2:  4 NS records, 2 DS records, 1 RRSIG record
• Response 3:  4 A records, 1 AAAA record, 4 NS records, 12 RRSIG records
• Response 4:  4 DNSKEY records, 14 RRSIG records, 4 NS records, 3 A records, 1 AAAA record,
• Response 5:  4 DNSKEY records, 2 RRSIG records, 6 NS records, 1 RRSIG record, 2 A records, 2 AAAA records

Now, some of these are duplicates, and some RRSIG records aren't needed in the validation process, but each RRSIG record requires one cryptographic hashing operation and one asymmetric encryption operation
to check, and each DS record requires one cryptographic hashing
operation to check.  Compare that with the resolution of www.cert.org,
which would require all of, er, zero hashing operations and no
asymmetric encryption operations.

As a consequence, we should expect to see CPU overhead go up dramatically as our name servers start handling more DNSSEC-signed responses.  After you configure validation, you'd be well advised to
begin monitoring your name server's CPU utilization, too, so you aren't
caught by surprise when your recursive name server pegs the processor.