Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 12 September 2018 22:13 UTC

Return-Path: <kaduk@mit.edu>
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 0A4BF130F8A; Wed, 12 Sep 2018 15:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fQWS6Q61FTXQ; Wed, 12 Sep 2018 15:13:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61438130F7E; Wed, 12 Sep 2018 15:13:55 -0700 (PDT)
X-AuditID: 12074423-80dff70000003d3a-f3-5b998fa0016d
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.05.15674.1AF899B5; Wed, 12 Sep 2018 18:13:53 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8CMDlHl011625; Wed, 12 Sep 2018 18:13:48 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8CMDgeG011333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Sep 2018 18:13:44 -0400
Date: Wed, 12 Sep 2018 17:13:42 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-refuse-any@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>
Message-ID: <20180912221339.GV48265@kduck.kaduk.org>
References: <153659090282.26589.6349707416227956108.idtracker@ietfa.amsl.com> <CAN6NTqxeNcnW+nawMmUcKGs7++nHzfXp91=NbFY0r5FiVsqjUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN6NTqxeNcnW+nawMmUcKGs7++nHzfXp91=NbFY0r5FiVsqjUA@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6noruwf2a0QcdvbYs32yexWNx9c5nF 4uHBO2wWM/5MZLZYvHkji8W0ts3MDmweH2dPYPPYOesuu8eSJT+ZApijuGxSUnMyy1KL9O0S uDLazt1iKtipX/Ft3mXGBsaZql2MnBwSAiYSx771sncxcnEICSxmkrj7+iQzhLORUeLn0xls EM5VJolTi98zg7SwCKhK7Di4mAnEZhNQkWjovgwWFxFwlnjzbQJYN7PAVkaJx/9WgyWEBUIl ej6uB2vgBdo3qXsPC4gtJDCFUeJAtwlEXFDi5MwnYHFmAR2JnVvvAG3mALKlJZb/44AIy0s0 b53NDBLmFAiU2PUmCSQsKqAssbfvEPsERsFZSAbNQjJoFsKgWUgGLWBkWcUom5JbpZubmJlT nJqsW5ycmJeXWqRrppebWaKXmlK6iREcCS7KOxhf9nkfYhTgYFTi4W0QmhktxJpYVlyZe4hR koNJSZR3cRZQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjva3agHG9KYmVValE+TEqag0VJnPeC 7uRoIYH0xJLU7NTUgtQimKwMB4eSBO+7PqBGwaLU9NSKtMycEoQ0EwcnyHAeoOHJIDW8xQWJ ucWZ6RD5U4y6HH/eT53ELMSSl5+XKiXO+wOkSACkKKM0D24OKIFJZO+vecUoDvSWMK8OSBUP MPnBTXoFtIQJaMnnPTNAlpQkIqSkGhhZ19r+t7+X09VqKBy0/YpQbPS/oNf5xb+2bXbc3TS3 bG+Y9tHCgs+2bfPf2gc9W+676XqbdWVnJif3zc/nY4+tYFyeUmXE/cJa+ttqFcUVFqxfJb4U cFRneYs1fPCuTOePt//sYRBu7/u65lrcVza/AG0l7uc373xw8+JO1/y5NGueBcPns0osxRmJ hlrMRcWJADvUwpw7AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jhbw8pfAU9Xow8FaGP5EIguSukg>
Subject: Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
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, 12 Sep 2018 22:14:05 -0000

Hi Ólafur,

Before I get into the inline comments, I should note something that I only
noticed after I posted my ballot position: although everyone I know always
refers to this query as "ANY", that's the command-line interface in dig(1),
etc., it seems that the specified string to refer to this query is
officially "*".  That's what 1035 uses and that's what's in the IANA
registry; RFC 6895 has a clarification in a parenthetical "* (ALL/ANY)",
but I didn't see much precedent for only using "ANY" in an RFC to refer to
this query.  To be clear, I don't object to using that as the primary term
-- it is, after all, the common usage!  But perhaps it's worth a short
mention at the start that we use "ANY" to refer to QTYPE 255, registered as
"*".  The reader can perhaps infer this fact from the IANA considerations
that update that entry in the registry to also refer to this document, but
it would be nice for the relationship to be more explicit.


