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

From: [email-masked]
Date: Fri, 03 Mar 2017 01:23:20 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : A Common Operational Problem in DNS Servers - Failure To Respond.
        Author          : M. Andrews
	Filename        : draft-ietf-dnsop-no-response-issue-08.txt
	Pages           : 25
	Date            : 2017-03-03

Abstract:
   The DNS is a query / response protocol.  Failure to respond or to
   respond correctly to queries causes both immediate operational
   problems and long term problems with protocol development.

   This document identifies a number of common kinds of queries to which
   some servers either fail to respond or else respond incorrectly.
   This document also suggests procedures for TLD and other zone
   operators to apply to help reduce / eliminate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Mar 2017 20:57:06 +1100

Added missing EDNS truncation behaviour test.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Tue, 7 Mar 2017 18:40:47 +0100

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