[Unbound-users] NOTIFY implementation to unbound

[Marcus Alves Grando]

On 10/07/2009 06:08 AM, Ondřej Surý wrote:
> On Tue, Oct 6, 2009 at 23:22, Marcus Alves Grando <marcus at sbh.eng.br> 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