Currently there are four timing parameters:
1) TTL suggestion 2) vInterval (signing frequency parameter 3) startDate 4) endDate
If these dates are not honored, the current situation treats this as a warning.
Here is what we think it ought to become...
1) TTL limit 2) Validity span limit
Treating failure of the server to accommodate these as hard failures.
The rationale is
- The DS RRSet is authoritative only from the parent, making it unlike the NS RRSet or glue records. I.e., there is a reason that the child gets to "feedback" to the parent in this case.
- The lack of explicit revocation in DNSSEC means that the parent has a responsibility to limit the length of the RRSIG validity period at the request/demand of the child. (The parent has the right not to serve the child too.)
- The treatment of a failure to accommodate the request as a hard failure is based upon the thought behind this example:
1) Client says "here's my DS, sign it for just a week at a time" 2) Servers says "okay, but warning, I signed it for 2 years."
There's no undoing the publication of a record, you can pull it, but someone out there can copy it first and use it in replays. Akin to "privacy", it's hard to rescind information once it goes out, so we now think we want to play it conservatively.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar
Achieving total enlightenment has taught me that ignorance is bliss. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
