At Mon, 19 Oct 2009 11:41:08 -0700 (PDT), Aaron Hopkins <lists at die.net> wrote: Subject: Re: [Unbound-users] NOTIFY implementation to unbound > > On Mon, 19 Oct 2009, Greg A. Woods wrote: > > However if _all_ the slaves are configured to send NOTIFY to Unbound > > (including, or excluding, the true master) then the last one to reload > > will cause a final flush of Unbound's cache and all will be well. > > > > Sorry I didn't make this concept clear before. It was so obvious to me > > I forgot to mention it! :-) > > I'm not sure that this will be obvious to everyone or possible in many > topologies, and will lead to non-deterministic behavior that many people > will interpret as a bug in unbound. I'm not sure what you're getting at here. In face of updates and changes the DNS _is_ non-deterministic, kinda by design. I think all we've been discussing in this thread is a simple mechanism to allow easy internal control over the cache for certain zones in an intimate setting of close-nit nameservers. Typical sysadmin behaviour I've seen in the past is to simply restart the caching nameservers completely from scratch if updates have to be pushed through to local clients ASAP. Anything better than that is a huge improvement. > > BTW, performance considerations are secondary (or even tertiary). > > It depends on how long each flush locks a big cache. How many queries are > you willing to drop on the floor with each NOTIFY? Are you willing to do so > with all of your recursive servers simultaneously? I'm saying performance considerations are simply not important AT ALL when dealing with NOTIFY messages from trusted authoritative servers. This is a simple short-cut to clear potentially stale locally important records from locally used cache servers with the primary importance being placed on interoperability and automation. Manually logging into each cache server and running "unbound-control flush" (or even more brutally, restarting Unbound) is going to lead to equally non-deterministic results, and it's also a lot more effort to have to go through. I for one am not talking about ideal designs or perfect implementations, but rather simple operational concerns that still have to be dealt with in the real world. -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack <woods at robohack.ca> Planix, Inc. <woods at planix.com> Secrets of the Weird <woods at weird.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20091020/1b3b9ebd/attachment.pgp>