> 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
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
>
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
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
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
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
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
7 matches
Mail list logo
