[Unbound-users] NOTIFY implementation to unbound

[Ondřej Surý]

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?

> Everything else stays the same -- the cache is re-loaded ONLY on demand.

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