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

Hi Ted,

Thanks for your relevant comments, :-)

Ted Lemon <mellon@fugue.com>于2017年8月16日周三 上午1:28写道：

> 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 already
> 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 the
> 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
<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.

>
> 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.  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 required
>> 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
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan