search

NLnetLabs / draft-toorop-dnsop-dns-catalog-zones

Work on catalog zones
3 stars 11 forks source link

Describe how zone transition from one catalog to another would work. #9

Closed wtoorop closed 3 years ago

wtoorop commented 4 years ago

Sketch text: 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.

I am pretty sure this can be expressed/described much more clearly.

Brought up by Richard Gibson and Bob Harold

Should we facilitate not losing the state when unique id stays the same in different catalogs? I'm inclined to say no.

gibson042 commented 4 years ago

For the use case I have in mind (live reassignment of a zone's upstream primary), I would want atomic replacement rather than remove-then-add.

wtoorop commented 4 years ago

@gibson042 do you mean without removing state and/or zone content?

It is already be pretty "atomic" when the zone already exists as a member of the catalog to which to move the zone to. Though with the description above, the zone would have to be transferred from scratch from the new primary (in your use case scenario).

We could facilitate moving zones between catalogs without resetting state in our draft. For example by requiring that zone content and state should not be removed if the unique id in the new catalog is the same as the one from which it was removed.

@gibson042 would that cater for your use case better?

gibson042 commented 4 years ago

Yes, definitely. :+1:

wtoorop commented 3 years ago

/me just pushed pr #12 which (when merged) should resolve this issue

Habbie commented 3 years ago

We merged #16 instead. Richard, if you feel we somehow managed to not cover your needs now, please mention that on dnsop after we post the new draft revision later today. Thanks!