[Unbound-users] NOTIFY implementation to unbound

[Olaf Kolkman]

On Oct 6, 2009, at 11:22 PM, Marcus Alves Grando 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?


I'm reading this with interest, and wonder why the TTLs on the  
authoritative data is not tweaked to reflect the dynamic nature of  
(certain data).

--Olaf




________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20091007/7f3b4988/attachment.bin>