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

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Oct 2016 13:32:51 +1100

In message <[email-masked]>, Matthew Pounsett writes:
>
> 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.

So we have a peer review document, the author of whom worked for
the company that managed the COM and ARPA zones and others, saying
as the step of last resort "request excommunication" and that it
would not happen if it was justified?  I know when I got delegations
back around '88 that excommuniction for failure to maintain a standards
compliant server was a real possibility.  Unfortunately the email
that said this is long gone.

> 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.

Actually it has a lot more relevence that DNS & BIND as it was
written by those that were in control at the time.  You will note
that the author was from SRI and SRI would act on excommunication
requests if they felt they were justified.

> 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.

But not all registries as so constrained.  This is BEST current
practice not LOWEST COMMON DEMONINATOR practice.

GTLD are required to remove records for abuse so removal of record
is expected for some conditions so it is not beyond belief that
they can change to include these reasons.  ICANN still has a committee
to maintain the stability of the DNS.  Nameserver behavior very
much affects that stability.

> 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"?
>

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

---

From: william manning <[email-masked]>
Date: Mon, 10 Oct 2016 05:44:02 -0700

Unfortunately we are no longer in the early days of the Internet AND the
IETF has no business in enforcing compliance with our protocol standards.
That's for the zone operators to do.  We are not the dns police.  Even Paul
mocapetris has called for more innovation in the dns space.   We must not
presume there is just one way to do things.

On Sunday, 9 October 2016, Mark Andrews <[email-masked]> wrote:

>
> In message <
> [email-masked]
> <javascript:;>>, Matthew Pounsett writes:
> >
> <javascript:;>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Oct 2016 01:56:42 +1100

In message <CACfw2hiV9+qQ_OysHAQ4jd4fJtN2a=[email-masked]>
> presume there is just one way to do things.

If the IETF was setting servers that went and checked DNS servers
and informed the operators then the IETF would be in the business
of enforcing protocols.  At this stage I don't see the IETF doing
that nor is this document asking the IETF to do that.

The is a difference between innovation and not exercising care /
lazyness.

Returing FORMERR because you see a EDNS flag you don't understand
is not innovation.

Returing FORMERR because you see a EDNS option you don't understand
is not innovation.

Returing FORMERR because you see a EDNS version you don't understand
is not innovation.

If there was anything innovative in what I'm seeing I'd be all for
it but there isn't.

Mark

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 10 Oct 2016 17:33:19 +0000

> If there was anything innovative in what I'm seeing I'd be all for

Amen.  This draft documents widely problematic behaviour that is
seen much too often.  It is good to have it all written down in
one place.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 16 Oct 2016 10:06:17 -0500

> seen much too often.  It is good to have it all written down in

I agree.  It is very useful in that respect.

The specific issue we're discussing here is whether the draft can/should
require certain actions from DNS operators based on the behaviour of child
zones.

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 16 Oct 2016 10:17:32 -0500

On 9 October 2016 at 21:32, Mark Andrews <[email-masked]> wrote:

>
> In message <CAAiTEH9Rbw4u3gV9GULQ-8WdoPHf3SXQMTRY+CtfUGrNQSGAWw@
> mail.gmail.com>, Matthew Pounsett writes:
> >

Who the author was doesn't change what they wrote.

> requests if they felt they were justified.

SRIs policy in the 80's doesn't have any bearing what is written in 1033.
Nor do their policies in the 80's have any bearing on the world as it
exists today.

> much affects that stability.

The draft can say it would be helpful to take action.  The draft can't
require action.  Requiring action isn't describing a best current
practice.  That just won't fly on today's Internet.

If you want to lobby ICANN to modify the gTLD agreements, then we can
revisit this discussion.  But until those are changed the IETF has no
business insisting on contractually prohibited actions.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Oct 2016 13:15:26 +1100

In message <CAAiTEH_Tn8YXXe9wYMgobeg0Fd3OdY9M4Rey6QQxh0Yg=[email-masked]>
> practice.  That just won't fly on today's Internet.

I've had TLD's saying they want the hard line to be there as it
backs up their stance.

> business insisting on contractually prohibited actions.

The IETF can say what is BEST practice.  If gTLD's feel they cannot
meet BEST practice they will not do that.  No one can make someone
follow BEST practice.

Every time I hear "But the gTLD's can't do" I see a conflict of
interest showing.

The IETF can recommend things that gTLD's can't do today.  There
is nothing wrong with doing that.  It puts the IETF's position not
gTLD operator position.

