Hi Wes, On 2013-04-24, at 09:18, Wes Hardaker <[email protected]> wrote:
> I > think part of the problem has been we don't have a good list of > requirements to compare any given solution to and we're talking around > them all because they're not written down (at least in one place). I like your list. I think it's useful. I think it's also instructive to write down the workflow of how changes might occur. For example, 1. each polling party (registry, registrar, parent zone operator, something) maintains a list of child zones that should be polled for CDS RRSets (which could be "all children", "all customers who have clicked a button to say they want to be polled", "child zones that we publish a DS for" or something else) 2. those child zones are polled regularly and the result is occasionally the construction of change requests for the DS RRSet 3. the polling party satisfies their requirements that a change should be made (e.g. automatic so long as technical checks pass, signal the child zone operator and request an out-of-band confirmation, something else) 4. the change is made in the parent zone (e.g. through direct changes to a locally-maintained parent zone, EPP signalling to a registry, something else) Perhaps this could be made more general, but those four steps seem fairly integral to me, regardless of the shape of the relationship between child zone operator and parent zone operator. A parent zone operator who wants to generate her own DS RRSets for a child zone could use the CDS signalling as method to identify a DNSKEY, could retrieve the DNSKEY RR in question (checking signatures) and generate their own DS RR for publication. The problem of how to signal the desire to publish a DS for a key that has not yet been published remains. It occurred to me that there may be use cases where including a "do not process before <date>" and "do not process after <date>" on a CDS RR might be useful, especially if the time taken for the parent to poll is not predictable. But I haven't thought that through very hard. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
