10:15 p.m.
Willem Toorop <willem at nlnetlabs.nl> wrote
Wed, 6 Apr 2016 15:21:25 -0300:
| > | Yes, I've been chewing on this a little bit, and considering that
| > | canonical order also seems important, perhaps we can come up with some
| > | more generic functions.
| >
| > I've been looking a bit closer at draft-zhang-trans-ct-dnssec-03 and
| > think that I only need the submitted DS record to be canonicalised. So
| > no ordering is necessary and only section 6.2 of RFC4034 needs to be
| > considered in my case.
| >
| > If you don't think there's a good reason for adding the feature of
| > returning canonicalised records in getdns, I could probably handle this
| > myself.
|
| Linus,
|
| After a meeting a few minutes ago about
| draft-shore-tls-dnssec-chain-extension-02, I realize I need to have
| those functions for our draft anyway. So they will be added.
Interesting. Glad to see a followup on agl's thing that you mentioned in
Yokohama. Seems useful.
| I will also consider returning the validation chain already
| canonicalized and sorted as a future improvement. Currently this is not
| the optimal path; the chain is extracted from the actual replies and not
| the verification buffers. Plus, you need the separate functions to
| canonicalize the answer anyway. But it might be a good future optimization.
OK.
| > If so, can this list explain if point 5 in RFC4034 section 6.2 is
| > applicable to this case, a DS record? I don't really understand it.
| >
| > 5. the RR's TTL is set to its original value as it appears in the
| > originating authoritative zone or the Original TTL field of the
| > covering RRSIG RR.
|
| When you lookup the DS at a recursive resolver, the TTL will be the time
| it has left in the recursive's cache and not the TTL that the DS had at
| the authoritative server. That TTL is in the "Original TTL" rdata field
| of the RRSIG associated with the DS. It would make sense for DNSSEC
| transparency log to store the "Original TTL" with the DS yes.
I see. Good info.
Since I require, even if the dnssec trans draft does not, that the
client includes the RRSIG for the DS in the submission (avoiding the log
to add pieces of information from its own view of the DNS tree) I guess
it doesn't seem crazy to "rewrite" the DS like this before checking for
a duplicate. (If there's already an entry in the log matching the
submitted record, we don't want to store the record again.)
Any thoughts on pros and cons?