On 10/07/2009 06:08 AM, Ondřej Surý wrote: > On Tue, Oct 6, 2009 at 23:22, Marcus Alves Grando <[email protected]> wrote: >> On 10/06/2009 06:39 PM, Peter Koch wrote: >>> On Tue, Oct 06, 2009 at 03:10:21PM -0300, Marcus Alves Grando wrote: >>> >>>> This idea doesn't break anything, it just implement an easy way to keep >>>> your info fresh into your recursives dns. The principle of RFC-1996. >>> >>> RFC 1996 deals with messages from a master to its slave(s), so only on the >>> authoritative side. Resolvers are zone agnostic, so this can only work >>> partly and, more importantly, in a controlled environment where the master >>> knows which resolvers to inform. Now, in an enterprise environment this >>> might be the case, but distributing the zone content close to the resolvers >>> and not caching there might be a better option. >> >> That's my point. In an enterprise enviroment we need to resolve our >> locals zones and external zones too. With notify I can use only unbound >> as resolver, pointing our zones to dns master with fast zone update. >> >> Your approach to take zone and put close to unbound have problems, like: >> >> 1. If you use unbound as recursive and put nsd/bind in another port, you >> have protocol overhead. >> 2. If you use unbound with local-zone and local-data you need some >> script to publish and take care. >> >> Why do not take advantage of unbound cache? > > Another problem here is security. Without BCP 38 deployed I can easily > keep your unbound cache flushing over and over and over.
Yes, it's true, but this problem isn't affect only unbound right? But you are right. > Your proposal abuses the protocol and can be implemented with unbound > control which has much more security (TLS). I don't think "abuse the protocol", I think about "using the protocol" :) Besides, the security part are doing like others, using acl. I understand your point and I agree, but I don't think it's possible implement TLS in notify part. Best regards -- Marcus Alves Grando marcus(at)sbh.eng.br | Personal mnag(at)FreeBSD.org | FreeBSD.org _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
