[bind10-dev] Resolver - address database requirements

[Jerry Scharf]

Stephen,

I am sorry to be so picky about it, but you immediately drop back to 
adding and looking up 'names.' It may be cumbersome, but if you stick 
with 'nameservers' all the way through, simple minds like mine won't 
wander off track.

jerry

On 10/04/2010 01:55 AM, Stephen Morris wrote:
> Trying to summarise and answer the post over the past few days on the address database requirements
>
>
> Terminology
> The name "Address Database" was used because that is the term that BIND-9 uses.  I agree thought with Jerry's point that terminology work its needed.  It occurs to me that names thought up on the spur of the moment when discussing/designing a component have a tendency to stick. We understand then because we were involved in their inception, but they could confuse future developers and maintainers.  "database" does tend to suggest something on disk; and anything with "cache" in it runs the risk of getting confused with the main cache.  How about "Nameserver Address Store"?
>
>
> Add/Lookup
> Michal noted the following:
>
>> Adding and looking up a name should maybe be one operation? Because if you look
>> up and it isn't there, you ask the database to add it there. What the user of
>> the database really wants is „get me the address somehow“. If the database needs
>> to query it or has it already or it finds out it is out of date and needs to
>> refetch it is up to it.
>
> Michal is correct, there is no explicit "create" operation - a caller will want to look up an address and the code creates an entry for it if it is not there.
>
>
> Multiple Outstanding Queries
> (Michal)
>> Furthermore, if there's a situation:
>> • Request 'a' about example.net. The database does not have it. So it is asked
>>   to add/fetch it.
>> • Request 'b' about example.net in the time between 'a' got answer „no data in DB“
>>   and 'a' asked to add it there. So it asks to fetch it again.
>
>
> We shouldn't need to worry about multiple simultaneous queries because the address store will be calling back to the main resolver code to issue those queries, and that code should prevent multiple outstanding queries for the same information.  However, issuing requests for the A records for all the servers is not completely straightforward - we need to take account of cases like the one Jelte brought up last month with _tcp.slb.com (which has 267 nameservers).  Unless the resolver code limits the number of nameservers for one domain name, the address store code should limit itself to at most two or three outstanding fetches for each domain name.
>
>
> Limiting the Number of Names in the Store
> As has been pointed out, this is fairly simple to do; hook the names onto a queue and delete the names at the head of it.  A LRU algorithm would seem to be the best although there is more contention in locking and unlocking a LRU queue that there would be if we were to use a FIFO queue. Rob's suggestion of a lock-less per-thread LRU queue is interesting though, although I guess there is more overhead involved in removing an entry when the TTL is reached, as the entry could be in more than one of these queues at the same time.
>
>
> Scope of the Code
>
> Michal wrote:
>>
>> And I'm still thinking about how clever the database should be. If it selects
>> the right address and queries the server itself to see the RTT and stuff, or if
>> it should be really dumb, giving out a Zone object, letting the requester choose
>> the address and update the RTT and stuff on the object. Maybe a dual-layer (the
>> dumb is inside and the clever thing around it)?
>
> I think it ought to be up to the store to choose the address and pass the selected address back to the main resolver code.  Quite apart from choosing the lowest RTT, something needs to periodically choose other addresses to see whether their RTT has changed or whether they have become unreachable. The address store can record how often an address has been used, when it was last used etc.  It can also do clever things with unreachable addresses - don't consider it for 10 minutes, if the address is still unreachable, back off for even longer etc.  In fact for unreachable addresses it would be possible for the code to initiate a query in its own right to test if there is a response before considering it for use again.
>
>
> Stephen
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev