[bind10-dev] Resolver - address database requirements

[Jerry Scharf]

OK, A couple comments from the peanut gallery.

For recursive servers, the idea of a 'database' could be misconstrued. 
Since all the data is transient, perhaps a better name might be used.

The normal way I have seen this is that as a query consisting of a 
qname, qclass, qtype tuple comes in, it is searched for in the transient 
store. If it is there and the ttl is still valid, the answer (or 
negative) plus any additional data is returned in the fast path.

If the answer is not there, the query is stalled and the search for the 
answer begins. If a second query comes in for the same tuple, it is 
attached to the first query as waiting for the answer to come back. When 
the answer is determined, all the queries waiting for the tuple are then 
answered. This is kind of the opposite of atomicity.

For the size cap, in the ideal case it is LRU based rather than record 
TTL. I don't care what www.google.com's TTL is, I don't want it flushed 
rather than some random name that has been used once. An interesting 
question would be whether a single hit from the cache on the tuple would 
be enough to split the store effectively enough to make flushing easier. 
In other words, if we only flushed tuples that had never been asked for 
a more than once, would this produce good results and simplify the flush 
opeation?

I think the point of not doing the flush during the fill operation is 
not such a big one. You are already out of the fast path. What I do 
think is true is that you never want to take a single entry out of the 
cache, you always want to flush enough entries to allow the server to 
operate for a while before the next flush.

jerry

On 10/02/2010 06:14 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> Just few random ideas while reading it, if they are of any use.
>
> On Fri, Oct 01, 2010 at 11:15:34AM +0100, Stephen Morris wrote:
>> Adding Names
>> -------------
>> 1) It must be possible to add a domain name to the database:
>> * Adding a new name will cause the database software to issue lookups for the A/AAAA information of the associated nameservers and store that information.
>> * As adding a new name will be associated with the need to use the address information, and since the address information may take time to acquire, it should be possible for the caller to specify a callback function that will be called when the address information arrives.
>>
>> 2) The names in a given class should be distinct, e.g. example.com class IN is distinct from example.com class CH.
>>
>> Looking up Names
>> ----------------
>> 3) It must be possible to look up a name in the database.  The lookup will return the addresses associated with the name subject to:
>> * If only IPv4 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
>> * If only IPv6 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
>> * If both IPv4 and IPv6 addresses have been requested, both IPv4 and IPv6 addresses will be returned.
>> * If an address is marked as unreachable, it will not be returned unless explicitly requested.
>>
>> 4) The returned address information should contain round-trip time (RTT) information.
>> * The RTT should be an integral number of microseconds.
>
> 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.
>
> 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.
>
> I think this should be atomic operation so we do not have these race conditions.
> Not that they would be bad, because we will have something like „This is not in
> the DB yet, but it is already requested“, so it could be solved here as well.
>
>> 7) If the address information associated with a nameserver reaches its TTL, the information should be fetched again the next time address information is required.
>>
>> 15) To limit memory usage, it should be possible to limit the number of names in the database.
>> * If a new name is added and takes the count over the limit, another name should be dropped.
>
> These look like expensive operations (with the TTL, we could wait until someone
> asks for it or is dropped due to 15), but it seems to lack elegance). Would it
> be possible to have them in „not exact“ manner ‒ if there are too many items in
> the DB, run a background task that clears the DB of outdated and not much used
> items and drop something like 10% of the database?
>
>
> 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)?
>
> Have a nice day
>
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev