Re: Is it possible to move a zone between catalogs on the same secondary? It is.

2023-05-02 Thread Aram Sargsyan

> 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?

That's an interesting suggestion, and I agree that it can solve the race 
between the two catalog zones in that particular case, but I think it should be 
acceptable for the operator that a member zone, which is in transition from 
catz1 to catz2, can be served by either of the catalog zones until the 
transition is over, and the entry with its "coo" property is removed from 
catz1. Skipping to load a member zone based only by the existence of a "coo" 
property can potentially leave the zone unloaded if it is still not added in 
the successor catalog zone. I.e. the "coo" property can be added into the old 
catalog zone in preparation, for example, hours before the member zone is added 
into the new catalog zone. 
  
Aram 
 
-- 
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


Re: Is it possible to move a zone between catalogs on the same secondary? It is.

2023-05-02 Thread Petr Špaček

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


Re: Is it possible to move a zone between catalogs on the same secondary? It is.

2023-04-30 Thread Aram Sargsyan

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. 
  
Aram 
 
-- 
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


Re: Is it possible to move a zone between catalogs on the same secondary? It is.

2023-04-21 Thread Jan-Piet Mens
And yes, you can automate this with nsupdate to old and new catalog, 


Brilliant, Petr, thank you.

I saw some of the loviest log messages this week during coo from k-catz to
t-catz:

zone t-catz/IN: transferred serial 10: TSIG 't'
catz: t-catz: reload start
catz: updating catalog zone 't-catz' with serial 10
catz: deleting zone 'z10.aa' from catalog 'k-catz' - success
catz: adding zone 'z10.aa' from catalog 't-catz' - success
catz: t-catz: reload done: success
catz: catz_delzone_cb: zone 'z10.aa' deleted
zone z10.aa/IN: Transfer started.
zone z10.aa/IN: transferred serial 1: TSIG 't'

The spec says:

"The old owner may remove the member zone containing the coo property
 from $OLDCATZ once it has been established that all its consumers have
 processed the Change of Ownership."

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.

Once I remove the offending zone from the 'giving' catalog, the diagnostic
doesn't reappear.

All this is with today's git version.

Best regards,

-JP
--
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


Re: Is it possible to move a zone between catalogs on the same secondary?

2023-04-20 Thread Petr Špaček

On 19. 04. 23 19:23, Jan-Piet Mens wrote:

Any ideas?


is this the point at which I confess I've only now read about Change of
Ownership (coo) [1]?


Indeed. Chapter
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-catalog-zones#name-change-of-ownership-coo-pro
has an example how the process is supposed to work.

And yes, you can automate this with nsupdate to old and new catalog, 
just beware that you need to wait until the change is propagated to all 
secondaries before moving on. (AFAIK order of operations is important, 
do it exactly as specified.)


HTH.

Petr Špaček
Internet Systems Consortium



 -JP

[1] 
https://bind9.readthedocs.io/en/latest/chapter6.html#change-of-ownership-coo

--
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


Re: Is it possible to move a zone between catalogs on the same secondary?

2023-04-19 Thread Jan-Piet Mens

Any ideas?


is this the point at which I confess I've only now read about Change of
Ownership (coo) [1]?

-JP

[1] https://bind9.readthedocs.io/en/latest/chapter6.html#change-of-ownership-coo
--
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


Is it possible to move a zone between catalogs on the same secondary?

2023-04-19 Thread Jan-Piet Mens

I'm in the process of migrating a modest number of zones from one signer 
(OpenDNSSEC) to another (Knot-DNS). (The KSKs are identical so that should not 
be an issue for this question.)

Each of the signers have a catalog (manually maintained for ODS, automatically 
for Knot) which is transferred and consumed by BIND 9.18 secondaries; each of 
these have two catalog{} stanzas on each server.

The trouble I'm going to be running into is when a zone should move from catz-A 
to catz-B: in this case the zone must be removed from catz-A (whereupon it'll 
be deleted when the catalog is notified/transferred) and added to catz-B 
(whereupon it will be populated when the catalog is notified/transferred). 
During this (possibly quite short) time, the zone will not be available on the 
secondaries (REFUSED).

Is there a clever/elegant solution to this problem?

My first idea was to use the same zones-directory for each of the catalogs, but 
a) I don't know whether that's actually a supported configuration and b) it 
would likely not solve the issue because the catalog name is embedded in the 
__catz__...*.db zone filename.

Adding the zone to both catalogs won't work either (obviously) because the zone would 
"exist twice"; BIND catches that error and correctly logs it.

Any ideas? Bonus points if the solution can be automated. :)

Thank you,

-JP
--
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