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

[Olafur Gudmundsson <[e-mail]>]

Ed,

Thank you for your review from the "parent perspective".

CDS is designed to be as simple as possible to operate for both parents 
and child.
CDS is designed around the "Replace" operation, you and Marc are
proposing to change that to Add/Delete operations.

In the draft a Parental Agent can simply sort and compare
	the RDATA of CD to the RDATA of CDS
if there is a difference it can either
	- figure out the diff and translate that to ADD/DELETE actions
	- or simply say "Delete <foo> DS *; Add <foo> DS ...."

Yes I can envision a tool that looks a the "proposed DS" in a file at
child compares to current DS and creates "CDS action records"
as you propose and then takes these actions out after the parent
reflects the update.

It think this discussion broils where does the complexity lives and if
the different choices make life significantly simpler for one party or
the other.

I'm not sure that the ADD/DELETE model is simpler for the parent as in
both cases the Parental Agent needs to check some "back end" as when it
last performed an action for the Child and or if the action is redundant.

Thus before we go into discussion into details of record formats, lets
have the REPLACE vs ADD/DELETE discussion.

	Olafur

On 28/02/2013 01:56, Edward Lewis 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!
>