On 2013-03-05, at 11:54, Paul Hoffman <[email protected]> wrote:
> On Mar 5, 2013, at 8:44 AM, Paul Wouters <[email protected]> wrote: > >> That said, I'm still with the authors. Keep the CDS format identical to >> the DS format. (and let parent and child local policy determine what to >> do with the CDS RRset) > > Seeing that at least a few zones have a good reason to take DNSKEY as input > to their "add a DS" process, I propose the CDS add another type of record, > CDNSKEY. Only one of CDS and CDNSKEY is allowed in an RRset to prevent silly > states. I presume this has already come up, and there are good reasons why the apparent lexical flexibility in what I'm about to suggest are swamped by a sea of vicious snakes, but if the goal is "transmitting general information to the parent which in some cases they might care about" why not think about a more general RRType of the form ; zone cut example.com. IN SOA ... ; example.com. IN PARENT DS parental-hints.example.com. example.com. example.com. IN PARENT A ns1.example.com. ns1.example.com. example.com. IN PARENT A ns2.example.com. ns2.example.com. example.com. IN PARENT AAAA ns2.example.com. ns2.example.com. example.com. IN PARENT NS example.com. example.com. ; example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com. ; ns1.example.com. IN A .... ns2.example.com. IN A .... ns2.example.com. IN AAAA .... ; parental-hints.example.com. IN DS .... A parent that cared (tm) could seek a secure answer to child/IN/PARENT and extract RRSets pertinent to the delegation (NS, A, AAAA, DS, etc). Each PARENT RR provides an RRType and an owner name where the record in question can be found, together with an owner name that the parent should presume applicability. I have not thought this through very well, but in general it seems to me that if we're going to create a mechanism by which zone data in a child can be interpreted flexibly by a parent, standardising a new RRType for every possible interesting RRSet seems annoying. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
