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

Lanlan Pan <abbypan@gmail.com> Thu, 17 August 2017 04:09 UTC

Return-Path: <abbypan@gmail.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 2503713247A for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 21:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 bUt6HWfS924B for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 21:09:47 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 3D32F1320BE for <dnsop@ietf.org>; Wed, 16 Aug 2017 21:09:47 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id 5so6420743wrz.5 for <dnsop@ietf.org>; Wed, 16 Aug 2017 21:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8CibytmrpmypAPBrJ4sXM3ywuiAPj06hCJM8wPYSjpc=; b=JoUi2VuHUSrF9rBLfQt25UjGVkubcb8oqyigloWjVMyJMwcmMbw2M5/VZlR7kruDSI Xgl9PyGoK0TG7mRTAPSe9NTUkuT69mkbwpg7p9bpeMO1n6w97spBk2IYZiOL7fUS+6Yo HpUTl8VaLggksVagQ995N5rrtQlbcD5O2km0EDSC+gc7+2dCtQMCvRkU73iGhIQo3Vno LuBeGIDYWtTBnZIrY9YA7LxObYXL3QH8WhhVL/DSbORKiemp78zcyEBZfbRDhLUSMJeu UD4IFOaA69Qs8pqTF4aPwkwmuar4SmWwknG1pbAm+LeJVpbhu7Vf9wQ9A3uR4AKZte5z Ytxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8CibytmrpmypAPBrJ4sXM3ywuiAPj06hCJM8wPYSjpc=; b=njC+wm4GR/87YFVRZ71/yMsd4fcV4JGKB4Zhgy0bsFpzLcxwb3D54IZXiDRlmWHH4t Y+JnH/0MW3A+CGI+ok6oyu+R0KTEJt73/d3b0IAakKMRzbd81tUyQ1JpUGj/hU5rytm3 G1/3Wae2c5LbfgOd0pTVpuOD6AQN3oWtnYpNBw0SzfqTnEcVjTKCjcNuzQjWMYSMIvUp bDyCykca46vTSSEQbBv5GEIeuhDd3G75vmMJZ3csBOJZt6BDgjW1Yc3ztghcPZ3cXaf9 /HoYdrQNXiICPrJPE7osmd0ernb/K91gPXNexYW6t2cpAkMa5wQKMfpf7W5MiSB1aT34 /Ftg==
X-Gm-Message-State: AHYfb5ifSfc/e8b8du56nVgFqqiVeW072jHhJRindjVaf6Esqb5vWdCF n9HFCYlPBzRc2bMLbN7aVxEiHc5cB9Ec5wM=
X-Received: by 10.80.165.167 with SMTP id a36mr567698edc.286.1502942985742; Wed, 16 Aug 2017 21:09:45 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <FFA80661-78A3-40B8-8DBC-FE79E873BCAF@fugue.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Thu, 17 Aug 2017 04:09:34 +0000
Message-ID: <CANLjSvWcscFQSH9KdmZPgOb9vC5immDoJZjG3msQB5TqfiHkDQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c2548c870dd0556eb2ef1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TVr3Qyw-CkqD3NXmt2AdOIKj1n4>
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, 17 Aug 2017 04:09:51 -0000

Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU
& TTL works fine.
SWILD not save many online cache size, because of the queries rate.
And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,  the
rate can be about 10% for 1 day statistics. Because temporary domain names
expire after TTL time.  Ralf has similar curious.

The problem is:

1)  cache size
Recursives commonly cache "all queried domain in n days" for some
SERVFAIL/TIMEOUT condition, which has been documented in
https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,  we can use heuristics
algorithm for deciding what to cache, or just use simple rule like "select
domain which queies time > 5 in last n days".
We can use SWILD to optimize it, not need to detecting, just remove items
which SWILD marked, to save cost.

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

3) DDoS risk
The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC
unsigned.
For example,  [0-9]+.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.

Ted Lemon <mellon@fugue.com>于2017年8月16日周三 下午8:54写道:

> El 16 ag 2017, a les 0:19, Lanlan Pan <abbypan@gmail.com> va escriure:
>
> We analyzed our recursive query log, about 18.6 billion queries from
> 12/01/2015 to 12/07/2015.
>
> We found about 4.7 Million temporary domains occupy the recursive's cache,
> which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
> 360safedns, Cloudfront, Greencompute...
>
> Temporary Domain Names/ All Names: 41.7%
> Queries for Temporary Domain Names/ All Queries: 0.12%
>
>
> Okay.   So it sounds like you have an algorithm for detecting temporary
> domain names.   It seems to me that a quicker solution to your problem is
> to publish an operational document describing that algorithm and proposing
> ways that recursive caches can use it to prune such domains from the cache
> early.
>
> I'm curious if you studied the behavior of existing recursive caches in
> the presence of these domains: do they in fact cache at the rate you
> predict they will?   The reason I ask is that I know that my own company's
> cache, which is widely deployed in the exact scenario you are describing,
> has a pretty sophisticated set of heuristics for deciding what to cache.
> It would surprise me if it exhibited the behavior you are concerned about.
>
> BTW, your paper is behind a paywall, so please don't cite it as a reason
> to do anything in the IETF.   If you want the IETF to take action based on
> what is in the paper, you need to publish it openly.
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan