search

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

Work on catalog zones
3 stars 11 forks source link

<unique-N> IDs may be predictable #30

Closed wtoorop closed 2 years ago

wtoorop commented 3 years ago

Which we should mention in the document that some implementations may have that (especially since we abandoned zone state reset by ID change). And in several places in the document what that would entail in that context.

peterthomassen commented 3 years ago

Context how this affects coo migration between catalog zones: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/29#discussion_r695720567

wtoorop commented 3 years ago

This has consequences for so many things in the document, that I think it should be described in a follow-up document. We can than also settle on what hash to use etc. Support for it can then be signaled in the Schema property (which allows for more than one RR to support backwards compatibility). @peterthomassen What do you think?

peterthomassen commented 3 years ago

tl;dr: Sure, sounds good to me!

My earlier stakes were with respect to what has become draft-thomassen-dnsop-dnssec-bootstrapping in the meantime. My thinking was that the "signaling zones" mentioned in that draft are structurally similar to catalog zones, so I thought it would be nice if one could be built on top of the other. But I see now that there are also benefits to not bending things for compatibility with catalog zones, so that motivation for my argument is no longer there. (For example, the zone-identifier label in the above draft is now actually two labels, which is not how catalog zones work.)

I still think that predictable labels would be helpful for catalog zones, too, especially to avoid wait times during catalog migration. But I'm not a catz implementor, so I don't feel strongly. :-) :cat:

peterthomassen commented 2 years ago

This has consequences for so many things in the document, that I think it should be described in a follow-up document. We can than also settle on what hash to use etc. Support for it can then be signaled in the Schema property (which allows for more than one RR to support backwards compatibility). @peterthomassen What do you think?

Doing this in another document means this is out of scope for the current document, so the issue should be closed.