Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

[Marc Lampo <[e-mail]>]

Hello,

somewhat more words but in line with what I was suggesting, a couple
of days ago,
about adding "operation code" to CDS RDATA.

This still feel like a good idea, worth elaborating, I'd see.
I support this.

Kind regards,

Marc Lampo


On Thu, Feb 28, 2013 at 7:56 AM, Edward Lewis <[e-mail]> wrote:
> Having quickly read the -01 for Automating DNSSEC delegation trust
> maintenance:
>
> I'd like to propose a twist.  Comparing to X.509, a CDS record is kinda
> sorta like a key signing request.  For that reason I want to see an explicit
> "request" in the RDATA and not have anything implied.
>
> I would suggest that the RDATA of it *not* be the same as the DS record.
> There should be an explicit RDATA element instructing the parent what to do
> with the request.  Probably some other ancillary data will be needed too.
>
> I would not specify how the parent "discovers" the CDS.  Just as for AXFR,
> knowing how AXFR works is different from why it is called.  I say this
> because in some scenarios I can see the parent scanning the children and in
> others there will be an event driven reason to look for the CDS set at a
> child.  In some cases "scraping" is optimal, in some cases "explicit" is
> optimal.
>
> The CDS has to do this:
>
> 1. Let the parent know whether it is a request for new DS records or whether
> this is a request to delete DS records.  (Plural referring to the fact that
> a SEP might have more than one DS record.)
>
> 2. Let the parent know when this request was first posted (so that the
> parent can tell if it did this one before).  I.e., a 32 bit timestamp viewed
> as a yyymm-etc. like the RRSIGs do.  Or it could be the serial number of the
> zone when the request was added (although that might be hard for a tool to
> determine).  But - goal is - something to let the parent know when this
> request appeared so that the parent can guess whether it has already
> responded to it.
>
> 3. Let the parent know the RDATA of the DS records that are desired.
>
> What #3 hints at is the case where DS records are requested for a DNSKEY
> that is not (yet) published in the child zone.  There is a DS record in the
> root zone for a ccTLD that points to no existing record - an example that
> this is done.
>
> I'd like to see one CDS per DNSKEY state change.  It is up to the child to
> groom the CDS set, that is, once the parent has granted the request (which
> can be seen by asking the parent) the child has the onus to remove the CDS -
> but as protocol designers we have to account for the case where a child does
> not remove a CDS (ever), and might in fact have a CDS to add a key and
> another to delete the key.
>
> Other considerations.  I left off "urgent" or "due time" because those
> features generally are overkill.  For urgent matters, that falls under the
> "why" category  and not the "how" category.  And "how" is what we need to
> define.
>
> For example, a zone has KSKs with footprints/ids of 11111 and 22222 and is
> flipping to the latter:
>
> zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>
> The hash in the DELETE is over kill.  Perhaps for that just the footprint is
> needed (unless you want to delete one or the other hash only).
>
> Here's a meltdown case that I want to smooth over (with hashes elided):
>
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ...
> zone.tld.   1800  IN  CDS   DELETE 20130301000000 22222 ...
>
> In this case, the child forgot to remove the add request when it decided to
> do the delete.  (No intention of allowing the timestamp to be a schedule -
> even though I show a future date in the example, I did that just for
> convenience.)  The parent should know then to delete what it has for 22222,
> whether or not it ever added the DS.  (E.g., if the two records popped up
> together with the same timestamp.)
>
> PS - looking at the email addresses for the authors: so it is true, Warren
> and George are the same person!
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>