Hi Warren, On 09/27/2013 04:27 AM, Warren Kumari wrote: > > On Sep 26, 2013, at 12:05 AM, Matthijs Mekking > <[email protected]> wrote: > >> Hi, >> >> I thought it would be good to start a thread about CDS or CDNSKEY, >> given the recent discussion on dnssec-deployment. > > Thank you! > > I'm off at another meeting and that thread got away from me… :-) > >> >> CDS is a nice proposal for automating the the delegation signer >> information at the parent and is able to deal with all possible >> rollover scenarios. > > Yup. > >> It's drawback however is that it cannot be used by registries that >> require the delegation signer information to submitted as DNSKEY. >> >> There are two straight-forward solutions for this, imo: >> >> 1. New RRtype: CDNSKEY Which is similar to CDS except it publishes >> the DNSKEY RDATA elements of the to be DS RRset. A parental agent >> that calculates the DS itself would poll for the CDNSKEY RRset. >> >> 2. Adjust the CDS RR format The CDS RDATA is equal to the DNSKEY >> RDATA plus one RDATA element for what (preferred) hash is to be >> used. >> >> The first solution has some minor drawbacks: * It requires a new >> RRtype for something that can also be done within an existing >> RRtype (CDS after changing the format). * For the child signer >> system it would need an additional configuration knob to decide >> whether to publish CDS or CDNSKEY. >> >> Adjusting the CDS RR format makes the CDS proposal compliant with >> both 'requiring DS' and 'requiring DNSKEY' registries. > > > Yup, but the way you have written option 2 (unless I misunderstand) > does't allow for "standby keys" .
It does allow for standby keys. It allows for anything that the current specification of CDS allows for (plus more!). Basically, option 2 is just like the current CDS proposal, but publishes the information unhashed. The additional RDATA element, call it selector if you like, informs about how to hash the record. So if you want a standby key, publish a CDS record for that key, but not its DNSKEY record. > An option that was discussed (sorry, cannot remember if it was onlist > or over a beer) was to have the CDS record be: > > RRTYPE <selector> <data> > > If the selector is 0, then the data element is a DS record. If the > selector is $something_else then the data is a a DNSKEY. The selector > could be the hash type that you would like... This sounds a lot like option 2 here, only this has different RDATA formats depending on the value of one RDATA element. > AFAIR, the main objections to this was that it makes parsing > *slightly* harder / there is a view that it is less elegant. Yes. I would prefer resource records with a static RDATA format. > So, I *think* basically what you suggested as option 2, but if the > "what (preferred) hash is to be used" part is e.g 0, then the data > bit is already hashed. What I suggested is always publish a CDS with unhashed information (e.g. DNSKEY RDATA) + a selector RDATA element on which hash to be used. If the selector is 0, it is up to the parental agent. Best regards, Matthijs > > Thoughts? W > >> >> >> Best regards, Matthijs >> >> >> _______________________________________________ DNSOP mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/dnsop >> > > -- Do not meddle in the affairs of dragons, for you are crunchy and > taste good with ketchup. > > > > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
