Maintained by: NLnet Labs

[Unbound-users] NOTIFY implementation to unbound

Aaron Hopkins
Wed Oct 14 20:48:43 CEST 2009


On Wed, 14 Oct 2009, Greg A. Woods wrote:

> Using some sort of local "update" protocol is highly desirable as it
> allows the best of both worlds in those cases where it work.  NOTIFY
> _is_ this protocol within the scope of the DNS infrastructure.

I agree that this is the standard protocol for saying "something changed
with this zone".  I haven't found anything suggesting that this should or
must only operate on only authority data.

However, without the ability to check SOA serial numbers on everything in
the cache, there's a race condition with using NOTIFY like this.  Let's say
you run unbound along with two authoritative nameservers, ns1 and ns2, with
ns2 slaving example.com from ns1.  You configure ns1 to send notifies to ns2
and unbound.  The race condition is that ns1 updates example.com, notifies,
ns2 starts its zone transfer and unbound clears its cache for that zone. 
Unbound then immediately looks up example.com from ns2 and caches it, prior
to the zone transfer completing.  Amusingly, by notifying, you've just
extended the time that the stale example.com lookup stays cached.

This can be sort of fixed by always notifying from all authority servers to
all recursive servers on all updates, but that's not obvious and doesn't
scale terribly well.

The right answer is to only clear unbound's cache after all authority
servers are showing the updated SOA for the zone.  This logic sounds too
complicated to add to unbound itself, but the suggested external daemon that
receives notifies and runs unbound-control could do this.

                                     -- Aaron