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

Lanlan Pan <abbypan@gmail.com> Mon, 14 August 2017 07:26 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 12B59131D27 for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 00:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 Uq4xgR63V1oh for <dnsop@ietfa.amsl.com>; Mon, 14 Aug 2017 00:26:24 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 08FFF131D19 for <dnsop@ietf.org>; Mon, 14 Aug 2017 00:26:24 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id t138so15094826wmt.1 for <dnsop@ietf.org>; Mon, 14 Aug 2017 00:26:23 -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=3MzqldQnWAAtmNU54WC+aCzUzlxbGLkHE7Ia2VCjeM0=; b=lbAkMr7WrJC/DyGt/5Hq2nbbtg+lmiBgQLmbIY1rcGgTjXOaJJTGY2M8zUpxJAbT09 XitaBrMzWIvtqAOXLX1Ke/NxZvKm/2lYt2Gbui2TtRyzJxkzIU8RQp7na3ffLpCOfvaP c7j1KLH7CHJZzBq71gi/LHYOyMmbUYksuJsXEDbu2dFhTsXPtw0MsLKROjateZBEZFIF 1XGZyZ4YHOwQeks4x3HbEmes6Z/0Q3eJt+FSHeuqfhGdzerwKW8L/GJIpwxRr1pu66Tp bULYe+ziCt+Sjlfk/GiU+zMuivw0tsZ38F29HJwApNsnLXpYLN/KKHD8sBn3F9JGECOG jYiQ==
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=3MzqldQnWAAtmNU54WC+aCzUzlxbGLkHE7Ia2VCjeM0=; b=VV0W9sQY50q5KhUeGsg4wk0byjsPGj5fFkh6sMqSy/moqt5+4WzFfRVoLkGj6wwaDP Av3jrAQnsMEz9GeSfJ7ebPYLORGZAgTqdP9tV4Td18LAsax4P/i1pdt6ikszSQmzr1Dm y3+KFzQC1lMPW0loijBUWF8rTLzhc9He/o1y+LerrjYsXgboYE/rKdYlJ0D/pn82PaxB /VBPUW831r29/eAqU8rN60Xm/tFmAUegi/V2pBZe/zZ+erI40nVYb1ER5tiPk8hzaY+m Y+jAd5NJXrmrB7liXVRhExYKTj2mSmi5uw2DFOpSJBQnAAjEo/3+PCG+IXal+tNa6pgt sbSQ==
X-Gm-Message-State: AHYfb5hFFOGK249pPtLKSyvWlaK6ZE2F/hDtsOW2q+OpJVlEdoiHf0SF K6OGKu+XObhSE9J73/dxlTapMCmrSg==
X-Received: by 10.80.146.5 with SMTP id i5mr22934429eda.48.1502695582515; Mon, 14 Aug 2017 00:26:22 -0700 (PDT)
MIME-Version: 1.0
References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <CANLjSvU23OPMM=cETxBiV7j8UhMzMd426VuivxAtboMAB0=7jw@mail.gmail.com> <alpine.DEB.2.11.1707031317070.21595@grey.csi.cam.ac.uk> <CANLjSvXE4q9PSEc4txKM4OPKXVpT38N_PC2-fDHmihpk29ahcw@mail.gmail.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <CANLjSvVe99q4vtTW0TRopmQ0s9hC8HdMze5B6COs8Y_3unir5w@mail.gmail.com> <CAAiTEH8ntOerB6MGKMS2xcCK3TL9n4fyLq6F+bpUY6oTUpWN8w@mail.gmail.com> <CANLjSvWOzaJcVL64BhNFKnTUEgfq06TQtoy=ZNJ_JafvPU1aSA@mail.gmail.com> <CAAiTEH_3d3_DJoeB-7iQTP-3QVCArU9p=U9YAxntiOp2Vh_1=g@mail.gmail.com>
In-Reply-To: <CAAiTEH_3d3_DJoeB-7iQTP-3QVCArU9p=U9YAxntiOp2Vh_1=g@mail.gmail.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Mon, 14 Aug 2017 07:26:11 +0000
Message-ID: <CANLjSvWizPQ2LCZwXPF17GjDcb0yAcPoT5Z-_4Z+oNc592dtWg@mail.gmail.com>
To: Matthew Pounsett <matt@conundrum.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, Petr Špaček <petr.spacek@nic.cz>, dnsop <dnsop@ietf.org>, Vladimír Čunát <vladimir.cunat@nic.cz>
Content-Type: multipart/alternative; boundary="f403045c0c4666c5e50556b19410"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ix5pCwEGMNWuQbzR7ViJ7cAyoGA>
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: Mon, 14 Aug 2017 07:26:27 -0000

Hi Matthew,

Thanks for your detailed reply, :-)

Matthew Pounsett <matt@conundrum.com>于2017年8月13日周日 上午12:31写道:

> On 12 August 2017 at 04:29, Lanlan Pan <abbypan@gmail.com> wrote:
>
>> Hi Matthew & Paul,
>>
>> Good question, :-)
>>
>> SWILD is a feature just for recusive cache optimization, only dealing
>> with the wildcard subdomain issue (with no nodes below).
>> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
>> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>>
>> My assumption is: *we can give recursive server an alternative solution
>> for wildcard subdomain cache issue, not need to depend on DNSSEC.*
>> Authoritative server just simply add one SWILD RR, not much deploy cost.
>> Recursive server can add SWILD support if it has an interest in wildcard
>> subdomain cache optimization,  it is OPT-IN.
>>
>
> I confess it was a rhetorical question. All of the major implementations
> already support DNSSEC.  8198 doesn't have an implementation status
> section, but there's every reason to think the major implementations will
> have support within a version of two.  A quick survey of a few issues
> databases shows that at least Knot is already working on it.  That is a
> significant head start; SWILD support without DNSSEC support can't happen
> in any significant way, and SWILD support without support for 8198 doesn't
> seem likely.
>

We know that we will have a Swiss Army knife (DNSSEC) in the future, can we
also put a Fruit knife (SWILD) in the kitchen now?


>
> As for operator adoption, the incentives are all wrong for this to
> actually get used.
>
> Recursive operators already have a very low operational bar to turn on
> DNSSEC and get the same benefit to their cache.  In both cases (SWILD and
> DNSSEC) they rely on the authoritative operator opting in before that
> benefit can be realized.
>
> Authoritative operators may choose to use DNSSEC  because it will secure
> their zone, and if recursive operators also have 8198-capable name servers
> then the workload for both authoritative and recursive is reduced for all
> terminal names.
>
> With SWILD, there is no direct benefit to the authoritative operator, as
> far as I can see.  Given that the only benefit to using SWILD is to the
> recursive operator, what is the motivation for the authoritative operator
> to add complexity to their deployment by adopting it?  Traditional
> wildcards work fine for them.
>

Authoritative will be directly benefit, save cost, reduce wildcard
subdomain response laterncy.

As methioned in the draft : "Intermediate Nameservers' cache hit rate will
rise, avoid to query Authoritative Nameserver for the same wildcard domain
configuration."
Imagine that Recursive Resolver knows that SWILD RR of wildcard domain "*.
foo.com". In TTL time, if Recursive Resolver receives "
yyy.foo.com/zzz.foo.com/..." A RR query, it can directly return this
subdomain wildcard response without send dns queries to Authoritative.

Traditional wildcards work no so fine for them, it make recursive send many
subdomain dns queries to Authoritative.

Authoritative operators can choose DNSSEC because of security,  they can
also choose SWILD because of wildcard domain response optimization.  Not
contradictory.


> To make the adoption problem worse, it appears as if SWILD is more limited
> in its use than traditional wildcards.  For example, I don't see how you
> could occlude an SWILD record with a more-specific domain name, as you can
> with traditional wildcards.
> Here's a common scenario based on the example from the draft:
>    @    86400  IN   SWILD  _
>    _     3600  IN   CNAME  map.bar.net.
>    *      600  IN   CNAME  _
>  dev      600  IN   CNAME  map.dev.bar.net.
>
> How does SWILD behave when a client queries for dev?  According to the
> draft, the authoritative server would return the SWILD record at the apex.
> An SWILD-aware recursive server seems like it would ignore the CNAME
> returned for dev and instead use the CNAME for _, which is not what the
> operator intended.
>

As I replied to Petr, "many wildcards occupy the Resolver cache, with no
nodes below them."

Most of the subdomain wildcards for CDN, P2P, advertise, anti-virus, DNSBLs
service have not specific subdomain like "dev",  SWILD is not for this
condition.


>
>>
>> *I don't expect implementers would adopt SWILD 100% before adopting
>> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can
>> decide adopting or not, before or after, we won't pre-select for them.*
>> Even if both Authoritative server and Recursive server support
>> DNSSEC+NSEC aggressive, when will they configure default dns query with
>> dnssec ? (for NSEC agreesive cached deduced wildcard)
>>
>
> We already know that a year ago 26% of all end users were behind some sort
> of validating resolver, a number which continues to climb as more ISPs turn
> on validation, and more users switch to things like Google Public DNS
> <https://labs.apnic.net/presentations/store/2016-06-27-dnssec.pdf>.  This
> isn't an ideal deployment status so long after DNSSEC was standardized, but
> it's a long way ahead of SWILD.
>

Every protocol feature has a deployment progress, nobody thinks that will
be a short time, the same with other features such as ANAME, DANE, ...


> You'll need to have a very compelling argument for me to believe that
> SWILD is both more useful than DNSSEC and more likely to be deployed at any
> kind of scale that would make a difference.  I just don't see it.
>
> Add to that Paul's point that we would very much like to encourage DNSSEC
> adoption, I don't see why we'd add support for an alternative technology
> that accomplishes a subset of its features.
>

I don't think SWILD will be more useful than DNSSEC,  everyone knows that
they are different features, and it is impossible.

I think SWILD has no influence on DNSSEC deployment,  details in last mail
replied to Paul.

One question:  is wildcard subdomain cache issue solution must bind with
security feature ?

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan