Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

延志伟 <yzw_iplab@163.com> Wed, 20 July 2016 05:34 UTC

Return-Path: <yzw_iplab@163.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 77E8112D0E7 for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 22:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.285
X-Spam-Level:
X-Spam-Status: No, score=-3.285 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=163.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 wtdKItDZpg8Y for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 22:34:11 -0700 (PDT)
Received: from m13-8.163.com (m13-8.163.com [220.181.13.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93C12D0C9 for <dnsop@ietf.org>; Tue, 19 Jul 2016 22:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=5dVJm 5wz1+ZCt4oIVppLkCKL8YZovpRvLOTvD/5yiWw=; b=T+GurOTGIeI0N/6xqxzTs dzg01wn5mBvlxBChuWb+FEtHpCwU7j6w/NVnnfrVbkK0iiI4OXgQA8++FKLkQLSH ZW7yRfshaHetIHLhlqIcpWRhBEmuxDQO45r+uop743GWx/fTtGCd3FMxWKs8GQyE A8zogYMHJ/Yal2bIjtcucc=
Received: from yzw_iplab$163.com ( [31.133.151.189, 10.144.1.72] ) by ajax-webmail-wmsvr8 (Coremail) ; Wed, 20 Jul 2016 13:34:03 +0800 (CST)
X-Originating-IP: [31.133.151.189, 10.144.1.72]
Date: Wed, 20 Jul 2016 13:34:03 +0800
From: 延志伟 <yzw_iplab@163.com>
To: Ralf Weber <dns@fl1ger.de>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160420(83524.8626) Copyright (c) 2002-2016 www.mailtech.cn 163com
In-Reply-To: <236F5488-42D4-4A89-ACAB-B55FD2B5782A@fl1ger.de>
References: <b00ec4.3833.15606420d47.Coremail.yzw_iplab@163.com> <236F5488-42D4-4A89-ACAB-B55FD2B5782A@fl1ger.de>
X-CM-CTRLDATA: po3O2WZvb3Rlcl9odG09MTc4Nzo1Ng==
Content-Type: multipart/alternative; boundary="----=_Part_84837_448102027.1468992843647"
MIME-Version: 1.0
Message-ID: <3f3d0268.51bf.15606cbef7f.Coremail.yzw_iplab@163.com>
X-Coremail-Locale: zh_CN
X-CM-TRANSID: CMGowACnoFpMDY9XoTIFAA--.37902W
X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/xtbBRR+szlO-2+0QsQACsB
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zUHPj0vpZzJC9pcwEZ6pj2mQ20E>
X-Mailman-Approved-At: Tue, 19 Jul 2016 22:43:21 -0700
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jul 2016 05:34:12 -0000

Good morning, Ralf.


At 2016-07-20 13:07:01, "Ralf Weber" <dns@fl1ger.de> wrote:
>Moin!
>
>On 20 Jul 2016, at 5:03, 延志伟 wrote:
>
>> About the DDoS risk, it should not be worried so much because this 
>> scheme is controlled/triggered by the recursive server (with a flag as 
>> NN bit).
>> In other words, the recursive server can get the piggybacked multiple 
>> responses only when it wants and of cource it can disable this model 
>> anytime.
>That's not who DDos work. If attacker would only do what the specs say 
>we wouldn't have any DDos. But an attacker can just create an UDP packet 
>with that bits and a spoofed address and fire it off (or get a botnet to 
>fire it off).

I understand your points, but these risks always be there because DNS response is larger than the request, like DNSSEC. 
How to avoid DNS DDoS is anther problem.
>> Another scenario to illustrate this proposal is under the DANE case:
>> A client wants to visit www.example.com.
>> But this domain name supports DANE can the TLSA record is configured 
>> under the domain name: _443._tcp.www.example.com.
>> The client has to query the two names seperately.
>> Yes, it is just one more TTL, but why not to do the optimization with 
>> a steerable method.
>Again if example.com is popular almost all the time this record will be 
>in the cache already.

Anyway, the cache should get the data fist and then it can cache them.
:-)


>So long

>-Ralf


Zhiwei Yan