On Mon, Oct 19, 2009 at 19:11, Greg A. Woods <[email protected]> wrote: > At Wed, 14 Oct 2009 19:13:10 +0200, Peter Koch <[email protected]> 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ý <[email protected]> http://blog.rfc1925.org/ _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
