Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Lanlan Pan <abbypan@gmail.com> Tue, 15 August 2017 04:45 UTC

Return-Path: <abbypan@gmail.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 8DFEC1324BB for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 21:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rwtxVWq45KtX for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 21:45:30 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 4D3E1132397 for <dnsop@ietf.org>; Mon, 14 Aug 2017 21:45:30 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id m85so1533346wma.0 for <dnsop@ietf.org>; Mon, 14 Aug 2017 21:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dzBq9n3zT0kTS/v8ovhrEWVzNYSwNoOln7GRsnJqAiw=; b=iWGgH+xWbzsI75f3ESWcSD1wg/YOh6DWYMQXvR13XoFDi0bY82N8DDF2jk/Vnzr/no 7m0HhL2tQs7/Asic4ESDXTs3ac1QUx3B+QuN+ldRXUgxtY329oQyQFFyr6vRO8p1GSMs uTcSXsFQ/MeQcu7wRWbWQj7A9nQP7ehPESoBOaJd4xHP16jfuehMPV3P249mWg15Fh91 pkJCIuh5jQ1akdEFMi6+buYKkWZ1/uVLqbuVznlwT9tQIylyaaCt0oY1RGy3R61gs37N U59Si/kAvsysNvAmc7Wchv/LFpOBV7VNymB82SG5L39Rg5CxriRQ9nHSuvPHiliR8/y+ LJGw==
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=dzBq9n3zT0kTS/v8ovhrEWVzNYSwNoOln7GRsnJqAiw=; b=sMNAu1LMoq610bnUbyTSy/lBbe4UhfntOeKX01UX0k4b5NNpv78oO6kjR9B96cKWyZ PKlCcxArkSW+igPVj/T7xMlHf/cGUPVjq/0nN+2Go1nVXuDWQCLIxRbhXZ/0luLL+I59 254tl+y81oSIpRNYDLQ3NaFl3I+glutNXyBouYPP6rYp4tYrJPaF33THLAtFWQjoQBLm GLj2d4vqSZtqJPAsso4H2FA7nCOR7gF8X/F0JTBrkuvirxabERl4w9qq8bT67OGSb8bZ CYOklMw2NYmO2A+cZNhZRLfG1k312ETxWtIVqsd4cjQFYLLVANPBOecaNE1e6uSLJotp +4pw==
X-Gm-Message-State: AHYfb5jQZSLd4aV2ibr4U4CvKltZBMTOlQlqyg/FHtA+pqhQX7j7P+lj H/5jGR+71dBNoWXGkhhkvJ2D/DVzcB7k
X-Received: by 10.80.216.206 with SMTP id y14mr26019681edj.165.1502772328775; Mon, 14 Aug 2017 21:45:28 -0700 (PDT)
MIME-Version: 1.0
References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <CAAiTEH8ntOerB6MGKMS2xcCK3TL9n4fyLq6F+bpUY6oTUpWN8w@mail.gmail.com> <CANLjSvWOzaJcVL64BhNFKnTUEgfq06TQtoy=ZNJ_JafvPU1aSA@mail.gmail.com> <1659363.yAWSxLQAC2@tums.local> <CANLjSvUkoYt1LXwVQ90MVej6mwOg4Q_2=PT=+Rwrf=8k5WAaRA@mail.gmail.com> <599216D2.8060608@redbarn.org>
In-Reply-To: <599216D2.8060608@redbarn.org>
From: Lanlan Pan <abbypan@gmail.com>
Date: Tue, 15 Aug 2017 04:45:17 +0000
Message-ID: <CANLjSvWyO0nbiSJGSqhRH33evbCUFLNzCjceAHJ-L89FA+En8g@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="089e08222db4d5c4c20556c372ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eJwVY_MoOLLzIPX1XX9PDOy5Ilg>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 15 Aug 2017 04:45:34 -0000

Hi Paul,

Don't judy other's motivation with meaningless skeptics. The endless
skeptics can also push on your RPZ to DNSSEC.

