[DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett <[e-mail]>]

My first impression of this document is that it is still in need of some
extreme editing – mostly for grammar and syntax, but also for clarity and
readability.  I've included many of the early problems I found in a list of
nits at the end of this email, but at two and three errors per paragraph
(and occasionally per sentence) it's just too much to cover this way, so I
stopped noting nits after the first couple of sections.  I suggest such
sweeping changes to later sections that any nits I noted there may end up
being rewritten anyway.

The draft still suffers from inconsistent approaches to the content.  In
any given section it might shift from a problem description, to
admonishment, to advice for workarounds, and back again without a clear or
consistent structure.  This makes it difficult to figure out what the
intended takeaway is in places.  I've tried to point out specifics below,
and suggest better approaches where I can.

Don't let my criticism of the document give you the wrong impression.  I
think this is useful work, and I'm very appreciative of the work that has
gone into it so far.  I just happen to think that there is still work left
to be done.


As for the meat of the matter...


In the Introduction, in the paragraph which begins "Unless a nameserver is
under attack" would it make sense to replace "broken delegations" with
"lame delegations"?   We have a term for delegating to a name server which
is not authoritative for the delegation... we should probably use it.


Section 2, "Consequences," seems out of place to me.  It makes a number of
assertions that seem to follow no particular flow, or pattern.  The line of
reasoning or evidence that lead to these assertions has not appeared yet in
the document, and so they seem unsupported.  If I'm interpreting the
author's intent correctly, perhaps this section should be split up and
interspersed into the current section 3 as the direct or indirect
consequences of each type of dropped response.


The way section 3 is titled and introduced I expect to just see a survey of
commonly dropped queries, but the content seems to be inconsistent as to
whether it's just a survey, or a survey and advice to client authors about
working around problems, or just advice without a clear description of the
problem behaviour.  It seems to me that if the section is intended to be
advice to authors, then it should be introduced that way.  Also,
clarification for server authors on how they should respond–instead of
dropping queries–should probably come before any advice on how to work
around dropped queries.

If the goal here is to help implementors fix what's broken, then I would
suggest each subsection start with a clear description of an observed
broken behaviour, followed up with a description of how that behaviour
should change (possibly only as a short summary with external references,
as we don't want to reproduce whole RFCs here) and then follow that with
advice for client authors for working around existing brokenness.  Sticking
to a pattern–either the one I've suggested or some other–for every query
type would make the entire section easier to read.  It will also make it
easier for the working group to go through the section item by item and
discuss whether we agree on the problem descriptions and proposed
remediation.

RFC 2119 language is conspicuously absent from this section and SHOULD be
added.


Section 4, "Remediating", is very problematic.  I think the biggest issues
stem from two false assertions:
1) "TLD operators are being asked to do this as they...have access to a
large numbers of nameserver names as well as contact details for the
registrants of those nameservers."

This is incorrect.  Or, at least, frequently incorrect.  TLD registries
fall into one of two categories: thick or thin.   Thick registries do have
this information, but a significant number of thin registries exist, which
delegate the responsibility for maintaining registrant contact information
to the registrar.  All thin registries know is that a delegation should
exist, which name servers are currently supposed to be authoritative for
the subzone, and which registrar asked them to create the delegation.

This false assertion leads the author down the path of making the TLD
registry responsible for contacting registrants.  The third paragraph
backpedals a bit on the question of who should be doing what, but then the
rest of the section goes on to talk about the registry anyway.

A lot of text could be removed from the first few paragraphs by removing
the need to soften the initial statement that this responsibility lies with
the TLDs.

2) The second false assertion is the implied assertion that RFC 1033 says
anything at all about a zone operator's responsibility to remove
delegations that lead to badly behaving name servers.

To provide context ... the title of RFC 1033 is "DOMAIN ADMINISTRATORS
OPERATIONS GUIDE," and the first sentence of the referenced COMPLAINTS
section is, "these are the suggested steps you should take if you are
having problems that you believe are caused by someone else's name server."
  The specifically referenced step is to "ask the parent authorities to
excommunicate the domain."  None of this is normative language directing a
parent operator to do anything.

RFC 1033 appears to be nothing more than a "how to" guide for new DNS
operators of the late '80s.  Its main goal seems to be to give a
prospective operator an overview of the DNS, and instructions for how to
get a DNS server up and running for the first time.  We shouldn't be
looking to it for standards guidance any more than we should look to an
early (or any) edition of DNS & BIND.

Even if the normative language implied in this draft existed in an RFC
somewhere, it is legally impossible for most TLDs to follow the directions
this draft gives.  Any registry that falls under the "gTLD" category is
contractually prohibited from directly contacting its registrants, and none
of the registries or registrars for gTLDs would have a legal leg to stand
on if they tried to remove a delegation due to a misbehaving name server.
Even if the name server belonged to the registrant of the delegation this
would be problematic, but in many cases the registrant and the DNS operator
are not the same.  Attempting to remove a registrant's delegation because
of the actions of a third party would have any gTLD's legal department up
in arms in an instant.

Removing the above two assertions obviates a lot of the current content of
section 4, and leaves only descriptions of testing that MAY be implemented,
but is already discussed in more detail in section 9.

If this section remains, removal of any suggestion of imperative from it is
essential to this document being viable.


Section 5, "Firewalls," seems to be more of section 3 and should be merged
there.  If the author wanted to separate the misbehaviour of name servers
from the misbehaviour of middle boxes that would be reasonable, but then
this should at least appear immediately after section 3, without some other
subject sitting between them.


Same for section 6.  This just seems to be a special case of the firewall
problem.


And again for section 7.  This definitely belongs in section 3 as just
another case of a misbehaving name server.


The third paragraph of section 8 fails to address recursive servers
handling unknown types.  This may just be an oversight if the intent was to
limit the paragraph to authoritative servers.  If that's the case, the
first sentence of the paragraph should be rephrased.  It's important to set
the reader's expectations for scope as early in the subject as possible.

Section 8 as a whole probably belongs closer in the document to section 3,
as it is entirely advice for implementors.  It could probably be split up
into section 3 in much the same way I suggested with section 2.




Nits:

– Introduction:

"Failure to respond to a query is indistinguishable from a packet loss."
This seems awkward to me.  I'd change it to either "from packet loss" or
"from a lost packet."

In the following sentence, "a analysis of query response patterns will results"
contains two errors.  It should be "an analysis of query response patterns
will result..."

"Servers which fail to respond to queries to remain results in developers
being hesitant to deploy new standards."   I'm not sure what "to remain" is
doing in there.   Should this be: "Servers which fail to respond to queries
result in developers being hesitant to deploy new standards."  ?

– Consequences

"Lack of following the relevant RFCs has lead to various consequences.
Some as a direct result and some from recursive servers try to work around
the non compliance."  This is a sentence fragment; replace that period with
a comma.

"Fixing known issues know"   Fixing known issues now?

"Wide spread non response to EDNS queries has lead to recursive servers
having to assume EDNS may not supported and fallback to plain DNS is
required."  I think that "is" is a typo of "as".  This also reads like
fallback is another thing they must assume.  May I suggest: "Widespread
non-response to EDNS queries leads recursive servers to assume EDNS may not
supported, and fallback to plain DNS as a result."

"3. Common queries kinds that result in non responses" ... "Common kinds of
queries that result in non response"?