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

Ted Lemon <mellon@fugue.com> Thu, 17 August 2017 13:56 UTC

Return-Path: <mellon@fugue.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 DFACE132577 for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 06:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 OjqxdWoo9BfS for <dnsop@ietfa.amsl.com>; Thu, 17 Aug 2017 06:56:20 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 26AB3132499 for <dnsop@ietf.org>; Thu, 17 Aug 2017 06:56:20 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id p3so37794693qtg.2 for <dnsop@ietf.org>; Thu, 17 Aug 2017 06:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5IdYHIy+13xgnFu7WDLOVIUokAwAYh0SdN7LUEwcKiQ=; b=kyX2QJ1sSo69A/YkAhUYhSHsAnsyNt9AOJGQmWlCMAF6Gx9AFCyRENQ2UP2mWGuxrF +TsF9oFAA+B6UvYuNPogLolukZobTDhjYxITtG3hjizPSIUrd7vzopjtYQJvbdxferLL mXtYdhgs7roPJJjaXG1h4cTqX3M80SuKS0kA5pT5vI4Dw9RCQd5K4Xi1ihJmGdaJBcl3 NV0q7pVagAOSq4WK6Sj26y4HEMShm5xItak3AqkefGg45iMxKdLNLQI/3Mh59jT23Dl6 7JIDeTfm0VkwCPQC0bwTGAmoO8ygm2r5xrgoF7mt9HYc4WCa2REjZayGfafFhGFnJqDB Abcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5IdYHIy+13xgnFu7WDLOVIUokAwAYh0SdN7LUEwcKiQ=; b=VZCbazZq/A9pcgJridZqmFPy/IicuQ+k9ujBf5+m9PMtzwtFPveEB1xyG6Q+gnBDJH HcqXPVxNidRG4weRQAZ9f3WCYlIYEj2MTIKQjeBZ1TP2I5NtwnZ1qb2mbFX3fo/4DZ8b bgGMIxy7TLyLNC0pA/xDsESFmebQHzg3aFzDJaVcBsD5PXHoV6iWxC2yeT97/6C86jaU 5xj73RQU0M6AK9nBwqgS+cPbK+YPhLlSi888aLPgG2WMkwJlI0108Lb4YzsdPpYc9/yY dnLgofPHYQSTi6SiN3SJv+Ty5potcXZ5PGdL1BTeh6GEEFIM04tISskBX3CA6XHuSzqR fSpQ==
X-Gm-Message-State: AHYfb5jthmAopcvCHkwLNVDM2RC5hFz8iS8rGG4sP753nwo7/4AuVwVw WP4ndU/zMbB/630q
X-Received: by 10.200.55.129 with SMTP id d1mr7939500qtc.167.1502978179281; Thu, 17 Aug 2017 06:56:19 -0700 (PDT)
Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k184sm674254qkf.40.2017.08.17.06.56.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 06:56:18 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_268BB982-BE83-4769-A757-C28E208BAE50"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 17 Aug 2017 09:56:17 -0400
In-Reply-To: <CANLjSvWcscFQSH9KdmZPgOb9vC5immDoJZjG3msQB5TqfiHkDQ@mail.gmail.com>
Cc: dnsop WG <dnsop@ietf.org>
To: Lanlan Pan <abbypan@gmail.com>
References: <CANLjSvWFh0ER47=SFJB-3rkTJKT_OxcjKwcD9-DUkDDxJTo=+g@mail.gmail.com> <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <CAPt1N1=2eFRBCHYptn6W=3ruFisN0xRcMQSPPakgZXnmsaTS5w@mail.gmail.com> <CANLjSvWkDTgqTg+fy2jZzfcaY7e1VWB11yiWMzO3MfcrCGVLSQ@mail.gmail.com> <FFA80661-78A3-40B8-8DBC-FE79E873BCAF@fugue.com> <CANLjSvWcscFQSH9KdmZPgOb9vC5immDoJZjG3msQB5TqfiHkDQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mXOheQ2xTy4OAwh7TNlOw0WRYPg>
Subject: Re: [DNSOP] 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, 17 Aug 2017 13:56:23 -0000

El 17 ag 2017, a les 0:09, Lanlan Pan <abbypan@gmail.com> va escriure:
> We can use SWILD to optimize it, not need to detecting, just remove items which SWILD marked, to save cost.

So, can you talk about how your proposal saves cost over using a heuristic?

> 2) cache miss
> All of temporary subdomain wildcards will encounter cache miss.
> Query xxx.foo.com <http://xxx.foo.com/>,  then query yyy.foo.com <http://yyy.foo.com/>, zzz.foo.com <http://zzz.foo.com/>, ...
> We can use SWILD to optimize it,  only query xxx.foo.com <http://xxx.foo.com/> for the first time and get SWILD, avoid to send yyy/zzz.foo.com <http://zzz.foo.com/> queries to authoritative server.

Can you characterize why sending these queries to the authoritative server is a problem?

> 3) DDoS risk 
> The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC unsigned.
> For example,  [0-9]+.qzone.qq.com <http://qzone.qq.com/> is a popular SNS website in China, like facebook. If botnets send "popular website wildcards" to recursive,  the cache size of recursive will rise, recursive can not just simply remove them like some other random label attack.
> We prefer recursive directly return the IP of subdomain wildcards, and not rise recursive cach, not send repeat query to authoritative.

Why do you prefer this?   Just saying "we prefer ..." is not a reason for the IETF to standardize something.

There are a bunch of problems with your proposal, as I'm sure others have remarked before.   It breaks DNSSEC validation for stub resolvers that aren't aware of SWILD.  In the absence of DNSSEC validation, it creates a new and very effective spoofing attack (poison the cache with bogus SWILD records).   Etc.

So you need to clearly explain why it is that you prefer this approach, and not just say that it's something you like.   Are you using it in production?   Do you have data on what it does?   Do you have data on the behavior of real-world caches that you can cite that shows that SWILD would produce more of an improvement than just using a better cache aging heuristic?