Maintained by: NLnet Labs

[Unbound-users] NOTIFY implementation to unbound

Peter Koch
Wed Oct 14 19:13:10 CEST 2009

On Wed, Oct 14, 2009 at 12:34:10PM -0400, Greg A. Woods wrote:

> While NOTIFY might be outside the scope of the most strict requirements
> definition for a minimalistic caching recursive DNS resolver (though I
> don't agree with this myself), it's definitely not outside the scope of
> DNS protocols, and it is also the _ONLY_ way to maintain compatibility
> with other nameserver implementations.  If some inter-nameserver
> protocol is to be used to control cache flushing on a per-zone basis
> then NOTIFY is the only one that can realistically be used!  I don't
> understand why you're so blind and/or opposed to this fact.

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.
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.
Nothing like this is covered by RFC 1996 (see abstract and 3.11).
Now, one could come up with all kinds of NOTIFY based cache control, e.g.
inform the (known) caches of all changes to the zone file initiating
a re-query case by case.  But there's protocol work to be done to catch
all the side effects etc.

On the other hand, integration auf "authoritative" data into an unbound
based resolver infrastructure is sometimes really needed, be that for
split view DNS or other purposes -- but it can be done with paired
nsd/unbound on the same system and some tweaking to the caching parameters.