On Thu, Sep 13, 2018 at 08:51:45AM +1100, Ólafur Guðmundsson wrote:
> On Tue, Sep 11, 2018 at 1:48 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dnsop-refuse-any-07: Yes
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I am balloting YES, because it is good to have these techniques available,
> > but
> > I also have some comments that I would like to see addressed or rebutted.
> >
> > The Shepherd writeup does not say why 1034/1035 are not mentioned in the
> > Abstract.  Also, the phrase "updates [103x] by" does not appear in the
> > Introduction, leaving just section 7 to describe the changes.
> >
> 
> --->
> Section 1 has following text
> 
>   The DNS specification [RFC1034] [RFC1035] does not include specific
>    guidance for the behaviour of DNS servers or clients in this
>    situation.  This document aims to provide such guidance.
> 
> 
> Is that sufficient for readers ?

I was coming at this from the perspective of the proposed IESG statement on
the use of the "Updates" (see thread at
https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html), the
wording or which would imply that a stronger statement is appropriate in
this document.  But the linked proposal is not yet in effect, and as such
is non-binding.

> 
> > The document doesn't really make it clear whether the "[t]he operator [...]
> > might choose not to respond to such queries" is restating an existing
> > specification from some other document or making a new statement.
> >
> It is stating an operating practice

Is this behavior permitted by the existing RFCs, or a grey area, or in
contravention to the spec?

> Section 1.1
> >
> > As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719
> > by the time this document's publication process finishes.
> >
> > If that is published I hope RFC editor Auth48 phase will catch it
> 
> 
> > Section 2
> >
> > It seems like the intended takeaway here is that there's a balance or
> > tradeoff to had between the "good" uses (efficiency of getting all desired
> > data at once) and "bad" ones (amplification), with mining for zone data
> > being a "dual-use technology".  The text doesn't really help the reader
> > reach that conclusion, though -- a few extra words at the start of each
> > paragraph might help, like the "legitmiately used" in the very first one,
> > or "On the other hand, ANY queries are frequently abused to [...]" might
> > help set the intended tone.
> >
> >
> IMHO there is no "good" use of ANY in the world but by the operator of the
> server,
> all other uses are based on misunderstanding or abuse,
> others disagree.
> Since this document was started the abuse of ANY has decreased against the
> operators that have adopted the techniques in the document
> but at the same time moved more to operators that do not support it.

Ah, interesting.  This was a non-blocking comment anyway, so (as Spencer is
acclimating us all to say) "do the right thing".

> Section 4
> >
> > Should "return a conventional ANY response" be listed or mentioned here?
> >
> IMHO no

Okay.

> 
> > Section 4.2
> >
> >    [...] The
> >    specific value used is hence a familiar balance when choosing TTL for
> >    any RR in any zone, and be specified according to local policy.
> >
> > nit: Is there a missing word or three before "be"?
> >
> "to be " ?
> 
> >
> >    DATA described in this seection to distinguish between synthesised
> >    and non-synthesised HINFO RRSets.
> >
> > nit: "section"
> >
> good catch
> 
> 
> >
> > I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU'
> > contents of "RFCXXXX" for the final RFC number, since I can't come up with
> > an other reason why that CPU value would be used.  But I do not object to
> > it.
> >
> thanks
> 
> 
> > Section 4.4
> >
> > Why are we enumerating transports instead of talking about the properties
> > they provide?  We've got multiple new transports in the works, and it would
> > be a shame to ignore them out of the gate.
> >
> >
> This is a good point DNS people have in the past only thought in the
> context of two transports UDP and TCP
> but the world is changing.
> We will work on text that replaces TCP with "transport properties" as
> Spencer has suggested.

Great; thanks!

-Benjamin