[bind10-dev] NSAS Using Authority/Additional Information?

Thu Dec 2 09:55:43 UTC 2010

Hello

On Wed, Dec 01, 2010 at 07:04:11PM +0000, Stephen Morris wrote:
> > So it seems simpler not to need them. Or is there any real reason to have
> > timeouts on everything?
> 
> There has to be a timeout somewhere, but where that is is implementation-dependent.  My example had the timeout in the NSAS->resolver calls.  But the code should work equally well if it is in the resolver->NSAS call.  At some point something times out and unwinds the chain of asynchronous function calls.

Yes, they have. But in the optimal design, the only thing that can time out is
remote communication, not local computations.

But yes, after reading further it seems putting a timeout on a whole query will
be easier (I'll just assume that the resolver puts the timeout on the query
itself, when called resolve() and will return failure if it times out).

> > That is not exactly a duplicate, one was for A, www.example.net, another for A,
> > ns.example.net.
> 
> I perhaps didn't explain it as well as I could.  In both step 2 and step 9 the resolver asking for the address of the nameserver for example.net.  In step 2, in response to the query to the .net nameserver for www.example.net it has received a referral to ns.example.net and so attempts to get the address from the NSAS.  In step 9 that request has led to another request for the address of the example.net. nameserver.

Ah, I see. But I think the resolver not only should be allowed to do so, but
should actually be encouraged to put another callback, as it will simplify it a
lot and we will group them on the zone entry for no additional cost (or, at the
cost of few bytes for the callback).

> > Then we must think of something else then. But it still seems like an unclean
> > idea to put a callback there. Maybe we will be able to detect some of the
> > problems described here sooner. Or maybe they do not happen in real life much so
> > we should care only not to leak memory in such cases.
> 
> I don't think it is unclean.  It simplifies each task - I call something and pass a callback object.  At some time later the callback is called.  In the rare cases that we get a misconfiguration, it doesn't really matter that the callback nesting is deep or takes a long time to execute.  We are only getting the penalty on an error.

Right. It seems unclean from the design perspective, that it could be done
better. But it does simplify things, so I think simple code with slightly
unclean design is better anyway.

> > But the CACHE_ONLY could be used to fetch all the glue information at the
> > creation time, failing for the not specified ones. Then the second round could
> > get the rest remotely. When we do not have that one, we just pick 2 nameservers,
> > ask for their IP addresses and wait for that. If we are unlucky, we might have
> > chosen the two that are out of zone, so they trigger external query.  And we wait
> > for them to answer before we ask for the glue in cache. But that's probably too
> > soon to think about optimising this (anything real just has the glue anyway).
> 
> This could be a note for implementation.  The NSAS knows what zone is being asked for.  If the zone does not exist, a zone entry is created for it and the resolver asked for the nameservers it knows about.  If there are more than two, the NSAS could check whether any are in-zone and if so, ensure that they are the ones it selects.  The idea here is that if configured correctly, we know that the resolver will have the addresses of them in cache (the glue records) so eliminating the need for an external query.

Well, I wanted to this because after that I'm able to throw away the cache
cookie. I could have received the glue records for others than in-zone as well.

But I think we will agree that this is an optimisation we can put aside for a
moment. I think I can just query everything at once and put a TODO note there.

I think that the resolver having some flags is a good thing and might turn
useful at other locations as well. I think I'll just add a flag entry to the
interface and say that they will appear some time soon.

> > The detection will be no problem I think. I'm afraid little bit about the
> > notifications, since the nameserver might be already out of the LRU list and
> > hash table and still used by a zone. So we either need to ignore this one, do
> > something on TTL expiration or have some linking there.
> 
> I don't think this is a problem.  The NS RRset just contains a list of nameservers; if the zone contains any that are not in the RRset, drop them.  And if there nameservers in the RRset that are not in the zone, add them.  If any of the new nameservers correspond to an entry in the nameserver entry hash table link to that, else create a new entry.

Well, no, I mean if cache finds an update of a A record, it needs to notify it.
But if it is not in the nameserver hash table, it is unreachable, unless there's
a direct pointer from the cache (searching trough all zones is unusable).

> > The problem there would be to correctly remove them from the hash at the
> > destructor, but some clever locking should solve it.
> 
> That is a thought but you would need to detect when the reference count is 2 (so the nameserver entry is pointed to only by the zone and the hash table).  The documentation for shared_ptr::use_count() says "use_count() is not necessarily efficient.  Use only for debugging and testing purposes, not for production code".

No, I'd use a weak pointer, so it would not be held alive by the hash table
only. I'm not worried about that at all. The thing I worry about is thread
safety.

So either we do some good locking in the destructor (but it seems to be too
late) or use modified shared_ptr that removes it from the hash table first and
deletes it afterwards. This one seems slightly tricky, but should be possible to
solve.

> If this does work, as well as simplifying the code it would remove a bottleneck with the nameserver entry LRU list.

Ok, we will agreed that this is a think we want to do sometime. I think it also
saves some resources and makes the RTT more accurate, as it eliminates
duplicates.

> > Does it bring anything else than just not having duplicate addresses? I do not
> > see much benefit there.
> 
> It means that the RTT information is more accurate, being the result of queries to multiple names.

Yes, probably. How common do you think the situation is? Do you think we could
get some numbers somewhere?

> I mentioned it because of the possibility; if it were common, then we would save time when the address object is created because we would access an existing structure instead of creating it from scratch.  But I take your point - let's leave it for now and mark it as something we could look at when investigating performance.

OK.

> The problem is exemplified by something like:
> 
> 	example.net NS ns1.example.net
> 	ns1.example.net A 1.2.3.4
> 
> ... in the parent.  That data is not authoritative but without using that information, you can't access the authoritative data.

Yes, but that is only from the NSAS. Or maybe not, as someone might use us as a
backend for own traversing of the zone structure.

Does anyone remember what the RFCs say here? Or should I try to find something?

> > Yes, that's why I want to propose the cookie. It would hold small piece of the
> > cache and when passed with the request, cache would fallback there. The cookie
> > would not be subject to the eviction, therefore 0-TTL data would survive, would
> > be used just for the request that got the cookie and when dropped, the hold data
> > would get reference count to 0.
> 
> That would work.  Providing the cache can be encapsulated as a single object, we could just create a (new, empty) instance of the cache to use as the cookie.

Not really empty, it would contain the currently inputted data, but yes, kind of
that. The data would be shared pointers to save copy, so the cookies would be
cheap. And the cookie would contain only the cache internal structure, the
lookup in the cookie would be done inside the call to the main cache (because we
want to look into the main cache first anyway). But yes, that is the rough idea.

Do you think that requirement for a cache is sane? And that passing this around
is OK? In the todays call, Shane mentioned tagging entries, so we will need to
carry some kind of state object with us anyway, so maybe being able to put the
cookie into that (so that NSAS code could be completely oblivious about the
cookie existence).

Thanks

Have a nice day

-- 
The cost of living is going up, and the chance of living is going down.

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/20101202/d65f337e/attachment.bin>