[bind10-dev] recursor cache requirements (better explanation of the cookie idea)

[Likun Zhang]

> As it turned out, the idea of cache cookies is not entirely clear, so let me try to
> explain it little bit more.
> 
> First, I'll explain why it is needed by NSAS. Currently, NSAS uses resolver to get
> NS records for a zone and A and AAAA records for the nameservers. Which
> means it relies on the resolver to use the glue.
> 
> The nice flow of events would be:
> 1. Resolver asks a remote nameserver something.
> 2. The nameserver responds by a referral, providing the name of the zone to
>    follow and glue.
> 3. The complete answer, including the glue, is stored in cache.
> 4. The resolver looks and asks NSAS what the IP address of some nameserver of
> the
>    zone might be.
> 5. NSAS does not know, so it asks resolver for NS records and then A records.
> 6. Resolver looks into the cache and finds it there, because we got it as the
>    glue.
> 7. NSAS gives an IP address to the resolver.
> 8. The resolver can ask the nameserver and everyone lives happily ever after.
> 

Hi vorner,

A better design can make the problem which triggers your cookie idea be avoidable. I like to make things more simple and modular. 

Cache:  works just like key-value database, just support lookup, dump, remove etc.
NSAS:   just record which nameserver should be used for the next query.

In step 3 mentioned by you, once the cache get the updated, nsas should also be updated(by cache or recursor module, I will prefer to cache)
In step 5, if NSAS does not know, it should return NULL to the caller of it. Then recursor will send out the query outside. We should never let NSAS do some ask or query. Note, my understanding for NSAS is: it just saves the information for choosing nameservers for one query.  I know it's different with section "Fetching information " in NSAS design document. 

Maybe we need a big picture about how recursor, NSAS and Cache work together.