Maintained by: NLnet Labs

[Unbound-users] NOTIFY implementation to unbound

Marcus Alves Grando
Wed Oct 7 15:59:05 CEST 2009


On 10/07/2009 06:09 AM, Olaf Kolkman wrote:
> 
> 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).

Yes, it can be done, but not for all entries. My concern is about when
you need to change something fast or some service change IP. To do this
without notify you need to loggin in all servers and flush zone.

One example is DNS RR, if you need to take off one server, you need to
flush. If you decrease TTL to much you increase load in your servers.

Best regards

-- 
Marcus Alves Grando
marcus(at)sbh.eng.br | Personal
mnag(at)FreeBSD.org  | FreeBSD.org