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

Ólafur Guðmundsson <olafur@cloudflare.com> Wed, 12 September 2018 22:39 UTC

Return-Path: <olafur@cloudflare.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 00909130ED2 for <dnsop@ietfa.amsl.com>; Wed, 12 Sep 2018 15:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.031
X-Spam-Level:
X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 gDxNScUxeY1I for <dnsop@ietfa.amsl.com>; Wed, 12 Sep 2018 15:38:57 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 AF957126F72 for <dnsop@ietf.org>; Wed, 12 Sep 2018 15:38:56 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id q8-v6so4093416wmq.4 for <dnsop@ietf.org>; Wed, 12 Sep 2018 15:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U1jmXQ5dgtA9DCYGvU96MsdE9vA8aFCzaYKzvvd0RqE=; b=vOALlvTdwymXooDaV/AyK5NoMhmoIscEhIg2mLrwvOf0AUkxQBQOk4ceVrmQKWXC2E F5CZYtOeUmU5mHKBu9AMQHuaq0KJ7ph/+M1LIcBwfrkFv/mzZplcXBLxoYY486DT+KwC XsMRIeYOMMnClm0VAY06tAIXTyzqSs3CzXHas=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U1jmXQ5dgtA9DCYGvU96MsdE9vA8aFCzaYKzvvd0RqE=; b=FRNbFmQF5AJ3/1C0lne11qUe8E+mqI9TcZ26nX0XL+fNtkfKRtPS2TRiAxTOYIuE8N Hm2UDONPkfxdCzGKs7qyxiq+r9Ojs+gFhq1MLXa4OtNpUnkiro/96yVhE3Vm7r7Ai/ny TyLEiM06f45cRsvBrrZuwciXBEbf77RgsledS0OTaeeO7fLqf6mbf8qxWRbAU1KcjavT Ch2YyNWcZqYfcO0pcUn3qN7qyrwhV5eh1e+uyYDF87Y7NU/Xp4YySZ3rG1KRz3Av5KxI KniQElwJUKda+08kRCMiWZDXGOEVO4dgkeA4vL6A/LxqEyn2j5dBrB2DAETQWQBLVbN5 kBjg==
X-Gm-Message-State: APzg51Bp0GH6yruXZhE52YPBGOrleytZgpr6Ompwx39yIWkA4SWu4jkT bmeq8a1YtZQMClExcokDdC+MEvDs0TdpTMTRCJA4pQ==
X-Google-Smtp-Source: ANB0VdaWp+8PONXO5PNWkstaBbaWtVt20og9IF5YxWM+nDmo3VxubB3ZnqCBG7HPtKRwlJnXh5gOv+IXv1xsbxjKVsQ=
X-Received: by 2002:a1c:4182:: with SMTP id o124-v6mr3191940wma.101.1536791934987; Wed, 12 Sep 2018 15:38:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:e451:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 15:38:54 -0700 (PDT)
In-Reply-To: <20180912221339.GV48265@kduck.kaduk.org>
References: <153659090282.26589.6349707416227956108.idtracker@ietfa.amsl.com> <CAN6NTqxeNcnW+nawMmUcKGs7++nHzfXp91=NbFY0r5FiVsqjUA@mail.gmail.com> <20180912221339.GV48265@kduck.kaduk.org>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Thu, 13 Sep 2018 09:38:54 +1100
Message-ID: <CAN6NTqztdoxAPBuTjF4eDwzMMaSQWdQmEOkCKN=vZwLt83V8+Q@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Content-Type: multipart/alternative; boundary="000000000000610fbf0575b441dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NBXejRHIMitzxtL3D5cX3bRanYQ>
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:39:01 -0000

On Thu, Sep 13, 2018 at 9:13 AM, Benjamin Kaduk <kaduk@mit.edu>; wrote:

> 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.
>
> That is a great point something like:
RFC1035 defined "*" as type 255 but DNS applications have used the "ANY"
word to refer to that type code"



> 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.
>
> thanks for the background,


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

Good question answer depends on who you ask
I say all three


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


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



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com