Thanks for your feedback about the extended errors draft. Below are
responses to some of your previously raised points in email to dnsop:
8.1 Puneet Sood
~~~~~~~~~~~~~~~
My comments on the latest version.
General: Thanks for writing this - it provides useful information for
our public DNS resolver implementation.
8.1.1 NOCHANGE > Section 1. Introduction and background
-------------------------------------------------------
> Para 4. "Authoritative servers MAY parse and use them ..." Comment:
Why talk about auth servers parsing this since this field is only
meant to be present in responses?
+ Response: because we are trying to specify what an authoritative
server *should* do when it receives one, even if it doesn't expect
them. IE, the DNS protocol doesn't prohibit clients from sending
them so we should at least mention that servers should be prepared
to receive them (even if useless).
8.1.2 DONE > Section 3.1 The R (retry) flag
-------------------------------------------
> Para 2. "implementations may receive EDE codes that it does not
> understand. The R flag allows implementations to make a decision
> as to what to do if it receives a response with an unknown code -
> retry or drop the query."
Comment: It is unclear what should be done if a response contains
multiple EDE options and the R flag value is different across them.
+ Response: good question. Due to popular request, the R bit has now
been dropped so this issue goes away.
8.1.3 NOCHANGE multiple EDE vs single
-------------------------------------
Comment: On a related note, what is the reasoning for allowing
multiple instance of the EDE option in a response versus encoding all
the (Response-CODE, INFO-CODE, EXTRA-TEXT) tuples in a single EDE
option? A single EDE option would avoid having different values for
the R flag and any new flag in the future. 16-bit length field means
that total size of all EDE options should fit in a single option.
+ Response: Implementations already need to parse multiple extra EDE
options (to avoid crashing, over-writing, etc). And the parsing
structure is significantly easier if they can take the option
record, pull off the 16 bit option and take the rest as text. If we
added a length record for both the number of options and the number
of text fields (of different lengths), this seems more complex to us
than adding multiple options instead. Feel free to try to convince
us otherwise, or better get all the implementations to prefer it.
8.1.4 DONE > Section 4.1.3 and 4.1.3.1 NOERROR Extended DNS Error Code 3 -
Stale Answer
---------------------------------------------------------------------------------------
Comment: 4.1.3.1 should be 4.1.3?
+ Response: I (Wes) just rewrote that section and ensured everything
is consistent. Thanks for the catch though.
8.1.5 NOCHANGE DNSSEC bit
-------------------------
> Section 4.2 INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2)
Comment: There are a number of INFO-CODEs here for DNSSEC failures.
Over time it will be extra work for implementations to stay up to date
with new INFO-CODEs added for DNSSEC failures. The R bit signals
whether a resolution should be retried. Do we want also want a bit for
signalling DNSSEC validation failures? Only needed if some DNSSEC
related behavior needs to be different from the R bit value.
+ Response: 1) we've now removed the R bit, and 2) interesting idea...
It seems premature without a worked example/need. Do you have an
exact use case where this would prove beneficial.
8.1.6 NOCHANGE dnssec protection opts
-------------------------------------
> Section 6. Security Considerations Para 2: "but until we live in an
> era where all DNS answers are authenticated via DNSSEC or other
> mechanisms, there are some tradeoffs." Comment: Not clear how
> DNSSEC would help here since the OPT RR is not protected by any
> DNSSEC mechanism.
+ Response: Yes, that's true. But the sentence is talking
generically, and refers to "other mechanisms" too... DNSSEC won't
help with opt codes, you're right. But I don't think that was the
point of the sentence. If you have specific text you'd like to
propose, I'd love to see it!
8.1.7 NOCHANGE > Appendix A.
--------------------------
Editorial: Missing diff summaries for new versions.
+ Response: very true. Sigh. I'm (Wes) horrible at remembering to
write those, and I never put them in my drafts in the first place.
With the advent of online diffs I don't find them as useful either.
Since we're nearing last call (again), I'll likely not try to go
back and retrofit them.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
