Petr Špaček <[email protected]> writes:
> First, I perceive a "problem" with the current document structure:
> > 2. Recommendation for zone publishers . . . . . . . . . . . . . 3
> > 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3
> > 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4
> > 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4
> > 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> > 3. Recommendations for deploying and validating NSEC3 records . 6
> > 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6
> > 3.2. Recommendation for validating resolvers . . . . . . . . . 7
> > 3.3. Recommendation for Primary / Secondary relationships . . 7
>
> It seems odd to have "2. Recommendation for zone publishers" followed
> by "3.1 Best-practice for zone publishers".
You bring up a good point. When looking at it though, 3.1 really does
look written for zone publishers but actually maybe we should change the
title of 2 is actually what's wrong. How about "NSEC3 parameter value
considerations":
2. NSEC3 parameter value considerations . . . . . . . . . . . . 3
2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Recommendations for deploying and validating NSEC3 records . 5
3.1. Best-practice for zone publishers . . . . . . . . . . . . 6
3.2. Recommendation for validating resolvers . . . . . . . . . 6
3.3. Recommendation for Primary / Secondary relationships . . 7
> Either my understanding of relationship between terms "recommendation"
> vs. "best practice" is wrong, or these should be somehow renamed. Say
> "Background information about NSEC3 parameters" as name of section 2?
>
> Also there is now a SHOULD vs. MUST inconsistency between _content_ of
> sections 2.3. Iterations and section 3.1. Best-practice for zone
> publishers:
Good catch; I took your suggestion about dropping that half-sentence.
> The only other thing worth mentioning is a nit which I don't feel
> strongly about:
>
> > 3.2. Recommendation for validating resolvers
> > Note that a validating resolver MUST still validate the signature
> > over the NSEC3 record to ensure the iteration count was not altered
> > since record publication (see [RFC5155] section 10.3).
>
> Technically RRSIG validation is needed only if the resolver treats
> some combination of parameters as insecure. If it is going to SERVFAIL
> for e.g. large iteration value anyway then there is no point in
> validating the RRSIG, I think.
I think the reason is the error is different (eg EDE). You're right
that the processing may be an overload (but if it is, you can always
just drop it per the other thread too). Anyway, if others support this
change we can discuss it further, but it's been discussed before. So to
the others: please chime in if you agree and we want to revert the
existing consensus based on this new thinking.
> Additionally I've submitted PR#6 with purely editorial nits.
Thank you!
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
