[Unbound-users] NOTIFY implementation to unbound

[Ondřej Surý]

On Mon, Oct 19, 2009 at 19:27, Ondřej Surý <ondrej at sury.org> wrote:
> On Mon, Oct 19, 2009 at 19:11, Greg A. Woods <woods at planix.ca> wrote:
>> At Wed, 14 Oct 2009 19:13:10 +0200, Peter Koch <pk at DENIC.DE> wrote:
>> Subject: Re: [Unbound-users] NOTIFY implementation to unbound
>>>
>>> the NOTIFY semantics are clearly only defined between a master originating
>>> the message and a slave acting upon it.  It currently uses the SOA RR
>>> to initiate an SOA check and subsequent *XFR processing.
>>
>> Well, Duh!  :-)
>>
>> The key concept here is that notify says something has changed with the
>> given zone.
>>
>>> First of all, a recursive resolver is zone agnostic, it doesn't - and
>>> doesn't have to - know where the zone boundaries are, i.e. how far
>>> down the tree to flush the cache.  Second, a recursive resolver has no
>>> means to reload a zone.  Of course, one could start descending down the
>>> tree and re-query all cache content or do other fancy things.
>>
>> You make things _soooo_ complicated!  K.I.S.S.
>
> Peter just described current state, but you are oversimplifying them.
>
>> Unbound is a caching only nameserver.
>>
>> It doesn't have to know about zones, sub-zones, etc.  It doesn't have to
>> reload anything.
>>
>> All it has to do is flush records that _MAY_ now be out-of-date -- and
>> that's _everything_ matching the domain given in the NOTIFY.
>
> So if I send you NOTIFY . (the root), you flush the whole cache?  And
> if I send you a notify for .cz, you will walk through the whole cache
> and flush everything which ends in .cz or .com? I don't know exact
> design of unbound cache, but I guess it's more hash like table then
> tree like table, so how would you do that and not lock down whole
> resolving meanwhile?

I read the source code (daemon/remote.c) meanwhile and it does lock
the hash tables for cache (and validator cache). And I guess you don't
want to lock your cache for flush every time you receive notify. We
are not speaking about small company deployment, but also about big
caches at ISP level. And clearly this approach doesn't scale very
well. (On the other hand setting low TTL on fast flux zones/records
does scale very well.)

O.
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/