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 >
- [DNSOP] Fwd: New Version Notification for draft-p… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Tony Finch
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Petr Špaček
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Matthew Pounsett
- Re: [DNSOP] New Version Notification for draft-pa… Paul Hoffman
- Re: [DNSOP] Fwd: New Version Notification for dra… Richard Gibson
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Matthew Pounsett
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-pa… Peter van Dijk
- Re: [DNSOP] New Version Notification for draft-pa… Matthew Pounsett
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Mark Andrews
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Mark Andrews
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Vernon Schryver
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Vernon Schryver
- Re: [DNSOP] Fwd: New Version Notification for dra… Ted Lemon
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Mukund Sivaraman
- Re: [DNSOP] Fwd: New Version Notification for dra… Mikael Abrahamsson
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Mukund Sivaraman
- Re: [DNSOP] Fwd: New Version Notification for dra… Mukund Sivaraman
- Re: [DNSOP] Fwd: New Version Notification for dra… Mikael Abrahamsson
- Re: [DNSOP] Fwd: New Version Notification for dra… Mukund Sivaraman
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Mark Andrews
- Re: [DNSOP] Fwd: New Version Notification for dra… Davey Song
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] New Version Notification for draft-pa… Ralf Weber
- Re: [DNSOP] New Version Notification for draft-pa… Lanlan Pan
- Re: [DNSOP] Fwd: New Version Notification for dra… Davey Song
- Re: [DNSOP] Fwd: New Version Notification for dra… Mikael Abrahamsson
- Re: [DNSOP] Fwd: New Version Notification for dra… Ted Lemon
- Re: [DNSOP] Fwd: New Version Notification for dra… Vernon Schryver
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Vernon Schryver
- Re: [DNSOP] fragile dnssec, was Fwd: New Version John Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] Fwd: New Version Notification for dra… Vernon Schryver
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Mark Andrews
- Re: [DNSOP] Fwd: New Version Notification for dra… Lanlan Pan
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Petr Špaček
- Re: [DNSOP] Fwd: New Version Notification for dra… Paul Vixie
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Matthew Pounsett
- Re: [DNSOP] fragile dnssec, was Fwd: New Version John R Levine
- Re: [DNSOP] New Version Notification for draft-pa… Ted Lemon
- Re: [DNSOP] fragile dnssec, was Fwd: New Version John R Levine
- Re: [DNSOP] New Version Notification for draft-pa… Ralf Weber
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Mark Andrews
- Re: [DNSOP] fragile dnssec, was Fwd: New Version John R Levine
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Mark Andrews
- Re: [DNSOP] updating fragile dnssec, was Fwd: New… John R Levine
- Re: [DNSOP] updating fragile dnssec, was Fwd: New… Patrik Fältström
- Re: [DNSOP] New Version Notification for draft-pa… Lanlan Pan
- Re: [DNSOP] New Version Notification for draft-pa… Lanlan Pan
- Re: [DNSOP] New Version Notification for draft-pa… Ted Lemon
- Re: [DNSOP] fragile dnssec, was Fwd: New Version John Levine
- Re: [DNSOP] New Version Notification for draft-pa… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-pa… Lanlan Pan
- Re: [DNSOP] fragile dnssec, was Fwd: New Version Petr Špaček
- Re: [DNSOP] fragile dnssec, was Fwd: New Version A. Schulze