1:22 p.m.
Op 14-04-16 om 11:20 schreef Linus Nordberg:
Hi,
The draft is not precise on the question of what comprises an entry with
regards to duplicates. Here are my thoughts about this today:
- Duplicate checks are important to get right to avoid the log being
spammed to death.
- Should we perform duplicate checks on the key only, i.e. DS RDATA?
That's what we're interested in detecting misisuance of after
all. Well, owner name has to be included too. Type and class are
fixed, leaving us with TTL. Since canonicalisation of the DS record
sets its TTL to the Original TTL Field of the covering RRSIG, TTL
might be stable enough to be included in duplicate checks.
- How stable is the chain? Should it be included in duplicate checks,
canonicalisation assumed? No, RRSIG's expire and get replaced and are
not stable.
Also, there might be multiple RRSIGs that provide multiple different
ways to validate the DS.
If the DNSKEY RRset (+ RRSIGs) associated with a DS RRset would also be
stored with the DS, then it should be possible to construct a chain of
trust at a specific time from the log.
Is the absence of a DS also stored in the log? I.e. the NSEC(3) proof?
- If chains are not included in duplicate checks, is
there any point in
storing a canonicalised version of the chain? Are there any downsides?
I note that if canonicalisation would mean sorting the RR's, we'll end
up storing the RR's in a different order than what the client use when
submitting. That might be a bit unintuitive, for implementors of
monitors at least. But perhaps canonicalisation shouldn't sort like
that? Sorting _within_ an RR set is different from sorting all the
RR's in the chain, I suppose.
Thoughts?
_______________________________________________
DNSSEC-Transparency mailing list
DNSSEC-Transparency at lists.sunet.se
https://lists.sunet.se/listinfo/dnssec-transparency