[Unbound-users] NOTIFY implementation to unbound

[Greg A. Woods]

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://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20091020/1b3b9ebd/attachment.bin>