[Unbound-users] NOTIFY implementation to unbound

Wed Oct 14 16:34:10 UTC 2009

I'm not sure it'll be productive to try to have a conversation with you
about this issue in this forum, but I guess I'll give it a go....

At Tue, 13 Oct 2009 22:11:57 +0200, Ondœô ùej Surý <ondrej at sury.org> wrote:
Subject: Re: [Unbound-users] NOTIFY implementation to unbound
> 
> On Tue, Oct 13, 2009 at 20:53, Greg A. Woods <woods at planix.ca> wrote:
> > At Thu, 8 Oct 2009 10:41:20 -0400 (EDT), Paul Wouters <paul at xelerance.com> wrote:
> > Subject: Re: [Unbound-users] NOTIFY implementation to unbound
> >>
> >> On Thu, 8 Oct 2009, Marcus Alves Grando wrote:
> >>
> >> > The main idea is create one way to recursive server keep all my zones
> >> > freshly, without update all process or less as possible.
> >>
> >> Would using a forward zone address this?
> >>
> >> # Forward zones
> >> # Create entries like below, to make all queries for 'example.com' and
> >> # 'example.org' go to the given list of servers. These servers have to handle
> >> # recursion to other nameservers. List zero or more nameservers by hostname
> >> # or by ipaddress. Use an entry with name "." to forward all queries.
> >> # forward-zone:
> >> #     name: "example.com"
> >> #     forward-addr: 192.0.2.68
> >> #     forward-addr: 192.0.2.73 at 5355  # forward to port 5355.
> >>
> >> The description does not make it clear whether or not the responses are
> >> always forwarded, or whether they are cached.
> >
> > I've been wondering the same thing for a long time now.  I think based
> > on my experience with one site where I've set up unbound using
> > forward-addr they are cached, which would-be/is (IMHO) wrong.
> 
> Why?
> 
> I don't consider this wrong - Unbound is full caching resolver and not
> just stub resolver. I guess it could be per forward option, but it's
> not wrong.

Well, to start with it is in fact logical to read the documentation in
such a way that the word "ALL" is emphasised.  In fact this is where I
differ from the previous claim that the documentation isn't clear.  I
find it to be abundantly clear -- though perhaps not describing the
current implementation accurately.

To be clear:  All means _all_ -- i.e. NO queries for "example.com" are
answered through the cache; all answers MUST come from the listed
servers.

If the documentation is in fact not describing the current
implementation then perhaps someone needs to reveal the original
requirements which lead to the idea of "forward-zone" so that we can
critically analyse them and determine whether it is the documentation or
the implementation which most closely matches the requirements and
correct the appropriate part.

As for what seems to be your overly pedantic attempt to assert that
unbound is a full caching resolver, well, I'm not sure what your point
is really driving at, other than perhaps you'd rather just remove the
"forward-zone" feature entirely because it doesn't fit your minimalistic
idea of what a full caching recursive resolver should be.

> > Ultimately though I like the NOTIFY solution best.
> 
> And it's direct violation of RFC1996. I wouldn't call it "solution",
> but a "hack". While I consider it to be fine for Marcus (it's his
> network after all), I would be extremely unhappy to see this in
> unbound upstream.

Huh?  How can using NOTIFY to inform a nameserver that a zone has
changed and a query should be initiated to discover new data be contrary
to the concepts described in RFC1996?  (Note that my question
effectively paraphrases the very Abstract of RFC1996!)

While using "forward-zone" as a form of application-level router is
obviously one way to do things, and for some purposes perhaps the only
way to do some things, it's necessarily inefficient and possibly also
far more unreliable.

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.

> > Sites converting from BIND will already be using NOTIFY.
> 
> Eh? Could you point me to the bind9 documentation saying that Bind9
> will flush the cache if it receives notify?

I could point you to several BIND sites which use NOTIFY in this way,
not all of which I set up (I didn't invent the scheme -- I just use it
at sites where I've set up BIND).

With BIND the ideal, and most (only) secure, way to serve locally
important zones is to slave them into the local cache servers.  This
forces the whole zone into the local cache with authoritative records
preventing cache poisoning and NOTIFY messages will cause the cache
servers to update their copy of these locally important zones in the
most secure way possible.

> > The so-called "security" issue for NOTIFY is a bunch of FUD-mongering.
> > There are several ways to make sure unauthorised NOTIFY messages don't
> > cause any harm.
> 
> And there are several ways how to make it compliant with existing
> protocols, there were several mentioned and I am adding another one:
> 
> Configure snmptrapd with action to call unbound-control flushcache and
> trigger SNMP trap when zone changes.

Why do you continue to want to add another external unrelated protocol
with a whole new, disjoint, and separate, set of security issues to the
mix?

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.

-- 
						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/20091014/ff132a9c/attachment.bin>