Mark

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 18 Oct 2016 14:00:20 -0500

> is nothing wrong with doing that.  It puts the IETF's position not

The problem with the draft is that it doesn't recommend -- it requires.
1) It incorrectly references a non-normative RFC as if it were normative.
2)  It includes imperative statements while claiming to be a description of
best practice.

Neither of these things are supported by your argument.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 19 Oct 2016 16:19:58 -0400

Hi,

Adding a few comments on this discussion, just one chair’s opinion:

The underlying question in this exchange seems to be what advice should this document offer, and to whom?

This is a Working Group document, which means the decision about what’s in and what’s out doesn’t rest with any individual; it belongs to the WG. 

The bulk of the document is a description of certain issues that can arise in name server operation, and tests that can be performed to identify servers that behave incorrectly or suboptimally with respect to those issues. I’m seeing several suggestions that those portions of the document might benefit from some editorial work, but not seeing opposition to publishing them.

At the same time, there’s a question of what sound, credible advice this group can include in the document. A couple of thoughts on that:

	1. I don’t think that citing advice to operators in RFC 1033 as normative is helpful. Retaining any advice found there should be clearly justified in terms of current understanding of both protocol and practice. Besides the changes in how we use language in standards (RFC 2119) since RFC 1033 was written, it’s really hard to argue for the assumption that *anything* about the way we operate the TCP/IP internet hasn’t changed as it’s grown, or that *any* advice to operators of the 1980s is automatically relevant to operators today.
	2. In this particular case, the suggested “Remediation” includes advice that isn’t actionable for many TLD operators, because they’re operationally and contractually constrained from the recommended action. It may also be passing up an opportunity to provide advice to others who do have leverage over name server operators that TLD operators don’t— including registrars and registrants.

The chairs have asked those who have objections to the current “Remediation” section to “send text” and look forward to review by the WG. We need more comment/feedback on what advice, if any, should be given in this document.

thanks,
Suzanne
(for the chairs)

> On Oct 18, 2016, at 3:00 PM, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> 
> On 16 October 2016 at 21:15, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> 
> In message <CAAiTEH_Tn8YXXe9wYMgobeg0Fd3OdY9M4Rey6QQxh0Yg=[email-masked] <mailto:[email-masked]>>
> 2)  It includes imperative statements while claiming to be a description of best practice.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 27 Oct 2016 18:10:13 -0400

Following Suzanne's request to send text, I've put together a first draft
of what I think the Remediating (renamed to Remediation) section should
look like.  In addition to this rewrite, I'd recommend moving it to be
directly after the Testing section.

# Remediation

Name server operators are generally expected to test their own
infrastructure
for compliance to standards. The above tests should be run when new systems
are brought online, and should be repeated periodically to ensure continued
interoperability.

Domain registrants who do not maintain their own DNS infrastructure are
entitled to a DNS service that conforms to standards and interoperates well.
Registrants who become aware that their DNS operator does not have a well
maintained or compliant infrastructure should insist that their service
provider correct issues, and switch providers if they do not.

In the event that an operator experiences problems due to the behaviour of
name servers outside their control, the above tests will help in narrowing
down the precise issue(s) which can then be reported to the relevant party.

If contact information for the operator of a misbehaving name server is not
already known, the following methods of communication could be considered:

- the RNAME of the zone authoritative for the name of the misbehaving server
- the RNAME of zones for which the offending server is authoritative
- administrative or technical contacts listed in the registration
information
  for the parent domain of the name of the misbehaving server, or for zones
  for which the name server is authoritative
- the registrar or registry for such zones
- DNS-specific operational fora (e.g. mailing lists)

Operators of parent zones may wish to regularly test the authoritative name
servers of their child zones.  However, parent operators can have widely
varying capabilities in terms of notification or remediation depending on
whether they have a direct relationship with the child operator.  Many TLD
registries, for example, cannot directly contact their registrants and may
instead need to communicate through the relevant registrar.  In such cases
it
may be most efficient for registrars to take on the responsibility for
testing
the name servers of their registrants, since they have a direct
relationship.

When notification is not effective at correcting problems with a misbehaving
name server, parent operators can choose to remove NS records that refer to
the faulty server.  This should only be done as a last resort and with due
consideration, as removal of a delegation can have unanticipated side
effects.
For example, other parts of the DNS tree may depend on names below the
removed
zone cut, and the parent operator may find themselves responsible for
causing
new DNS failures to occur.