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
