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

Last time, I compared the number and size of the response messages involved in resolving a record in an unsigned zone to those involved in resolving a record in a signed zone under a signed TLD. This time, I want to look at the actual computation involved.<\/p>\n

This isn’t really a comparison, of course, because in the case of an unsigned zone, there’s no heavy computing involved: The nameserver simply reads responses from the network and unmarshals their content into discrete resource records–simple! In the case of a signed zone under a signed TLD, there’s lots of work to do.<\/p>\n

Let’s start with a count of the unique records returned and their types. We need to be a little careful here, though, since sometimes identical records are returned in more than one response. Here’s our census:<\/p>\n

    \n
  1. 6 NS RRsfor org<\/li>\n
  2. 6 corresponding A RRs (the org name servers’ addresses)<\/li>\n
  3. 6 corresponding AAAA RRs (the org name servers’ IPv6 addresses)<\/li>\n
  4. 4 NS RRsfor isc.org<\/li>\n
  5. 2 corresponding DS RRs<\/li>\n
  6. 1 RRSIG RR(covering the DS RRs)<\/li>\n
  7. 3 corresponding A RRs (the isc.org name servers’ addresses)<\/li>\n
  8. 1 A RR (theanswer!)<\/li>\n
  9. 2 RRSIG RRs(covering the A RR)<\/li>\n
  10. 4 NS RRsfor isc.org (same as in 4.)<\/li>\n
  11. 2 RRSIG RRs(covering the NS RRs)<\/li>\n
  12. 3 corresponding A RRs (same as in 7.)<\/li>\n
  13. 1 corresponding AAAA RR<\/li>\n
  14. 8 RRSIGRRs, covering the name servers’ 3 A RRs and 1 AAAA RR)<\/li>\n
  15. 4 DNSKEYRRs for isc.org<\/li>\n
  16. 4 RRSIG RRs(covering the DNSKEY RRs)<\/li>\n
  17. 4 NS RRs(same as in 4.)<\/li>\n
  18. 2 RRSIG RRs(same as in 11.)<\/li>\n
  19. 3 corresponding A RRs (same as in 12.)<\/li>\n
  20. 1 corresponding AAAA RR (same as in 13.)<\/li>\n
  21. 8 RRSIG RRs(same as in 14.)<\/li>\n
  22. 4 DNSKEYRRs for org<\/li>\n
  23. 2 RRSIG RRs(covering the DNSKEY RRs)<\/li>\n
  24. 6 NS RRsfor org (same as in 1.)<\/li>\n
  25. 1 RRSIG RR(covering the NS RRs)<\/li>\n
  26. 2 corresponding A RRs (subset of 2.)<\/li>\n
  27. 2 corresponding AAAA RRs (subset of 3.)<\/li>\n<\/ol>\n

    Whew! Now, to keep things simple, let’s just say:<\/p>\n