[DNSOP] (no subject)

[Wes Hardaker <[e-mail]>]

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