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

Matthew Pounsett <matt@conundrum.com> Wed, 06 November 2019 13:42 UTC

Return-Path: <matt@conundrum.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66B12010C for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2019 05:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRK_v9xH-94C for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2019 05:42:40 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBB112089D for <dnsop@ietf.org>; Wed, 6 Nov 2019 05:42:40 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id m9so26115422ljh.8 for <dnsop@ietf.org>; Wed, 06 Nov 2019 05:42:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rZTPjKQR9p20J3M9yz56Lc0ADh0R9F/N8NCklpN0lfA=; b=qqCEZMbO8ZfpNj6c0QkD9ulsn3F4mzTdJa15OU2cgr3ysCz6LynNJKnQdBpkkZOJBF aLwbZBSXGqBq9OMpYC8RTHIu1LqbIW5Uu8+gpYlQBw0U+3EjfQh54MZFywKJ3QkoT7fS LVWx9P5AEMTjrkBvQZhWnS2oWin46LwzpwaT1ko9vHSClca8yF0fBezggKO8Dm7/mIyw UChXf96qAEgexYjP0Rw6kiPzbujQ6WKRo8iornXTpdnIPSSgVwaIctVo110k/Yk/DJ3R o7tYSP3oKgfA2jKkOtTnNTEcnCPSJ+KdcjTqnZrZVImhaKVzHF9F2BAKMoYSOHG/fMhr UC9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rZTPjKQR9p20J3M9yz56Lc0ADh0R9F/N8NCklpN0lfA=; b=hD1h4xeeTmTLip6tMb838Kh2lM+uNEEQnGd8ApA4vxzfZ+xzesGDSAMhz7VacOXjdb rR/nP6tE4qGvsoGE5WwQcY9XabAn6cSM6T4Ye1ysXQWetuaruMLkKWVYafLTN/g+FdeE 2eOOB34ZEvMY6P1/xOUtFwQA0pzcCLMqTu1V6TyE/aMk7cfnnWQc+OvsyUMgpYhyZVpz 4H2ZiwAUsh+DAaDW36PnRR/PYV9VnF5Q5Oxj4MjFs7HNepNrpwxFVTZGL2DmbQp9gs6i oXkOBk2i2ZQ5JDySN3u4fGvFmataRO+RtWJhZXjxtBFv062qw+OYB8MpwlkGQ93uiOJT mSdA==
X-Gm-Message-State: APjAAAWgESJQQROgbR2dUW2gvXEMxVqkOk0RswphpL2S1qWF+4W06IG+ 8R8QzpNfSuNDLMUeio2WSKS8dIySrzU7kDpupDh8MbgXvgPgzA==
X-Google-Smtp-Source: APXvYqysAcJ1UBHUYKHD5ZudRfyzo6CKCk9s1D8apL550svuGe+dtVSejO5Huww6G7PEChHQruY/5Te3XoO++VQ9Aiw=
X-Received: by 2002:a05:651c:303:: with SMTP id a3mr1957950ljp.55.1573047758033; Wed, 06 Nov 2019 05:42:38 -0800 (PST)
MIME-Version: 1.0
References: <157289952539.13851.12121504796430856747@ietfa.amsl.com>
In-Reply-To: <157289952539.13851.12121504796430856747@ietfa.amsl.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 6 Nov 2019 08:42:24 -0500
Message-ID: <CAAiTEH_t9Tsa_9go4JA=ELED7WcKzuPmCd_qD9nh+Vmicd0GQg@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: i-d-announce@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d52c260596adb8b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_Nq8PAVOapIVal2BS7P-jlWmnuc>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 13:42:43 -0000

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