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

[Michal 'vorner' Vaner]

Hello

On Tue, Dec 21, 2010 at 04:22:09PM +0800, Likun Zhang wrote:
> A better design can make the problem which triggers your cookie idea be avoidable. I like to make things more simple and modular. 

Well, I too prefer simple things. However, this resulted from trying to make the
NSAS more simple while keeping its abilities.

> 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.

You could have the NSAS only an array of IP addresses with RTTs and every time a
resolver would ask which address to use, it would provided the addresses of
nameservers. But this way, resolver provides only name of the zone
(simplification for the resolver).

Asking trough the resolver (which should not generate any external queries, it
is not sending a packet) is simplification of the NSAS (it solves problems like
CNAMEs).

And every query will need to carry some kind of state with it anyway (because of
logging, etc). So it does not really make things harder. Even the cache
implementation will not be harder, because it can work in similar way as L1/L2
cache.

> 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)

So NSAS will know about all existing A records in cache? Isn't it a bit too
much?

And it does not solve the TTL0 problem. How long should the NSAS keep using it?
With the cache, you are guaranteed it is only the one query that gets it, which
is correct. If you choose how long it is available somewhere (without any kind
of identification, which query it is for), then you either have it too long and
present to to some other query where you shouldn't or too short and you don't
give it to anybody.

> 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. 

Yes, but it needs to get the information somewhere. It needs to know from which
nameservers to choose. We either need to store mostly nothing (which is complete
redesign of NSAS, including external interface), or ask something else (it does
so now) or parse it from referral info (which is IMO both complicated and wrong
and incomplete, because for out-of-zone nameservers which are not in glue).

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

Agreed. I believe we should borrow a whiteboard for some time at the F2F and
spend some time drawing bubbles and arrows on it, because it seems too many
people have an idea how it should look like, everybody is sure it is the correct
way and expecting everyone else to have the same idea, while they differ.

With regards

-- 
Hallowed be the zeroes and ones

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101221/c05c4c6e/attachment.bin>