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 protected]] On Behalf Of
[email protected]
Sent: Saturday, November 28, 2015 7:52 AM
To: [email protected]
Cc: [email protected]
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-00.txt
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/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
