folbricht
Idea: CACHE based on Records instead of whole RRSETs
RouteDNS stores answers in cache based on using the lowest TTL it find in the RRSET of the answer. There might be an optimization possible by storing every record in an RRSET separately based on a per record basis (using the TTL per record), to reduce lookups, and reconstruct the records in an RRSET based on what is in cache instead.
What will happen when a query comes in, the cache will follow the chain of records in RRSet in cache and when missing/expired it just fetch just that record and reconstruct the RRSet on the way.
When RouteDNS in the future becomes a recursive resolver (see #123) this potentially will improve the number of iterative lookups resulted as loads of records in RRSets nowadays use the same values (see all the CNAME chaines for the different content-providers and load-balancers like cloudflare, aws, akamai, etc).
Positive side-effect possibly is a more efficient and lower use of memory for cache (shared records among RRSets, only store same records once). Performance could be impacted though, but looking at other DNS software (see below), it is negligible.
It might be just an on/off switch on the current cache group.
Note: don't forget about the ns ("authoritative" section) and extra ("additional" section) RRSETs.
See the ISC BIND and NLNETLABS UNBOUND caches for examples.
BTW, As potential alternative... See #242, putting the TTL/Optimize-TTL behind the cache, we can already influence storage in cache more (no need to modify current cache code). You lose the benefits of efficiency of shared records among RRSETs though.