Return-Path: 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 61748132361 for ; Tue, 15 Aug 2017 21:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 6UiF6MAe_7MB for ; Tue, 15 Aug 2017 21:19:22 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 6E99F1321A5 for ; Tue, 15 Aug 2017 21:19:22 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so21532894wma.0 for ; Tue, 15 Aug 2017 21:19:22 -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=RVcpz8f6wQQ9+EFLUs/WfEmVlyuRUauwMjJcvHKt1/w=; b=HDZ19Zx5ZNQPVZQt/1ifw/yo2mdsd8gUFhepPofq3Uy7bsOmvO0/VmGhWBVQ9sstIk SmNE157asUJvBf3ZV++7S9bK7t6Q16rwB1YqlkIV/LXQDx0kqDjPZCpDQsut2SRm4gHN r6khFRnG69KtJWpk7GFlhC++2umZSCsyY/DphQCwVSL1pqjF4lxQEONpONhGjzN2Ew1X f2zG/VeydkKN+Z4KJN+R44TTSSnRVc/URtNz5SLZrSREKXv30dHUYrQEHijwkTHon8mr Fty22r3C2pNvMkXdx+FqqFXF5QxWANzf1OSUjuf7DwwkQOMKliv785ueYa52sKuN9wrW c3Aw== 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=RVcpz8f6wQQ9+EFLUs/WfEmVlyuRUauwMjJcvHKt1/w=; b=VIITbcSUU9RqelchM9iH5cpygelTPrCvP3tOWcckgPKgd0un2oZ2baXUNNumjoukaI YrA4pZHkMjF6GqPwfWnzB9cYN9HakMa0PMJZVSAnlZzGAJGgPq1pBuvgwkfFfPPF5pX+ X1ngu4W2Opz2YNPsuR5tPdWAHYyp0ykJfNMRu2oWIG0bX+EVe9n05nsVVtCw15dLBxEc W5990aJ/+EYjUohsdj57ecmFI11AmpXdURrx/pwQ6pmrSUHwWtpC3XIB/Z14OgY47TuO WLoMBHbz6doTTIMZmCiOdomebZzXyJjTual6T2LuJA0bOtNtVOp7RgEE9wIWvOJb5N9F 9X7g== X-Gm-Message-State: AHYfb5hvHvApJgqFPXFzZ5LhNMJEr3HiFZJvFV/EN/IJxgoQqxt0NGjj D2xVVnXwq1a87qL6iIrgYra8S1GSodX9Y14= X-Received: by 10.80.146.5 with SMTP id i5mr708851eda.48.1502857160985; Tue, 15 Aug 2017 21:19:20 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> In-Reply-To: From: Lanlan Pan Date: Wed, 16 Aug 2017 04:19:10 +0000 Message-ID: To: Ted Lemon Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c0c463a8fbe0556d7336c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 04:19:25 -0000 --f403045c0c463a8fbe0556d7336c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ted, Thanks for your relevant comments, :-) Ted Lemon =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8A=E5=8D=881:28=E5=86=99=E9=81=93=EF=BC=9A > I tried to ignore this thread for a while, but became alarmed after > reading some of the recent comments, so I went and read the document. > > As far as I can tell, this document gives no clear justification for why > it is a good idea. We have not been told of the practical operational > problems that motivate it. It appears to solve a problem we have alread= y > solved, in a way that creates new security vulnerabilities. We have not > been told why the existing solution to the problem is not adequate. > > If the authors have a real problem that they feel has not already been > solved, the first step in the process ought to be to present that > information to the working group, rather than to present a solution to th= e > working group with no clear statement about the problem it solves, and in > particular no data about the seriousness of the problem. > For what it's worth, which isn't much since the chairs haven't issued a > call for adoption, I don't think the working group should work on this. > 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% Details in: Dealing with temporary domain name issues in the DNS 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. > > On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver wrote= : > >> ] From: Lanlan Pan >> >> ] Give the choice to operators, time is the best witness, like IP >> surpassed >> ] ATM. >> >> That is backwards. IP did not surpass ATM, because IP came long before >> ATM. Instead, end-to-end ATM was the last gasp of the end-to-end >> circuit switching point of view. End-to-end ATM was supposed to replace >> IP, but instead the new virtual circuits of ATM came far too late and >> did not solve the problems that packet switching had already solved. >> >> ATM has not yet died and is still common for some uses. For example, >> ATM is used as x.25 was used under IP in the early days of IP; many >> DSL installations use AMT VCs. >> >> A better and more relevant history is that of the SPF RR. The SPF RR >> was supposed to replace the use of the TXT rtype for SPF. The SPF RR >> was widely available in deployed DNS authoritative servers (via BIND). >> I think it was in milter modules for sendmail and postfix. Nevertheless= , >> it died because it came late, was only a modest improvement, and require= d >> operators to do something more than they were doing. >> >> >> Vernon Schryver vjs@rhyolite.com >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c0c463a8fbe0556d7336c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

