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

"Ralf Weber" <dns@fl1ger.de> Wed, 20 July 2016 05:07 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 C39C912DA53 for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 22:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no 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 NpboYiFwLlKC for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 22:07:07 -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 4970612DA47 for <dnsop@ietf.org>; Tue, 19 Jul 2016 22:07:06 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 0D34F5F40647; Wed, 20 Jul 2016 07:07:02 +0200 (CEST)
Received: from [172.20.0.225] (unknown [62.217.47.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 7D54B5F403ED; Wed, 20 Jul 2016 07:07:02 +0200 (CEST)
From: Ralf Weber <dns@fl1ger.de>
To: 延志伟 <yzw_iplab@163.com>
Date: Wed, 20 Jul 2016 07:07:01 +0200
Message-ID: <236F5488-42D4-4A89-ACAB-B55FD2B5782A@fl1ger.de>
In-Reply-To: <b00ec4.3833.15606420d47.Coremail.yzw_iplab@163.com>
References: <b00ec4.3833.15606420d47.Coremail.yzw_iplab@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XunKV_g4JpHoKWMiVTLCxNVTbGI>
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:07:09 -0000

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).

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

So long
-Ralf