[bind10-dev] Resolver - address database requirements

[Michal 'vorner' Vaner]

Hello

On Sat, Oct 02, 2010 at 02:18:15PM -0400, Robert Edmonds wrote:
> Michal 'vorner' Vaner wrote:
> > 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.
> 
> resolvers should definitely avoid sending multiple queries with the same
> qname/qtype/qclass, as not doing so weakens the protections against DNS
> spoofing.  see:

No, I meant that with „lookup“ and „add“ functions, you need more complicated
checks of what you are doing, that not sending multiple same queries would be
harder to code. You know, the lazy approach ‒ less code means less bugs ;-).

> it is fairly easy to avoid having to implement a "background task" and
> the associated concurrency problems if you're willing to add two extra
> pointers to each node in the address database to implement a doubly
> linked list for the purpose of LRU expiration.

Well, if the library should be thread-safe, we need to have the concurrency
problems anyway. So a background task wouldn't be a lot more work (maybe less,
compared to „I need to lock 4 nodes and tail when I take the name from the
middle to the tail“). But you are right that with the linked list, the task of
cleaning is much less expensive and can be done in each query. But as I
mentioned in another answer in this thread, I think the background task could
possibly be more efficient and less intrusive to the ongoing queries. But I
might be wrong, of course.

Thanks

Have a nice day

-- 
The difficult we do today; the impossible takes a little longer.

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/20101003/de086780/attachment.bin>