Viktor Dukhovni <ietf-d...@dukhovni.org> writes: Thanks Viktor,
Thanks for the comments. Responses are inline below in my tracking notes below. 14.1 DONE Viktor Dukhovni ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14.1.1 DONE Introduction 3rd paragraph (missing verb, extra period): -------------------------------------------------------------------- [...] These extended DNS error codes [are?] described in this document and can be used by any system that sends DNS queries and receives a response containing an EDE option.. [...] 14.1.2 DONE With respect to the much discussed caveat: ------------------------------------------------------ This document does not allow or prohibit any particular extended error codes and information be matched with any particular RCODEs. Some combinations of extended error codes and RCODEs may seem nonsensical (such as resolver-specific extended error codes in responses from authoritative servers), so systems interpreting the extended error codes MUST NOT assume that a combination will make sense. Receivers MUST be able to accept EDE codes and EXTRA-TEXT in all messages, including even those with a NOERROR RCODE. My take is that when the (12 bit EDNS) RCODE and new extended error are in apparent conflict, I should treat the RCODE as definitive, and ignore the extended error code. That is, the extended error can *refine* but not contradict the status indicated by the RCODE. If that's correct, perhaps it should be stated explicitly. If not correct, then a clarification is perhaps still in order. + Response: there seems to be consensus around this and I adopted Paul's text to clarify this 14.1.3 DONE Section 2, 3rd bullet: s/index to/index into/ ---------------------------------------------------------- The INFO-CODE serves as an index to the "Extended DNS Errors" registry Section 4.1. 14.1.4 DONE Section 2, 4th bullet: s/be take/be taken/ ------------------------------------------------------ Care should be take not to leak private information that an observer would not otherwise have access to, such as account numbers. 14.1.5 NOCHANGE account numbers and privacy ------------------------------------------- I find "such as account numbers" a bit of a non sequitur (what account numbers?) I'd drop this, or produce a more transparent example. + Response: I agree, it's a bit of an unusual statement. But it was suggested by Shane Kerr in the summer and if you want to suggest better text for replacing it, I need a real suggestion as deleting it would delete his desire to have an example in there (which I agree with, FWIW). Maybe "account name" would be a middle ground? 14.1.6 DONE Section 3.2 (code 2), may warrant more guidance on when this is --------------------------------------------------------------------------- appropriate. AFAIK, there is nothing wrong with all DNSKEY algorithms being unsupported, provided the same holds for the DS RRset. So, while I see a use-case for code 3 (all DS unsupported, perhaps to signal why the AD bit is not set, despite the non-empty DS RRset), I don't understand when one would use code 2. + Vladimír Čunát adds I do fail to understand the split codes 1 and 2 for all DS/DNSKEY algorithms being unsupported, and it actually makes me wonder how to exactly write the resolver code that would set this pair. For validation I need at least one usable DS RR, i.e. one where *both* the DS and DNSKEY algorithms are supported. I believe that's the exact condition to be able to extend the trust chain. (and that's how I implemented it for Knot Resolver) It may theoretically even happen that there is a supported DS algorithm and a supported DNSKEY algorithm but never paired together in the DS RRset - IIRC it's not perfectly correct to generate such an RRset but that's probably not something a validator should care for. + Response: Error 1 (unsupported DNSKEY alg) could be included in any message where the DNSKEY algorithm (say 1 RSA/MD5) isn't supported. A servfail would be returned with EDE-1 as well. For DS unsupported, a similar case occurs when chaining from the parent and a DS Digest Type of 1 (MD5) is hit that the validator doesn't support. I *think* the problem is that the text should really say "Unsupported DS Digest Type", which I'll go change it to. Let me know if that's wrong. 14.1.7 DONE Section 3.6, code 6 (indeterminate answer) needs clarification, --------------------------------------------------------------------------- since there is no single defintion of "indeterminate" in DNSSEC. In particular different definitions are given in RFCs 4034 and 4035 (as explained in [https://tools.ietf.org/html/rfc7672#section-2.1.1]). My take is that with the root zone signed, the 4033 definition is obsolete, and the correct one is 4035. This should probably be made explicit: 4035 "indeterminate": An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. 4033 "indeterminate": There is no trust anchor that would indicate that a specific portion of the tree is secure. + Response: good point. I'll use a reference to 4035. 14.1.8 DONE Section 3.8, the text reads: ---------------------------------------- The resolver attempted to perform DNSSEC validation, but a signature in the validation chain was expired. However, there are recent observations of domain where each RRset was accompanied by both expired *and* unexpired RRSIGs. [https://twitter.com/VDukhovni/status/1171170411712827393] So just *an* expired signature is not really a problem provided another signature for the same RRset is not expired. So I think the text could more clearly read "but *all* signatures for an RRset in the validation chain expired", or some such. + Response: good point, changed + Vladimír Čunát adds Nitpick: *if* we were diving into such details... each RRSIG might fail for a different reason, for example. That's the general problem with providing reasons for validation failures: validation is defined in the sense that you (may) succeed when at least one of various ways succeeds. A failure could typically be fixed by multiple different ways (EDE codes). Still, I'd hope that in most real-life cases the implementations can "correctly" guess what's wrong. + Response: That's true, and I think if you had sigs that were both "early" and "late" but not "now" you'd return both codes or more likely an "other" error code (0) with informational text. 14.1.9 NOCHANGE Section 3.13: the text reads: --------------------------------------------- The resolver attempted to perform DNSSEC validation, but the requested data was missing and a covering NSEC or NSEC3 was not provided. I think that "missing" can be misleading, it is not that the answer is "missing" from the response, but rather that the response affirmatively denies the existence of the requested RRset. So perhaps "but the response denies the existence of the requested RRset" or something similar. + I think you're misreading that section (or I'm not following). The point is that the validator *failed* to get a NSEC or NSEC3 that proved the name doesn't exist to match the NXDOMAIN. So the validator changed all the way down through keys and then got an NXDOMAIN with no NSEC for 'wwww'. 14.1.10 DONE I find the two sections: ------------------------------------- 3.16. Extended DNS Error Code 15 - Blocked 3.17. Extended DNS Error Code 16 - Censored somewhat confusing, it seems that the resolver returning the answer is reporting second-hand status from an upstream server, but the language leaves me unsure. Perhaps this can be stated more clearly. + Response: Those three codes were supplied in a previous comment round and they are supposed to indicate policies being applied from different sources. Can you check the new text of them to see if they are more understandable now? -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop