the library is able to resolve query in stub mode (no referral chasing,
zone cut lookup) if asked to
validator turns off for stub queries, validating stub is NYI

thanks to Pieter Lexis and Peter van Dijk from PowerDNS for discovering this.

as the libknot packet interface disallows out-of-order packet
writes, authority and additional records must be written after
the answer is complete; records in the rr arrays will be written to final answer during finalization

for pktcache same or better rank is required (because it’s a direct answer)
for rrcache better rank is required (unless doing write-through)

for both cases, no cache rank check is needed when inserting secure data

security note: this mitigates possible non-auth NS hijacking

[1] shows an attack using spoofed CNAME targets to replace legitimate
entries in resolver cache by speeding up once-per-TTL attack opportunity

as a defense, the resolver almost always requeries CNAME targets and
doesn't store them in cache. the only exception is when the CNAME target
is within current authority, and the answer is DNSSEC-secured

thanks to Toshinori Maeno (@beyondDNS) for pointing this out [2]

[1]: https://tools.ietf.org/id/draft-weaver-dnsext-comprehensive-
resolver-00.html
[2]: https://moin.qmail.jp/DNS/KnotResolver/CNAMEpatch

when the DS NODATA was proved from a different authority

validator can now yield, but it doesn't plan the sub-requests directly,
that is still a job of the driver

this is useful when you need to issue several subrequests before
continuing with the current query, resuming is not supported yet, so it
will requery after the subrequests complete

current processed query is always in `request->current_query`

when no validation is attempted, trust level is 'bad'
when validation attempted but insecure, trust level is 'insecure'
otherwise 'secure'

minimised nodata/nxdomain can now be cached if it is
authoritative. also pkt/sec cache are now shared using
the ‘rank’ field to replace insecure version with secure
if needed

this is a workaround for missing DEFER operation, as the
validator module can only detect trust chain breakage
(caused by answering from different authority) after the
iterator writes answer. this causes duplicated answer on
uncached queries

this doesn’t fix record duplication in answer when not answered from cache

if the query has RD=0 or is ANY, only cache is probed
for ANY, only A/AAAA/MX is checked and no query is
forwarded to the authoritatives

if the answer is flagged as insecure, it means that the resolver tried
to validate it, but couldn't (e.g. trust chain doesn't exist)

the key is now stored in a format friendly to prefix search, the values
also contain one more 16bit field to store rank of the data (to be
utilised later)

this is a problem when both CNAME and the target are answered from the same NS (but different authority), but only the CNAME authority does DNSSEC. it’s probably legal, but it’s pretty stupid to do so

refs #33

the selected address is now an array with selection, caller can then send the same query to multiple offered targets

refs #35

this could happen if the query contained a CNAME with AA=0, or missing mandatory DS in previous NS query

this is useful if we want to prefetch or update data
in cache, it doesn’t affect the lookup of closest known
zone cut

if the client doesn't support DNSSEC, scrub these from the answer
and do not set the AD bit