We have had an off-line discussion with Paul on how to address his comments
and this is the result of that discussion.
New version will show up RSN.
At 13:55 06/08/2008, Paul Hoffman wrote:
Greetings again. Section 3 of this document says:
If any of the steps above result in an error, the validating resolver
SHOULD log them.
...and then what? Continue on merrily as if the priming worked? Just
logging the error seems like undershooting the security of using trust anchors.
Later in that section, it says:
If a validating resolver is unable to retrieve a signed DNSKEY RRSet
corresponding to a trust anchor (i.e., prime the trust anchor), it
SHOULD log this condition as an error. Inability to prime a zone's
trust anchor results in the validating resolver's inability to
validate data from the corresponding zone. The validating resolver
SHOULD treat this zone as bogus.
It is not clear why not being able to get the DNSKEY RRSet is more
serious (and thus worth bogofying the zone) than the validating
steps not working.
The new version of the draft will have an explicit pointer to
RFC4035 saying that TA processing errors should be treated the
same way as DS processing errors.
Further, the last sentence has a "SHOULD" but doesn't say under what
circumstances that a resolver can ignore the "SHOULD". Why isn't this a "MUST"?
You are right the new version says "MUST"
thanks for your comments.
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