Thanks for your relevant comment= s, :-)

Te= d Lemon <mellon@fugue.com>=E4= =BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D= =881:28=E5=86=99=E9=81=93=EF=BC=9A
=
I tried to ignore this thread for a while, but became alar= med after reading some of the recent comments, so I went and read the docum= ent.

As far as I can tell, this document gives no clear = justification for why it is a good idea. =C2=A0 We have not been told of th= e practical operational problems that motivate it. =C2=A0 It appears to sol= ve a problem we have already solved, in a way that creates new security vul= nerabilities. =C2=A0 We have not been told why the existing solution to the= problem is not adequate.

If the authors have a re= al problem that they feel has not already been solved, the first step in th= e process ought to be to present that information to the working group, rat= her than to present a solution to the working group with no clear statement= about the problem it solves, and in particular no data about the seriousne= ss of the problem.
<= div dir=3D"ltr">
For what it's worth, which isn't much since th= e chairs haven't issued a call for adoption, I don't think the work= ing group should work on this.
=C2=A0
We analyzed our recursive query log, about 18.6 billion queries from 12/01/2015 to 12/07/2015.
=09 =09

We found about 4.7= Million temporary domains occupy the recursive's cache, which are subd= omain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, Cloudfront, = Greencompute...

Temporary Domain Names/ All Names: 41.7%

Queries for Tem= porary Domain Names/ All Queries: 0.12%


The operational problem is, = subdomain wildcards waste recursive cache capacity. Existing solution to th= e problem is not adequate in recursive operating environment at present, be= cause of low DNSSEC deployment.
=C2=A0

On Tue, Aug = 15, 2017 at 9:41 AM, Vernon Schryver <vjs@rhyolite.com> wrote= :
] From: Lanlan Pan <abbypan@gmail.com>

] Give the choice to operators, time is the best witness, like IP surpassed=
] ATM.

That is backwards.=C2=A0 IP did not surpass ATM, because IP came long befor= e
ATM.=C2=A0 Instead, end-to-end ATM was the last gasp of the end-to-end
circuit switching point of view.=C2=A0 End-to-end ATM was supposed to repla= ce
IP, but instead the new virtual circuits of ATM came far too late and
did not solve the problems that packet switching had already solved.

ATM has not yet died and is still common for some uses.=C2=A0 For example,<= br> ATM=C2=A0 is used as x.25 was used under IP in the early days of IP; many DSL installations use AMT VCs.

A better and more relevant history is that of the SPF RR.=C2=A0 The SPF RR<= br> was supposed to replace the use of the TXT rtype for SPF.=C2=A0 The SPF RR<= br> was widely available in deployed DNS authoritative servers (via BIND).
I think it was in milter modules for sendmail and postfix.=C2=A0 Neverthele= ss,
it died because it came late, was only a modest improvement, and required operators to do something more than they were doing.


Vernon Schryver=C2=A0 =C2=A0 vjs@rhyolite.com

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--f403045c0c463a8fbe0556d7336c--