As an network engineer, I think good faith is face to the realistic
internet world, try my best to offer a better solution to technology
problem.

If we anticipated the subdomain wildcard scenario when designing wildcard
years ago, *make Authoritative give more precise wildcard information to
Recursive* (SWILD) is natually.
SWILD is not starting from "desire", not to mention "reducing DNSSEC
deployment".

*1) I believe,  reduce solution interdependence between different problem
areas is comfortable.*

Subdomain wildcard cache issue solution is not need to bind with security
issue,  in natural.

*2) I believe,  design an alternative solution to an existed problem is
ordinary.*

IPv4/IPv6 Migration can use Tunnel, NAT, ...
Subdomain wildcard cache optimization can use NSEC aggressive wildcards,
SWILD, ...

You can oppose to SWILD,  but wish you not oppose to the alternative
solution designing.

*3) I believe,  network protocol / feature deployment progress is decided
by the key function, not because of additional function.*

IPv6 deployment  will sharply rise mostly because of *IPv4 addresses
exhaustion*,  but almost impossible because of any improved IPv6 featue
that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ...
DNSSEC deployment will sharply rise if global nameservers desire *dns
security*, but almost impossible because of an addtional wildcards feature.

That is why I say "SWILD has no influnence on reducing DNSSEC deployment",
going further,  "NSEC aggressive wildcard has no influnence on rising
DNSSEC deployment".

Repeat the Google example,  as far as I can see:
- Google has expert on NSEC aggressive wildcard.
- Google likes to support some optimized protocols/features, such as QUIC,
SPDY, ...

Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return
NXDOMAIN.
Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED
in future, more probability than because of NSEC aggressive wildcards.


Paul Vixie <paul@redbarn.org>于2017年8月15日周二 上午5:32写道:

> WG Chairs: i oppose adoption of this draft.
>
> Lanlan Pan wrote:
> > Hi Paul,
> >
> > ...
>
> tl;dr: this message marks the end of this thread from my side.
>
> > I think, SWILD has no influence on DNSSEC deployment : 1) If
> > recursive wants to deploy DNSSEC, it is almost impossible because of
> > NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest
> > motivation behind DNSSEC depolyment.* 2) If recursive doesn't want
> > to deploy DNSSEC, it is almost impossible because of SWILD. Imagine
> > that, there is no SWILD to give precise subdomain wildcard
> > information from authoritative, recursive can use random subdomain
> > detect method to make cache optimization, which was described in DNS
> > Noise: Measuring the Pervasiveness of Disposable Domains in Modern
> > DNS Traffic
> > <http://astrolavos.gatech.edu/articles/dnsnoise-dsn2014.pdf>.
>
> Mr. Pan, your words above are a striking example of absurd reduction,
> which through a series of difficult-to-assail false equivalencies, an
> outcome unacceptable to your correspondent may begin to "look good on
> paper".
>
> Proof of this can by found by trying to reason your way to the
> conclusion you are offering, by any other path. You'll find this
> difficult, since the likelihood of someone deploying DNSSEC if it has no
> compelling features is lower, and aggressive negative caching with or
> without a wildcard is a feature of both DNSSEC and SWILD.
>
> In any case I find that you are arguing in bad faith, starting from your
> desire and then finding ways to justify it, rather than starting from
> the facts and finding out where those lead to. I won't play along any
> further. For your possible use, see these words from the NY Times
> opinion pages, published a day or so ago:
>
> <<What becomes clear to anyone following the climate debate, however, is
> that hardly any climate skeptics are in fact trying to get at the truth.
> I’m not a climate scientist, but I do know what bogus arguments look
> like — and I can’t think of a single prominent climate skeptic who isn’t
> obviously arguing in bad faith.
>
> Take, for example, all the people who seized on the fact that 1998 was
> an unusually warm year to claim that global warming stopped 20 years ago
> — as if one unseasonably hot day in May proves that summer is a myth. Or
> all the people who cited out-of-context quotes from climate researchers
> as evidence of a vast scientific conspiracy.>>
>
> --
> P Vixie
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan