[bind10-dev] Resolver - address database requirements

[Jerry Scharf]

  Evan,

Thanks for your response.

You are completely correct, I mistook what he was talking about. 
Tracking nameservers with their RTTs was not what I was thinking of when 
I wrote my response. I think the use of names and talking about A 
records rather than nameservers and zones had me very confused. I think 
some terminology work is needed and then send it out again.

jerry

On 10/3/2010 9:29 AM, Evan Hunt wrote:
>> For recursive servers, the idea of a 'database' could be misconstrued.
>> Since all the data is transient, perhaps a better name might be used.
> Any name is fine; I think the reason BIND9 refers to this as "address
> database" (adb) is to distinguish it from the cache, which is a different
> animal.
>
>> 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.
> ...actually, this sounds like you might be talking about the cache.  What
> Stephen is discussing is transient storage for nameserver addresses only.
> The data structure would do things like determining the RTT for each NS
> address so that queries will favor the shortest RTT, suppressing queries
> to addresses that are servfailing, etc.  The regular DNS cache doesn't do
> that stuff.
>
> Also, unlike the DNS cache, you probably don't want to query it via the
> <name/class/type>  tuple; the level we're most interested in is "give me
> all the currently valid NS addresses for the zone 'example.com' sorted in
> priority order".
>
> We may end up using the same data structure polymorphically to store
> both DNS cache and nameserver address data, but the requirements for
> the two aren't the same.  They are kind of similar, though, which makes
> it easy to mix them up and design for one of them while actually working
> on the other one, and I'm just saying let's avoid that. :)
>
>                                          eh
>