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

Richard Gibson <rgibson@dyn.com> Fri, 11 August 2017 20:47 UTC

Return-Path: <rgibson@dyn.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 523BE132400 for <dnsop@ietfa.amsl.com>; Fri, 11 Aug 2017 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.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 zF-HpRHubkVf for <dnsop@ietfa.amsl.com>; Fri, 11 Aug 2017 13:47:25 -0700 (PDT)
Received: from mail-vk0-x245.google.com (mail-vk0-x245.google.com [IPv6:2607:f8b0:400c:c05::245]) (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 04F8113231E for <dnsop@ietf.org>; Fri, 11 Aug 2017 13:47:25 -0700 (PDT)
Received: by mail-vk0-x245.google.com with SMTP id j7so17898285vki.6 for <dnsop@ietf.org>; Fri, 11 Aug 2017 13:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QGsNB2ZsOif7W0JCoEK72rqKCRJX2TZSGCSPNcUQqCU=; b=koKN7iEHB3bPw6o3UHAOEmO9C9wiaVtXZSZGzFpGoOByZBzKUZ28k1M8FYuuPX7FzU Zy8e3gTbLzrS4UXNnmKDGEJ08gphSE9XSHBCU4yAZ0a51BYGEQRxacV09UJJion64HQw tijrE+QUzJpKcPv+qtpIjdzSCk2Pp9kBdX5xI=
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=QGsNB2ZsOif7W0JCoEK72rqKCRJX2TZSGCSPNcUQqCU=; b=dZjDN7PmvlXMWkX5QEdcvmoj6hgkeAxbxJPTTKQmSXsd5j7CimkoPgelHZ7+UKo+c1 rZbdkxXkGpqbaMNrQeKYFizo5P7EEji4p3jIPYA2edOMwdK5iOPfyFbmg3NNXx8hDG+P jmP7v4MscNrA6tEgtlpvByJcem9dHsGaMrNV9GnO0ldDB1kASIrP/pPmK6L4vmyRGiQS 4haJRwOkITMlKmn3nidyXuKRr442BsRLomArbrVpUJiM0MDZq9fT6mTFwLOVoKBsWFbF D1LYZ4WxtjTV3xvZjUQQmfsvcqU7yxCYi9MdIo/IvMvTO9LYYPRCqVhT7T3S0Uv5J3O1 43Ug==
X-Gm-Message-State: AHYfb5gdJSiEIZrR+6XIQ26Sr2S3//4bp/vt9g67v9X8FYwphr2ifmG9 cDb0b7ccjEX8vwEQtNPnrMxzpGqKY3XnAYjC/g==
X-Received: by 10.31.5.18 with SMTP id 18mr9660744vkf.200.1502484444042; Fri, 11 Aug 2017 13:47:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.85.83 with HTTP; Fri, 11 Aug 2017 13:47:03 -0700 (PDT)
In-Reply-To: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@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> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz>
From: Richard Gibson <rgibson@dyn.com>
Date: Fri, 11 Aug 2017 16:47:03 -0400
Message-ID: <CAC94RYYxo1ZkOL_QEvCpCqssHF1jJyoMMgo=VzXXPYFr+mUrJg@mail.gmail.com>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop <dnsop@ietf.org>, Vladimír Čunát <vladimir.cunat@nic.cz>
Content-Type: multipart/alternative; boundary="001a1143da04916bcd0556806bf0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2BVlC8fDF7NuxnLTvBxm9A8PohQ>
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 20:47:28 -0000

I'm assuming there's a very obvious answer to this question, but what would
break if unsigned wildcard caching were covered by allowing
DNSSEC-independent NSEC (and therefore
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )?

$ cat zones/github.io
; apex records
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
github.io. 900 IN NS ns-1339.awsdns-39.org.
github.io. 900 IN NS ns-1622.awsdns-10.co.uk.
github.io. 900 IN NS ns-393.awsdns-49.com.
github.io. 900 IN NS ns-692.awsdns-22.net.
github.io. 900 IN NS ns1.p16.dynect.net.
github.io. 900 IN NS ns2.p16.dynect.net.
github.io. 900 IN NS ns3.p16.dynect.net.
github.io. 900 IN NS ns4.p16.dynect.net.
github.io. 30 IN A 151.101.193.147
github.io. 30 IN A 151.101.129.147
github.io. 30 IN A 151.101.1.147
github.io. 30 IN A 151.101.65.147
github.io. 300 IN TXT "v=spf1 a -all"
; wildcard answer records
*.github.io. 3600 IN CNAME sni.github.map.fastly.net.
; aggressive-use signal covering LDH wildcard-synthesized names
*.github.io. 3600 IN NSEC github.io. CNAME NSEC
; aggressive-use signal covering pre-* wildcard synthesized names (omitted
to demonstrate selective application)
; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC

$ dig @$resolver +noall +answer example.github.io. A    ; positive answer
with covering NSEC for aggressive use
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
example.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer foo.github.io. A    ; positive answer from
cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
foo.github.io. 3590 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 20 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3590 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer bar.github.io. AAAA    ; negative answer
from cache plus fresh SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3579 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer baz.github.io. AAAA    ; negative answer
from cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 890 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3569 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer '\032.github.io.' A    ; positive answer
with non-covering NSEC (due to partial application; could be remedied by
adding another NSEC to the zone)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
\032.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

On Thu, Aug 10, 2017 at 7:04 AM, Petr Špaček <petr.spacek@nic.cz> wrote:

> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>