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ý <[email protected]> wrote: Subject: Re: [Unbound-users] NOTIFY implementation to unbound > > On Tue, Oct 13, 2009 at 20:53, Greg A. Woods <[email protected]> wrote: > > At Thu, 8 Oct 2009 10:41:20 -0400 (EDT), Paul Wouters <[email protected]> > > 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...@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 <[email protected]> Planix, Inc. <[email protected]> Secrets of the Weird <[email protected]>
pgpz7f1CtIl4f.pgp
Description: PGP signature
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
