<commit_before>proposed getdns cache design
<NAME> <<EMAIL>>

API Description Requirements
============================
Considerations regarding cache are slightly different depending on
whether we are operating as a stub resolver or a recursive resolver.
The API description requires that we operate as a recursive resolver
and considers stub resolver behavior optional.

Recursive Resolver Cache
========================
Caching is arguably an important feature for most recursive resolvers.
In this case we are not intending a replacement for the fully
functional recursive resolvers already available (BIND, Unbound, etc.)
so we shoudl limit a cache implementation to behaviors important to
proper operation of a recursive resolver.

DNSSEC validation can potentially triggers more queries than a simple
request for a A RR so I think it makes sense to cache root and TLD
data.  Once we have gone that far it isn't much of a reach to cache
at each layer in the hierarchy (depth will not increase the coding
effort or defect rates).

Bear in mind that this resolver will only answer local processes,
it is not listening for queries over the network.

Stub Resolver Cache
===================
One well supported poition is that a stub resolver should not cache
DNS replies as it relies on a proximate recursive resolver for
iterative resolution and caching.  DNSSEC validation introduces
a potential use case for caching even when we would prefer to not
cache DNS replies in the stub resolver.  I'd like to avoid a 
religious debate about whether a stub resolver should have a cache
and focus on what we need to make the getdns API best suited to
its intended focus.

Since a cache makes sense for a recursive resolver we will need 
to implement it anyway.  With that in mind I recommend that we
use a configuration setting to enable caching and control its 
behavior when running as a stub resolver.

Cache Design Points<commit_msg>Some mispelled words corrected<commit_after>proposed getdns cache design
<NAME> <<EMAIL>>

API Description Requirements
============================
Considerations regarding cache are slightly different depending on
whether we are operating as a stub resolver or a recursive resolver.
The API description requires that we operate as a recursive resolver
and considers stub resolver behavior optional.

Recursive Resolver Cache
========================
Caching is arguably an important feature for most recursive resolvers.
In this case we are not intending a replacement for the fully
functional recursive resolvers already available (BIND, Unbound, etc.)
so we should limit a cache implementation to behaviors important to
proper operation of a recursive resolver.

DNSSEC validation can potentially trigger more queries than a simple
request for a A RR so I think it makes sense to cache root and TLD
data.  Once we have gone that far it isn't much of a reach to cache
at each layer in the hierarchy (depth will not increase the coding
effort or defect rates).

Bear in mind that this resolver will only answer local processes,
it is not listening for queries over the network.

Stub Resolver Cache
===================
One well supported poition is that a stub resolver should not cache
DNS replies as it relies on a proximate recursive resolver for
iterative resolution and caching.  DNSSEC validation introduces
a potential use case for caching even when we would prefer to not
cache DNS replies in the stub resolver.  I'd like to avoid a 
religious debate about whether a stub resolver should have a cache
and focus on what we need to make the getdns API best suited to
its intended focus.

Since a cache makes sense for a recursive resolver we will need 
to implement it anyway.  With that in mind I recommend that we
use a configuration setting to enable caching and control its 
behavior when running as a stub resolver.

Cache Design Points
{'fraction_non_alphanumeric': 0.05255023183925812, 'fraction_numerical': 0.0, 'mean_word_length': 4.812874251497006, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1753097', 'n_tokens_mistral': 933, 'n_tokens_neox': 865, 'n_words': 608}