{"id":4714,"date":"2010-01-14T16:43:09","date_gmt":"2010-01-15T00:43:09","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=4714"},"modified":"2020-05-06T10:31:46","modified_gmt":"2020-05-06T17:31:46","slug":"quantifying-dnssec-overhead","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/security\/quantifying-dnssec-overhead\/","title":{"rendered":"Quantifying DNSSEC Overhead"},"content":{"rendered":"

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:<\/p>\n

% dig ds isc.org. +dnssec<\/p>\n

I chose\u00a0www.isc.org\/IN\/A<\/a>\u00a0as the RRset I’d look up.<\/p>\n

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:<\/p>\n

% sudo rndc flush<\/p>\n

Then I fired up tcpdump to capture DNS traffic:<\/p>\n

% sudo tcpdump -w\u00a0www.isc.org.cap<\/a>\u00a0port 53<\/p>\n

And then sent the query:<\/p>\n

% dig\u00a0www.isc.org.<\/a>\u00a0+dnssec<\/p>\n

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.<\/p>\n

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

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!<\/p>\n

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

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:<\/p>\n