Extended DNS Errors

Note: This ballot was opened for revision 14 and is now closed.

Erik Kline Yes

Comment (2020-04-21 for -14)
Some non-mushroom-infection-related thoughts:

[ section 2 ]
* I'm insufficiently fluent in Unicode but is some reference here appropriate?
  Perhaps RFC 5198 (if not 3629)?

* Is some text of the form "EDE text may be null terminated but MUST NOT be
  assumed to be; the length MUST be derived from the OPTION-LENGTH field"
  worth including?

[ section 4.1 ]
? s/a EXTRA-TEXT/an EXTRA-TEXT/ perhaps

[ section 4.5 ]
* should DNS64 servers send "Forged Answer" EDEs with a NOERROR synthesized
  AAAA response?

[ section 4.22 ]
* "Not Supported" because something has been deprecated seems sufficiently
  specific that perhaps "Deprecated" or "No longer supported" would be more

Murray Kucherawy Yes

Comment (2020-04-10 for -14)
Bigger things:

The introduction is great, but the last paragraph drifts into normative language, which feels weird in an introduction.  I suggest moving that stuff off to a later section, even a new one.

Section 1.1 should use the more modern form of BCP 14.

I may need more DNS clue, but I'm wondering why any of the SHOULDs in the first paragraph of Section 3 are not MUSTs, or alternatively why I would ever deviate from what they're saying.

Lesser things:

Section 1:
* "... and so the stub resolvers only ..." -- s/resolvers/resolver's/
* "... is returned again or the next ..." -- add a comma after "again"
* "... described in this document and can be used  ..." -- remove "and"

Section 4.4:
* "... unable to resolve answer within ..." -- "an answer" or "the answer"

Section 4.9:
* "... validation, but but no ..." -- s/but but/but/

Section 4.16:
* "... operator of the server being directly talked to." -- "being directly queried", perhaps?

Section 4.25:
* "An authoritative server that cannot answer ..." -- remove "that", perhaps?

And with that, I'm off to check out Infected Mushroom.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-04-24 for -15)
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

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.

Martin Duke No Objection

Comment (2020-04-23 for -14)

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?


Sec 4.4 s/serever/server

Sec 6: s/validaion/validation

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

Martin Vigoureux No Objection

Robert Wilton No Objection

Comment (2020-04-22 for -14)
No email
send info
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?


Roman Danyliw No Objection

Comment (2020-04-21 for -14)
** 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?

Éric Vyncke (was Discuss) No Objection

Comment (2020-04-24 for -15)
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 ;-)



-- 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).

Warren Kumari Recuse

Comment (2020-04-10 for -14)
No email
send info
'm recusing as I'm an author...

(Barry Leiba; former steering group member) Yes

Yes ( for -14)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-04-23 for -14)
Agree with others that the Acknowledgments section should end with the list of those being acknowledged when this is published as an RFC.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -14)
No email
send info