slaves still serve old data after successfull zone transfer (with views)

[Aleksandar Milivojevic]

Quoting Kevin Darcy <kcd at daimlerchrysler.com>:

> Aleksandar Milivojevic wrote:
>
>> Hi,
>>
>> I've browsed through some documentation about views, consulted the
>> book, but still need one clarification.  Is it OK to share same zone
>> file between multiple views?

> Sharing zone files between views is a "feature" that AFAIK was never
> really designed into BIND 9. It just kind of works, on a master server.
> A slave, however, will assume that it has complete control over the
> replication of the zone data, so if one view happens to do a transfer of
> a zone, other views which might reference the same zone file have no
> clue about this, and for them, the change will propagate on the next
> refresh cycle, which could be hours away. If you want faster propagation
> of changes to the slaves, you'll need to re-enable NOTIFYs and zone
> transfers in the foo and bar views. For safety's sake, you should also
> define different slave zone files on the slaves, otherwise you risk
> corruption if two zone transfers happen to be writing the file at the
> same time.

Thanks for the explanation.

However, I don't think re-enabling notifies in all views on master will 
help a lot, unless I upgrade to 9.3.x and use keys to match views (I 
guess, not sure).  With BIND 9.2.x, the notify is going to come from 
the same IP address, and only the zone in view that matches this IP 
address will get updated.

I guess for this to work correctly, BIND would need to know that zone 
is shared between multiple views.  But this would be new feature 
request.

For example, it would be very nice and flexible feature if zone could 
be defined outside of any view if it contains special keyword telling 
to which views it belongs.  Something like:

view "one" { ... };
view "two" { ... };
view "three" { ... };
zone "foobar.com" in {
    views { "one"; "three"; };
    type slave;
    masters { 1.2.3.4; };
    file "db.foobar.com";
};
zone "foobar.com" in {
    views { "two"; };
    type slave;
    masters { 1.2.3.4; };
    file "db.foobar.com-two";
};

That way, BIND would also save on resources, since it would use only 
one instance of zone data for views "one" and "trhee" (from example 
above).  It might still send multiple notifications when zone is 
updated (depending when, where and how notify option is used), but 
slave would need to transfer zone data only once (since it knows it is 
the same data).


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.