On 30. 04. 23 13:04, Aram Sargsyan wrote:
Hello, Jan-Piet,
> however, when I stop and restart the consumer server, I have
sometimes (not always) seen
>
> catz: catz_addmodzone_cb: zone 'z10.aa' will not be added because
another catalog zone already contains an entry with that zone
>
>which is true, but it doesn't _seem_ to cause issues.
That's just working as designed. If a member zone exists in both catz1
and catz2 catalog zones, and catz1 has a defined "coo" change of
ownership property allowing a given member zone to be transferred to
catz2, then there are two scenarios when a catalog zone consumer starts up:
1. It loads the member zone from catz1 first, then it sees the member
zone exists also in catz2, and the "coo" property allows that, then the
zone will be transferred from catz1 to catz2.
2. It loads the member zone from catz2 first, then it sees the member
zone exists also in catz1, and there is no "coo" property allowing it to
transfer from catz2 to catz1, so it emits the log message that you have
seen, and continues serving the member zone from catz2.
That's why it's recommended to remove the transferred member zone from
catz1, once it is established that all the consumers have successfully
processed the change of ownership operation.
Wondering out loud:
Maybe it should skip loading that particular member zone if the "coo"
proproperty already points to different catalog? Would that be more
resilient against race conditions when named is restarted?
--
Petr Špaček
Internet Systems Consortium
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
