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

From: [email-masked]
Date: Sat, 28 Nov 2015 04:51:43 -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 Working Group of the IETF.

        Title           : A Common Operational Problem in DNS Servers - Failure To Respond.
        Author          : M. Andrews
	Filename        : draft-ietf-dnsop-no-response-issue-00.txt
	Pages           : 16
	Date            : 2015-11-28

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 classes of queries to
   which some servers either fail to respond or else respond
   incorrectly.  This document also suggests procedures for TLD and
   other similar 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-00

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: "Darcy Kevin (FCA)" <[email-masked]>
Date: Tue, 1 Dec 2015 00:01:39 +0000

I'm still reading through this draft, but a few things jumped out at me right away. Some of them are typos, others merely "style" issues, one is a jargon/definitional issue, and then one observation that goes somewhat deeper.

TYPOS: Intro: "not a necessarily" should be simply "not necessarily". Section 6: "proceeded" should be "preceded".

STYLE ISSUES: a) The use of the second-person "you" throughout the document. It's a little familiar, and could be interpreted as a slightly condescending/overbearing. General RFC "style" seems to use the passive voice (e.g. "If EDNS is supported" instead of "If you support EDNS"), use "implementations" as the subject, or use the more formal "one", as in "receiving queries for zones that one is not configured to serve". b) the term "broken" is somewhat overused, and in one case in particular -- "Testing is broken... ", at the very beginning of Section 8, can momentarily lead an unwary reader into a false train of thought. I suggest "Testing methodology is divided" (or "categorized") as substitute language to lead off that section.

JARGON/DEFINITIONAL: I must admit never having heard/read the term "Whole Answer Cache" before, and I'm still unclear what this term denotes. A quick Google search of the singular term yields nothing DNS-related; of the plural term, all references point to this I-D. So what is a "Whole Answer Cache"? What does it do? Can an example of a product, package or implementation be cited? Or am I missing the reference here, and "Whole Answer Cache" is just a new name for something old and familiar?

CONTENT ISSUE: There are several conclusory statements in Sections 4 and 5 about what DNS anomalies are or are not "an attack", or an "attack vector". Is there clear consensus on all of these? Even if they are not attacks _per_se_, could they be components of a more complex, multi-pronged attack, or, at the very least, if the codepaths which handle these anomalies are not optimized sufficiently, could they not be used to perpetrate a DoS? I'd be fine if someone with more InfoSec chops than I would review all of these scenarios and confirm that they are all benign. But, failing that, and failing clear consensus, I think at least a mention should be made in Security Considerations that some of the anomalous behavior described _could_ be used to perpetrate attacks, and thus might call for reasonable countermeasures as such attacks are discovered/revealed. A flat declaration that something is or is not an attack, could come back to haunt the declarer...

													- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, November 28, 2015 7:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-00.txt

Abstract:

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.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop