Op 16-04-2020 om 16:05 schreef Richard Gibson: > Doesn't that preclude scenarios in which a zone transitions from one > catalog to another?
Not necessarily, but we do need to provide more text here to describe precisely how that would work yes. So thanks for bringing that up! Something like: When a member zone is removed from a specific catalog zone, an authoritative server MUST NOT remove the zone and associated state data if the zone was not configured from that specific catalog zone. Only when the zone was configured from a specific catalog zone, and the zone is removed as a member from that specific catalog zone, the zone and associated state MUST be removed. Subsequently, after removal, an implementation MUST check if another catalog zone is present with has the zone as a member. In that case the zone must be configured and associated according to the set of configuration associated with that catalog zone. If there are multiple other catalog zones which have the previously removed zone as member, one should be picked randomly. This is just a quick sketch text proposal. I've submitted an issue for it in our github repo: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/9 -- Willem > > On 4/16/20 09:17, Willem Toorop wrote: >> An authoritative nameserver might have two or more catalog zones, each >> associated with their own set of configuration. In that case, the >> member zone that was configured first (and associated with the settings >> of the particular catalog zone it was a member of) will keep that >> association, regardless of it being a member zone of other catalog zones >> as well. >> >> >> -- Willem _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop