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 21:52 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 291AF130EF2 for <dnsop@ietfa.amsl.com>; Wed, 12 Sep 2018 14:52: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=unavailable 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 a5Sm5wvgwIZ6 for <dnsop@ietfa.amsl.com>; Wed, 12 Sep 2018 14:51:58 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 1474E130ED6 for <dnsop@ietf.org>; Wed, 12 Sep 2018 14:51:48 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id t25-v6so3969831wmi.3 for <dnsop@ietf.org>; Wed, 12 Sep 2018 14:51:47 -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=LVmXhxEr3VQMGfUFmVummFHHNENiS/s2LeLfduchbVE=; b=f4+z40GiKF1iaX4hjzWAvmjKG3jM+V4nyFuM50JpyVPqTL72yVwc+89LkpwuZ43wX0 6La/KTzs7rrZq18Oq+22uuRItOd+CqxSu7XJ6DwYTMQ89n9qL4SmHepVhoTDGeNThU6l 4FG4bZS5te0TDK63s02epHVnSkHBvyMzAG6jI=
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=LVmXhxEr3VQMGfUFmVummFHHNENiS/s2LeLfduchbVE=; b=uR5UxP2h9pQgg+AXpjoSOLdx/3Jmal10O4dsAYTXkdUGfeKAxDt5UfgX9IJm+LQXfv itd2TV4qHJSgmPCx619WweEujJgCCZPFhNXUnonRGzm2ZpB3p5m6ie2D+JnGHAPG8TE3 0MHpnNCq07E2qOHMs753BpC2dHtNJ3Qi3tg16HE+ZndpgxoBIS+/XgjWGtC0pFafZPXX saU6sZPCY7aaKJhwQLtpawaKCo7QvBGaJB18E676nXIckegAjx+UiJvf5ezp1HQtAeux mrdi/1uqz3lr2VjTY0QVU61waT9Azv+pLnflRD82cGRuD7l4mYV4d/qhgmlcsES8eqno bqgQ==
X-Gm-Message-State: APzg51COAWktiCT5Bq7WFhKpW7HQfe+YNe5ZHFDyInlZWmCE0zok4AAy w27sLMwT8uoQWARpnMH+ig/XSEDSdQ5VOY9jOtXn8g==
X-Google-Smtp-Source: ANB0VdZFAchNHBao+gVJBBzQ/yiYKh7b7s6lw7vSAM0C5M4iNE7F0fKxRwts+mKoI5GyoQtBNMFAmnim9+UwOwdhHOs=
X-Received: by 2002:a1c:1802:: with SMTP id 2-v6mr3006979wmy.81.1536789106371; Wed, 12 Sep 2018 14:51:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:e451:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 14:51:45 -0700 (PDT)
In-Reply-To: <153659090282.26589.6349707416227956108.idtracker@ietfa.amsl.com>
References: <153659090282.26589.6349707416227956108.idtracker@ietfa.amsl.com>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Thu, 13 Sep 2018 08:51:45 +1100
Message-ID: <CAN6NTqxeNcnW+nawMmUcKGs7++nHzfXp91=NbFY0r5FiVsqjUA@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="000000000000c7f0a10575b39860"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/smgDZRqm4Ozt1PgeC0cpBj_k_qI>
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 21:52:02 -0000

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 ?


> 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

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.

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


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



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