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

From: [email-masked]
Date: Mon, 04 Nov 2019 12:32:05 -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 WG of the IETF.

        Title           : A Common Operational Problem in DNS Servers - Failure To Communicate.
        Authors         : M. Andrews
                          Ray Bellis
	Filename        : draft-ietf-dnsop-no-response-issue-14.txt
	Pages           : 26
	Date            : 2019-11-04

Abstract:
   The DNS is a query / response protocol.  Failing to respond to
   queries, or responding incorrectly, 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 zone operators to apply to
   identify and remediate 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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-14
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-14

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

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: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Nov 2019 21:03:28 -0500

> On Nov 4, 2019, at 3:32 PM, [email-masked] wrote:
> 

Two comments:

-----------

Section 3.1.2 discusses non-response to unexpected qtypes, but there
is a closely related case that I think warrants a mention.  For example,
the nameservers for mail.protection.outlook.com (which don't support
EDNS, returning FORMERR, hence "+noends") mishandle TLSA and other
unexpected queries:

 i. A TLSA (unexpected qtype) query elicits an incorrect "NOTIMP" response:

  $ dig +norecur +noedns -t tlsa _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com. 
  ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 5167
  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;_25._tcp.mail.protection.outlook.com. IN TLSA

 ii. An "A" query for the same qname correctly returns "NXDOMAIN":

  $ dig +norecur +noedns -t a _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com.
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23790
  ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;_25._tcp.mail.protection.outlook.com. IN A

This demonstrates misuse of "NOTIMP" to signal an unknown qtype,
where a simple NODATA or NXDOMAIN suffices. The NOTIMP rcode is only
appropriate for unsupported opcodes as explained in section 3.1.4.
While I got a response, it is a "bad" response, not substantively
better than no response at all.

So I'd like to see text that makes it clear that unexpected qtypes
MUST return the same RCODE as would be returned if the qtype were
some expected value, for which no RRset is present in the zone at
the requested qname.  If the zone is signed, and the EDNS "DO" bit
is set in the request, any (untruncated) NODATA or NXDOMAIN response
MUST of course include the requisite denial of existence proof.

-----------

In section 8.2.3, the correction from:

  OLD: Any unassigned EDNS option code could have be choose for this test.

to

  NEW: Any unassigned EDNS option code could have been choose for this test.

was incomplete, it needed to also s/choose/chosen/, to match an identical
sentence in 8.2.6.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 6 Nov 2019 13:20:54 +1100

Under Response Code Selection we already have:

      <t>
        For unimplemented type codes, and in the absence of other
        errors, the only valid response is NoError if the qname
        exists, and NameError (NXDOMAIN) otherwise.  For Meta-RRs
        NOTIMP may be returned instead.
      </t>

> On 6 Nov 2019, at 13:03, Viktor Dukhovni <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 6 Nov 2019 08:42:24 -0500

I still have a few comments.  There were a few comments from my review of
-13 that weren't responded to in email, and haven't been updated in the
text, so I'm repeating them here.

As mentioned in my last review, Section 3 seems very confused about what
it's trying to accomplish.  Some subsections list only correct behaviour,
some only list incorrect behaviour, while other sections list only a test
for correct behaviour without actually describing either the correct
behaviour or the commonly observed misbehaviour.  These latter sections are
the most confusing, because tests are expected to be in section 8, based on
the current structure of the document.

If the authors wish to keep the description of problem responses separate
from the description of tests, then that should be done throughout the
document, and not just for some tests. If the authors wish to mix testing
and problem description, then that should be done consistently, and section
8 should be removed entirely.  I said in my last review that this isn't an
absolute requirement that should block publication, but while the
information is all there to be found I still think it's better writing (and
therefore an easier document to parse and act on) if sections 3 and 8 are
consistent in their content.

Presuming that the authors wish to keep problem description and test
description separate, then section 3 should be consistent about describing
at least good behaviour for each type of query and leaving off tests.  Bad
behaviour can be assumed to be non-response, based on the subject of the
document, but incidental mention of other common misbehaviours or common
reasons for misconfiguration wouldn't be out of place, I think.

I've done a section-by-section review of 3.x this time, using the
assumption that sections 3 and 8 will remain separate.  For some sections
I'm suggesting specific text to make clear what I think needs to change,
but I think all of those subsections of 3 mentioned below need rewriting.
Without a clear indication from the authors about which way they want the
structure of the document to go, it's hard to commit the time to suggest
rewrites for the entire section.

It would be good to hear back from the authors about whether they think
these issues are non-problems, and why, or whether they intend to address
them in a later version.

3.1.1 - A test description leads ahead of correct behaviour.  This section
doesn't discuss non-response at all.
Suggested text:
If a zone is delegated to a server, that server should respond to an SOA
query for that zone with an SOA record.  Failing to respond at all is
always incorrect, regardless of the configuration of the server.
Responding with anything other than an SOA record in the Answer section
indicates a bad delegation.

3.1.2 - A test description leads ahead of describing incorrect behaviour.
Correct behaviour is never described.  The test should be removed to
section 8, and this should just describe failing to respond to unsupported
QTypes, and what a correct response should look like.  I'm supplying two
suggested text blocks, the latter of which incorporates Viktor Dukhovni's
suggestion about NOTIMP.
Suggested text:
Some servers fail to respond to unknown or unsupported types.  If a server
receives a query for a type that it doesn't recognize, or doesn't
implement, it is expected to return the appropriate response as if it did
recognize the type but did not have any data for that type: either NOERROR,
or NXDOMAIN.
or
Some servers fail to respond to unknown or unsupported types, while others
may respond with an incorrect rcode of NOTIMP.  If a server receives a
query for a type that it doesn't recognize, or doesn't implement, it is
expected to return the appropriate response as if it did recognize the type
but did not have any data for that type: either NOERROR, or NXDOMAIN.

