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

Ted Lemon <mellon@fugue.com> Fri, 18 August 2017 17:05 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 78C9613219A for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 10:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 nXAp8y6h5VNU for <dnsop@ietfa.amsl.com>; Fri, 18 Aug 2017 10:05:14 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 C960713231E for <dnsop@ietf.org>; Fri, 18 Aug 2017 10:05:13 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id t37so56777236qtg.5 for <dnsop@ietf.org>; Fri, 18 Aug 2017 10:05:13 -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=1Cb4VrPVtYREz1pYjV1SYrnCKPORNf/9ycRWJnF3RRU=; b=rshX1JUPXyR/Sq9SoWmQbdrBr2OZZXrTVN8WD4TvlSu4wJVB/4a88JWWgAl6go9Ps3 fRRS/n2ObWNFcNyaivfc8V7XLPKLf4yEhBG3Qyx2JGt+bDVpKeDDHq5GOq3VQS6PwgXg RF8r3mbREjXsgTYyZ1Xyg42VqW1m9/R3Hp8WLELUec4HBgzoKk3T31FSK/3arXHW+7c3 x6MuDmAvkko1QpejLl3hGze6qajE7hR1sXzWPMinoJ0Ti/0v+pzd9kN9ku2qOvDp34br 0YEI8O/X2nGZp7hnpgdgtXcrTTbDX6wtcR+n4X9M0+gqPIrMyT/naj228Uag95o/ZQ41 6D4A==
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=1Cb4VrPVtYREz1pYjV1SYrnCKPORNf/9ycRWJnF3RRU=; b=Tn5mneGqG+p9wOdk+Yd/dSUaqawkEJyAi97Nnp8JSfxRP1NEnO7fQY/RXblCRNlSYl a44IdyBrginhYwfOkDljJ/oO21ajUBqm+BL5Ra1LcPisFub+04KujLpmnThB16Nnm/UM 2yDIifIErGmOnGnuxyxu0017h+1Av3DXng57hl7VesXoKERsyOIq15cnWDXyf1WChNH6 YZwDvLHClm9AzI12NAXHeZVuEvLUUNtXPQVE8cYrdATnzOR1hN8RJG3GD4a9Rl3w3V+K 55fPo/ojG9MthGKuhZMreGyw5tcORFcfxuz9jx3zQmEGF7y+rF8mPn6/O2p0QItGhAp/ 0gtA==
X-Gm-Message-State: AHYfb5hX6A6BLGBZL6O5kjN8chkxmvBR1cvVEUMgLUcWDm2/tlI39q2A OmoBC+xjHvpQL3a7
X-Received: by 10.200.51.129 with SMTP id c1mr14001040qtb.71.1503075912910; Fri, 18 Aug 2017 10:05:12 -0700 (PDT)
Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id f184sm3809113qkd.57.2017.08.18.10.05.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:05:12 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <DF434FBC-2F11-4548-9071-1B5FE84A549E@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08822224-AC60-4708-8BD2-24763F9696F8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 18 Aug 2017 13:05:10 -0400
In-Reply-To: <CANLjSvUZC=DCbuCKmq28C4+Qm_SZ7GTpTWZPisp-Gvf5hg21qw@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> <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> <CANLjSvUZC=DCbuCKmq28C4+Qm_SZ7GTpTWZPisp-Gvf5hg21qw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Vp8lSRy6cUJklQk9fYv-5bJzz0Y>
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: Fri, 18 Aug 2017 17:05:17 -0000

El 18 ag 2017, a les 11:33, Lanlan Pan <abbypan@gmail.com> va escriure:
> So, can you talk about how your proposal saves cost over using a heuristic?
> It can be used with cache aging heuristic.
> Heuristic read in aaa/bbb/ccc.foo.com <http://ccc.foo.com/>, expire and move out;  then read in xxx/yyy/zzz.foo.com <http://zzz.foo.com/>,  expire and move out;  loop...
> => Map aaa/bbb/ccc/xxx/yy/zzz.foo.com <http://zzz.foo.com/> to *.foo.com <http://foo.com/> when heuristic read, it will reduce the load of move in/out.

By "move out" you mean "remove," right?   Move out implies that you are moving it somewhere.   You haven't actually answered my question.  You say that SWILD will remove the load, but you don't give any evidence of this.

> 
>> 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?
> 
> Ok, Similar to RFC8198 section 6 <https://datatracker.ietf.org/doc/html/rfc8198#section-6>
> Benefit but not problem,  directly return from cache, avoid send queries to authoritative, and wait for response, reduce laterncy.

Okay, but this isn't a reason to prefer this to existing, standardized technology.

>> 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.
> 
> Sorry, my expression is fault.
> 
> More details:
> 1) All of the attack botnets were customers of ISP, sent queries to ISP recursive with low rate, so all of the client's IP addresses were "legitimate", could not simply use ACL.
> 2) Normal users also visit [0-9]+.qzone.qq.com <http://qzone.qq.com/>, all the the random queries domain seems to "legitimate".
> => The client ip addresses and the random subdomains are all in the whitelist, not in blacklist.
> 3) ISP didn't have any DNS firewall equipment ( very sad situation, but it was true ) to take over the response of "*.qzone.qq.com <http://qzone.qq.com/>".
> 
> In this weaker scenario,  it will be better if give recursive more information to directly answer queries from cache, and make recursive not to send/cache many subdomains query/response.
> Of course, we can defense the attack with professional operation, solve the problem very well. But there are also many more weaker recursive only run bind software, without any protection...

Maybe they should upgrade.

> I will reconsider these problems of the proposal, make the improvement analysis on real-world caches before next step.

Thanks!   However, I would really encourage you to step back from your proposal and see if there's a way to accomplish what you want without adding this resource record.   I think you can get the same results you want without SWILD, and the result will be a lot better for the DNS as a whole.