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

"Ralf Weber" <dns@fl1ger.de> Wed, 16 August 2017 08:22 UTC

Return-Path: <dns@fl1ger.de>
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 45C2513264C for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 01:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ufu-oVQSnQOV for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 01:22:26 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83B132641 for <dnsop@ietf.org>; Wed, 16 Aug 2017 01:22:26 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 7FF195F4044C; Wed, 16 Aug 2017 10:22:19 +0200 (CEST)
Received: from [172.20.10.3] (tmo-108-211.customers.d1-online.com [80.187.108.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 511D75F4004A; Wed, 16 Aug 2017 10:22:16 +0200 (CEST)
From: Ralf Weber <dns@fl1ger.de>
To: Lanlan Pan <abbypan@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, dnsop WG <dnsop@ietf.org>
Date: Wed, 16 Aug 2017 10:22:20 +0200
Message-ID: <949DA2AE-6E76-4F70-84EA-9864D0D2687C@fl1ger.de>
In-Reply-To: <CANLjSvWkDTgqTg+fy2jZzfcaY7e1VWB11yiWMzO3MfcrCGVLSQ@mail.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>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QZR_4Fp2nnAnkj6lKgVlsFcRfHs>
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: Wed, 16 Aug 2017 08:22:28 -0000

Moin!

On 16 Aug 2017, at 6:19, Lanlan Pan wrote:

> 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%
So you are designing a protocol change for 0.12% of your queries? IMHO 
not a
good use of engineering time.

> Details in: Dealing with temporary domain name issues in the DNS
> <https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>
>
> <https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>
> The operational problem is, subdomain wildcards waste recursive cache
> capacity. Existing solution to the problem is not adequate in 
> recursive
> operating environment at present, because of low DNSSEC deployment.
Sorry can't read that, but from the abstract and your emails I think the 
main
flaw in your thinking is that you want to cache all the records, 
regardless of
how often they are queried. That is not how caching resolvers work. 
Records that
are not used frequently and most of these signalling queries are one 
time queries
just expire from the cache, either by LRU mechanism or TTL.

So long
-Ralf