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

Petr Špaček <petr.spacek@nic.cz> Thu, 10 August 2017 11:04 UTC

Return-Path: <petr.spacek@nic.cz>
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 85F33132695 for <dnsop@ietfa.amsl.com>; Thu, 10 Aug 2017 04:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 47qxFTLqLrF7 for <dnsop@ietfa.amsl.com>; Thu, 10 Aug 2017 04:04:42 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C3C126C22 for <dnsop@ietf.org>; Thu, 10 Aug 2017 04:04:41 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a] (unknown [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a]) by mail.nic.cz (Postfix) with ESMTPSA id 85C23624E7; Thu, 10 Aug 2017 13:04:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502363078; bh=nHALdF5FbyeZbTVB7aL9jirZ9ScEi7bxIwCm13mPSYU=; h=From:To:Date; b=kT71UEDxbZxmAach2p/floxrqLMfwQvQ9cuR8GtsMC3l4hnHTkqi2KHCGYD/Aksiv INDWJXbSSZOVxxmfvSF/KdlaDuUdbm4z9/dTha3Gkm8K9WJuAuoxZ5/p+B+OUiFdbF BBfGqm7lM2f3VBm7/9Cgs/OIUEbS+PNLuT7/moIg=
From: Petr Špaček <petr.spacek@nic.cz>
To: dnsop@ietf.org
Cc: Vladimír Čunát <vladimir.cunat@nic.cz>
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>
Organization: CZ.NIC
Message-ID: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz>
Date: Thu, 10 Aug 2017 13:04:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CANLjSvXE4q9PSEc4txKM4OPKXVpT38N_PC2-fDHmihpk29ahcw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/54iKqj-FuwkR-EHIwx7oOQeBOqY>
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: Thu, 10 Aug 2017 11:04:44 -0000

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

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

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