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

Lanlan Pan <abbypan@gmail.com> Fri, 11 August 2017 05:02 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 256FD131CE8 for <dnsop@ietfa.amsl.com>; Thu, 10 Aug 2017 22:02:29 -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 69AyKe6_gLMj for <dnsop@ietfa.amsl.com>; Thu, 10 Aug 2017 22:02:26 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 2FC17132423 for <dnsop@ietf.org>; Thu, 10 Aug 2017 22:02:26 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id i66so38274295wmg.0 for <dnsop@ietf.org>; Thu, 10 Aug 2017 22:02:26 -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=0VWUDImnK9woM8iPH3MUDfarr61QG95GU87ZS+RXFto=; b=JUpBjoQv/UwlgPVBoDmC+zAJgzXAIA1cFViSd7biui3b/5EckIrckfIT8KYKoBxy7c gDdCeUYGupYrJIxv0zvbAeBOnOzP6I2Pi+1yHISzmNHhVs9UohUAeb8eOL8F6AwgJz7z Zlza7FI6z8ePxa4NQYPKzXcpGy0OlnOpcIgvXAza+5yh9m1xF143t2AMtGeO14ma73kg iuJk3rKB/vOW1SXpFgsjkj0RprwKtoIBjtjmEcQKYNLvDVExtmZHegJLAH3Bc3kofHO7 JkFnS6wkKQcBxpR7v1WeNkhMyZT2Ky4gyEFtkdHzxoP26YlnNjV4PrYU2Sta0QBfOpiS m2pA==
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=0VWUDImnK9woM8iPH3MUDfarr61QG95GU87ZS+RXFto=; b=N6oqGU2YNDFIujkE92Qvb3MBAG/mYjrJKRBnklkPRb2OTAubsRbuBdrtPtLKGbHuSC kyT6Z5HQ+vHGv+BSRroClXZKBRSOTBQ0zqvPji/VMFOUFk3zER4rJdhTFrmksA2PDHFv 6VV94WSNMClAPZNuyITNfFQX0jVY92NC/z7AluOItb2gNi5Q+UzGNrpz9BglHE6kJ6w1 i6MzpJhmYtaOWZDHwsRkzF1FILZ//8+ANgGc4tT9lzWuHzfDMdAdeSdS4Dz9XWV6wOYg EL6qGC+txFOrIX29bn4IJTPjxLNawaHJB1mPFJKSjcwjnzSkZiuRlGv1aUv8Ohafooe3 dXYQ==
X-Gm-Message-State: AHYfb5i6lKFY6ooq6ncvI/ZomzXtjEYj4cU+5nhGlRADC6BIkxRKcMBj mWXqsUUXrJtr957yY+CE5GeuBR8QOw==
X-Received: by 10.80.146.5 with SMTP id i5mr13947956eda.48.1502427744761; Thu, 10 Aug 2017 22:02:24 -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>
In-Reply-To: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz>
From: Lanlan Pan <abbypan@gmail.com>
Date: Fri, 11 Aug 2017 05:02:14 +0000
Message-ID: <CANLjSvVe99q4vtTW0TRopmQ0s9hC8HdMze5B6COs8Y_3unir5w@mail.gmail.com>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: Vladimír Čunát <vladimir.cunat@nic.cz>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c0c4606fbb905567338f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/frzhZd1DteqiJvMN-IvJhIKY4_w>
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: Fri, 11 Aug 2017 05:02:29 -0000

Hi Petr,

Thanks for your comments, :-)

Petr Špaček <petr.spacek@nic.cz>于2017年8月10日周四 下午7:04写道:

> Hello,
>
> On 4.7.2017 05:54, Lanlan Pan wrote:
> > Hi Tony,
> >
> > We try to solve similar wildcard problem.
> >
> > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> > <
> https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6
> >)
> > :
> > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> > - cached deduced wildcard: give the default wildcard RR.
> >
> > SWILD:
> > - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> >
> > SWILD is applicable even when Authoritative Nameservers don't give
> > NSEC/NSEC3 RR.
> > SWILD is applicable on non-validating Forwarding Resolvers.
>
> If I understand it correctly:
> - the only information added by SWILD RR is an explicit information
> about the original (unexpanded) name of wildcard owner
> - the very same information can be obtained from RRSIG RR in a
> synthtetised answer (RRSIG labels < owner name labels)
> - SWILD will work only if there are no nodes below the wildcard
>

Your analysis is totally right.

Assuming this analysis is right, I'm against this proposal.
>
> We can get even better behavior from aggressive NSEC use. Here are
> advantages of aggressive NSEC use:
> - does not require changes to existing authoritatives or signed zones
> - less fragile (if we consider manual SWILD specification as an option)
> - supports wildcards with nodes below it
>

Yes, aggressive NSEC use has advantages if:
1) AUTH give NSEC RR.
2) Every Intermediate Resolver supports DNSSEC validating and the NSEC
aggressive use.

>
Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
> is okay: New features are provided only by the latest version of
> the protocol.
>
But:
1) many wildcards occupy the Resolver cache, with no nodes below them.
2) many wildcards AUTH not give NSEC RR.
3) many resolvers not support DNSSEC validating, not to mention NSEC
aggressive use.

On the view of new feature, SWILD can be an alternative simpler choice to
deploy.

Petr Špaček  @  CZ.NIC
>
>
> >
> > Regards,
> >
> > Tony Finch <dot@dotat.at <mailto:dot@dotat.at>>于2017年7月3日周一 下午
> > 8:18写道:
> >
> >     Lanlan Pan <abbypan@gmail.com <mailto:abbypan@gmail.com>> wrote:
> >     >
> >     > This document specifies a new SWILD RR type for Intermediate
> >     Nameservers to
> >     > cache subdomain wildcard record, in order to reduce the cache size
> and
> >     > optimize the wildcard domain cache miss.
> >
> >     Isn't this functionality already provided by
> >     https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
> >
> >     Tony.
> >     --
> >     f.anthony.n.finch  <dot@dotat.at <mailto:dot@dotat.at>>
> >     http://dotat.at/  -  I xn--zr8h punycode
> >     Fitzroy: Variable 4 for a time in north, otherwise northeasterly
> >     becoming
> >     cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate,
> >     occasionally
> >     poor.
> >
> > --
> > 致礼  Best Regards
> >
> > 潘蓝兰  Pan Lanlan
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan