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!
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
