Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-08.txt

[Petr Špaček <[e-mail]>]

Hello,

version 08 is the first one I reviewed so this should be viewed as
first-time-reader's point of view.

Let me express my support for this work before we dive into deficiencies
of version 08:
I support moving this forward because I believe that this document has
potential to serve as an excellent checklist for diligent DNS
implementors and important reference usable by users to bash .

To serve this purpose, it first needs to be extensively rewritten to
improve readability and structure of the document.

Besides other things, the text needs clarification what parts are
applicable to resolvers and what is specific for authoritative servers.
If I had to guess, section 3.1.5.  Recursive Queries suggests that this
is about authoritative servers but term "non-recursive server" is not
defined in DNS Terminology [RFC7719].

Further, the text in section 3 is missing regular structure and thus is
hard to follow. I think that many Ondrej's suggestions from 20 September
2016 are very good and would improve the draft *a lot*. Please see:
https://mailarchive.ietf.org/arch/msg/dnsop/bpE9T0olLrtQqvdt7qsbMFFRXvY

Some of these suggestions overlap with suggestions in
https://mailarchive.ietf.org/arch/msg/dnsop/z5OqfuJIgwssxsqCqDOFnazIgME
and I agree with them as well. Please incorporate this feedback, it will
IMHO improve the document *a lot*.



I will add couple more suggestions to what was said already:

Section 6.  Whole Answer Caches deserves an additional note that this
section is a warning for DNS implementers. The name got me thinking what
software is an implementation of "Whole Answer Cache" before I realized
that it is (I guess) just note about one possible trap while
implementing DNS .

My attempt to find whether this was discussed already returned e-mail:
https://mailarchive.ietf.org/arch/msg/dnsop/_uO-eIImbFysAD_-UcDFbdh4zlw
Apparently I'm not the only one who got confused by current text. Please
clarify the text. Proposal:
   Some of mentioned problems may be caused by DNS implementations
   caching whole answers, just updating the query id field and possibly
   the qname to match the incoming query to avoid constructing each
   response individually.

   This is not a good idea because whole answer caches can return ...
[the original text from paragraph 2 on continues here]



Section 7.  Response Code Selection confused me when I encountered
following paragraph:
   Unimplemented type codes, Name Error (NXDOMAIN) and NOERROR (no data)
   are the expected response codes.  A server is not supposed to serve a
   zone which contains unsupported types ([RFC1034]) so the only thing
   left is return if the QNAME exists or not.  NOTIMP and REFUSED are
   not useful responses as they force the clients to try the other
   authoritative servers for a zone looking for a server which will
   answer the query.
It took me a while to find out that *previous* paragraph starts with
"For unimplemented opcodes". Judging from this I guess that the
paragraph in question should start with "For unimplemented type codes".
Or even better, "for unimplemented query type codes".

Still, following sentence seems torn out of context:
  "A server is not supposed to serve a
   zone which contains unsupported types ([RFC1034])"
What part of RFC 1034 is referenced in here? I'm clearly missing
something and it seems that I'm not the only one:
https://mailarchive.ietf.org/arch/msg/dnsop/UmTnGzmjijKY4mGuwfuxor6WvoY
Judging from repeated confusion, this part of text needs clarification.


Nits

Typo:
  Requests with unknown EDNS options is expected client behaviour and
  should not be construed as an attack.  The correct behaviour for
  unknown EDNS options is to ignore *there* presence when constructing a
  reply.

Subsection 8.3.  When EDNS Is Not Supported would be more logically
placed as very first or very last sub-subsection of 8.2.  Testing -
Extended DNS.



I hope we can get the document into a good shape and publish it as BCP.
Let me know if there is a repo with source code, I would be happy to
contribute changes so we can move this forward.

-- 
Petr Špaček  @  CZ.NIC