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.
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.
