the resolution driver now correctly fetches keys,
and the zonecut lookup should find closest TA,
then the validation module should have all the
information needed for simple validation

1. validate module must be between iterate/cache
2. produce: copy OPT with DO=1, ask for DNSKEY if we don’t have it
3. resolve.c: subrequest DNSKEY if asked to do it
4. consume: check DNSKEY and set it, validate RRSIGs against it

another issues:

rrsigcache is copypasta of rrcache, there is one special case with storing RRSIGs which doesn’t deserve it’s own module (if the validation is off, then nothing will get written in there anyway)

since the resolution is asynchronous, layers must only *ask* resolver to do subrequests for them using query flags (like when we encounter an unknown zone cut)

before root hints were hardcoded to the resolver,
now they are present in form of a cut in the resolution
context, and the modules can add/remove/replace them
on the fly

fixes potential cache key oob write

this LRU-like cache tracks lame nameservers, unresolvable
nameservers (to not waste resources in trying to resolve them),
and possibly other features (extension support, …)

simplified bee foraging strategy, by default each query goes to the most rewarding NS
however with a chance proportional to the NS RTT, a server may be probed even if it isn’t the most rewarding

if the query is satisfied from cache, it doesn’t need a zone cut lookup, so it may be deferred until an outbound query is about the be issued.

this prepares cache/txn structures to hold API as well, so we can get
rid of the global api

each asset is tagged by a byte defining its type and importance
this is a groundwork for negative cache and packet cache
abstracted the code in preparation for different backends

instead of keeping just random NS and address,
it keeps a map of nameservers => {addresslist}

this allows scoring and correct NS election, fallback
and evaluation