Extended DNS Errors
draft-ietf-dnsop-extended-error-16

** Thanks for responding to the SECDIR review (and thanks Catherine Meadows for the review).  I recommend applying the proposed text (suggested by Wes) to the Security Considerations that resulted from the discussion.  For me, it strikes a balance.

** Section 4.5.  Code = 4 (Forged answer) rolls up into a single code a number of rationales as to why the answer was forged (e.g., legal vs. malware).  However, when the request is blocked via blacklist, separate codes are not defined to convey the rationale.  Why isn’t there symmetry?   

** Section 6.  Per the example of [RFC2845] and [RFC8094] as being approaches where DNS answer could be authenticated, consider adding RFC8484 to the list too.

** Editorial Nits:
-- Section 1.  Typo. s/These extended  DNS error codes described in this document and can be used … /These extended DNS error codes described in this document can be used …/

-- Section 2.  Typo. s/ The INFO-CODE serves as an index into the "Extended DNS  Errors" registry Section 5.1./ The INFO-CODE serves as an index into the "Extended DNS Errors" registry defined in Section 5.1./

-- Section 4.  s/… in the "Extended DNS Errors" registry Section 5.1 ./ … in the "Extended DNS Errors" registry defined in Section 5.1 ./

-- Section 4.9. s/but but/but/

-- Section 4.4. Typo. s/serever/server/

-- Section 7.  “One author also wants to thank the band …”, is this really needed in an archival document?

Thank you for addressing my trivial DISCUSS. I have kept the rest of my COMMENTs for archiving purpose.

--- for archiving ---

Please find below some non-blocking COMMENTs. An answer will be appreciated.

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

== COMMENTS ==
-- Section 2 --
For my own curiosity, why is there no added semantic in the INFO-CODE ? Such as a bit or a range for transient errors vs. permanent errors.

It is also a little unclear whether the EDE can happen multiple times (or is it implicit for EDNS0 option?)

-- Section 4.5 --
The "forged answer" is not qualified in the name but well in the definition examples. Suggest to rename it in "forged answer by policy" and also create another code for "forged answer for technical reason" (e.g., DNS64).

We could also wonder whether this code is an "error" code or a "warning" code. If the latter, then the "EDE" acronym does not really apply anymore (but this is cosmetic).

Agree with others that the Acknowledgments section should end with the list of those being acknowledged when this is published as an RFC.

Thank you for addressing my Discuss point!
It's probably worth a second look at the IANA considerations (see below),
and I do have a few other comments.

Section 1

Were you going to say something about EDE allowing stubs to stop after
SERVFAIL-due-to-DNSSEC-bogus instead of continuing on to a non-validating
resolver?

Section 2

(I note that BCP 18 likes a language indicator, and "intended for human consumption"
relies on humans to be language detectors, which is not always reliable.)

Section 3

   the truncation bit when dropping EDE options.  Because long EXTRA-
   TEXT fields may trigger truncation, which is undesirable given the
   supplemental nature of EDE.  Implementers and operators creating EDE
   options SHOULD avoid lengthy EXTRA-TEXT contents.

I think this was intended to be one sentence, not two?

Section 5.2

Are these two snippets consistent with each other?

   o  0 - 49151: First come, first served.
   o  49152 - 65280: Private use.
[...]
   INFO-CODE:  25-65535
   Purpose:  Unasigned
   Reference:  Section 5.2

Section 6

   unauthenticated information.  As such, EDE content should be treated
   only as diagnostic information and MUST NOT alter DNS protocol
   processing.  Until all DNS answers are authenticated via DNSSEC or

This looks an awful lot like the text Eric Orth didn't like when proposed
in the secdir review thread.

Comments:

I know that in some crypto use cases, error codes are deliberately kept vague to frustrate analysis by attackers. Have the DNSSEC error codes been vetted for the same risk? Or does that not apply here?

Sec 5.2: since the shepherd write up, the maximum 16-bit integer has dropped to 65280. Have these code points gone somewhere?

Nits:

Sec 4.4 s/serever/server

Sec 6: s/validaion/validation

The redundant word in “This information is unauthenticated information” is redundant.

Thank you for this document.  I found it straight forward and easy to read.

However, I was left wondering how DNS clients are expected to process any received errors and whether any more guidance should be given either for classes of errors, or perhaps for particular errors.  Or is the recovery action entirely left to the clients discretion?

E.g. is the default action if any of these errors are received to just throw up your hands, and inform the user with a "computer say's no" error, along with the details?  Or in some cases, does it make sense to retry the operation against the same server (perhaps for "Not Ready"), or in other cases does it make sense to try and same operation against another DNS server?

Thanks,
Rob