3.1.3 - Good behaviour isn't described.

3.1.5 - The test in the second paragraph should be removed to section 8

3.2.1 - This section leads with a test that should be removed to section
8.  The final paragraph is useful, but expected good behaviour needs to
replace the first two.

3.2.2 - The last sentence of the second paragraph is potentially confusing,
I think.  Is it talking about misbehaviour of authoritative servers, or
misinterpretation by recursive servers of a bad response from authoritative
servers?  I'm pretty sure it's the latter... so, text:
Such answers will [may?] be misinterpreted by the client, and get discarded
or treated as new requests.

3.2.3 - This section does not suffer from the problem described above.
However, I think it could use some re-ordering to make it even clearer what
the correct behaviour is:
Some servers fail to respond to EDNS queries with ENDS options set.  The
original EDNS specification left this behaviour undefined [RFC2671], but
the correct behaviour was clarified in [RFC6891].  Unknown EDNS options are
supposed to be ignored by the server.

3.2.5, second paragraph - It's worth mentioning what the correct response
should be.

3.2.6 - It sounds like the misbehaviour being described is response without
an EDNS option, rather than non-response, but it's not absolutely clear.  I
can read the first sentence either way.  Potential confusion is increased
by the inclusion of the second sentence, which very clearly describes a
response, not non-response.  Response without an EDNS option would be a
variation from the topic of the document (non-response), and so if that's
what the authors are discussing here it should be called out clearly.

Some possible suggestions, depending on the original intent:
Some nameservers only respond to EDNS queries when the DO bit is also set,
and drop queries where EDNS options are present but DO is 0.  EDNS support
is independent of DNSSEC support, and servers that support EDNS should
always respond appropriately to queries with EDNS options set.
Additionally some nameservers fail to copy the DO bit to the response
despite clearly supporting DNSSEC by returning an RRSIG records to EDNS
queries with DO=1.
or
Some nameservers respond correctly to EDNS options when the DO bit is set,
but drop EDNS options from responses when DO is 0.  EDNS support is
independent of DNSSEC support, and servers that support EDNS should always
respond appropriately to queries with EDNS options set.  Additionally some
nameservers fail to copy the DO bit to the response despite clearly
supporting DNSSEC by returning an RRSIG records to EDNS queries with DO=1.

3.2.7 - some words about correct behaviour, or why this behaviour is
incorrect, would be helpful here.

Section 7 -

Last review I recommended some text for paragraph 2 that was neither
accepted nor responded to in email.  I'll repeat the recommendation here in
case it was simply missed:

Section 7, paragraph 2:
>    For unimplemented opcodes NOTIMP is the expected response code.  For
>    example, a new opcode could change the message format by extending
>    the header or changing the structure of the records etc.
> This is not, strictly speaking, an example of what's being talked about in
> the previous sentence.  Suggested text:
>    Newly implemented opcodes may change the message format by extending the
>    header, changing the structure of the records, etc.  Servers are not
>    expected to be able to parse these, and should respond with a response
> code
>    of NOTIMP when they encounter a query with an unknown opcode, rather
> than
>    dropping the message.

Likewise, I don't see any response to my comments about section 8.

Section 8:
> Most of the second paragraphs of the subsections of 8 are written with the
> general structure of:
> We expect A with B and C and D.
> I find this to be awkward list construction.  I think it would be more
> useful to structure these as:
> We expect A, B, C, and D.
> For example, subsection 8.1.2:
>    We expect no records to be returned in the answer section with the
>    rcode set to NOERROR and the AA and QR bits to be set in the
>    response; RA may also be set [RFC1034].  We do not expect an OPT
>    record to be returned [RFC6891].
> This could be:
>    We expect no records to be returned in the answer section, the rcode to
> be
>    set to NOERROR, and the AA or QR bits to be set in the header;  RA may
> also
>    be set [RFC1034]. We do not expect an OPT record to be returned
> [RFC6891].
> I'm happy to provide suggested text for all of these if that's useful to
> the authors.
>
> 8.1.3.1, first paragraph.  Too many "and"s, not enough commas. :)
>  Suggested text:
>    Ask for the SOA record of the configured zone.  This query is made
>    with only the CD DNS flag bit set, all other DNS bits clear, and
>    without EDNS.
> 8.2.3, first paragraph:
>    Any unassigned EDNS option code could have be choose for this test.
>    Any unassigned EDNS option code could have been choosen for this test.
>
>
Nits:

3.2.5, second paragraph:  "Some EDNS aware server...."  should be "Some
EDNS aware servers..."

---

From: Ray Bellis <[email-masked]>
Date: Wed, 6 Nov 2019 14:38:01 +0000

On 06/11/2019 13:42, Matthew Pounsett wrote:
> I still have a few comments.  There were a few comments from my review 
> of -13 that weren't responded to in email, and haven't been updated in 
> the text, so I'm repeating them here.

Hi Matt,

We sought advice from one of the Chairs as to whether in his reading 
such a significant restructuring of the document was warranted when only 
one participant was calling for it.

We have not yet had a clear steer on that.

kind regards,

Ray

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 6 Nov 2019 09:54:40 -0500

> one participant was calling for it.

I'm not actually calling for a restructuring of the document.  I'm calling
for the structure of the document to be followed.  Cleaning up section 3 by
moving its tests to section 8 and clearly describing non-response problems
instead is just following the existing structure of the document.

I did leave it open for you to restructure the document if you wish, to
actually combine sections 3 and 8.

Perhaps this response will encourage others to speak up about whether they
think either of those things are important changes.  It's possible people
saw my review of -13 and didn't feel the need to comment since someone else
already had.