[bind10-dev] Resolver - address database requirements

[Evan Hunt]

> 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