IETF Logo Mail Archive

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

Dick Franks <rwfranks@acm.org> Thu, 01 October 2015 11:14 UTC

Return-Path: <rwfranks@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234E51A1BF8 for <dnsop@ietfa.amsl.com>; Thu, 1 Oct 2015 04:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 BsXPsjRtDpfJ for <dnsop@ietfa.amsl.com>; Thu, 1 Oct 2015 04:14:15 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 EA3551A1BC9 for <dnsop@ietf.org>; Thu, 1 Oct 2015 04:14:14 -0700 (PDT)
Received: by igcpb10 with SMTP id pb10so15328796igc.1 for <dnsop@ietf.org>; Thu, 01 Oct 2015 04:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jEcDlVn+ufXPLtrdurh1bCyD2d+WvE87p9s9Ev0EbLA=; b=i3uDQvEisS1vWr8Eh2PcbOrnygDfrIc9O2xgNZc/+jnIPCLs6lvK8tf/efRPnJwoNu Gjz/brluXDe4h5Zkb/Z14f/COBePtck7zNZH+SNBiJpLV5CbxEOJfhpP1WwoLMrl4ImB p/ove8xEiOtza31iPnkTMdcFQBw13O8kBc9P0pY01muDM1sa/HwwEdnoW9zd7vxxlLjX BwYpNWDIncT9YTbUoHmUFGq/4nbgEb87EjmwE+kk++ZQ8UWxX67YJKw7/3bg9sxoQSWg dQQwvXanW9qckzeN+nYpf4QvU3w+divvwXkfZOg2Pv1EDydX8NjDO5Ljf6ebDufoZ2GW GvQA==
X-Received: by 10.50.107.104 with SMTP id hb8mr2424271igb.1.1443698054368; Thu, 01 Oct 2015 04:14:14 -0700 (PDT)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 10.64.54.194 with HTTP; Thu, 1 Oct 2015 04:13:34 -0700 (PDT)
In-Reply-To: <20151001101241.08ff8702@casual>
References: <20150930190405.17300.40441.idtracker@ietfa.amsl.com> <20151001025833.GA51655@isc.org> <0F438B6C-4797-4250-ABCA-4C5AE1D5F232@hopcount.ca> <20151001050850.GA51763@isc.org> <2EB63978-61F4-4833-8433-FDEE77CD4D65@hopcount.ca> <20151001101241.08ff8702@casual>
From: Dick Franks <rwfranks@acm.org>
Date: Thu, 01 Oct 2015 12:13:34 +0100
X-Google-Sender-Auth: vstVECJhwX5g0jJiBwpVNyCd8Ak
Message-ID: <CAKW6Ri7dDB8pqrYiaBA6dw5qN=WCGVu8NNF4AgCXVn82VgT9wA@mail.gmail.com>
To: Shane Kerr <shane@time-travellers.org>
Content-Type: multipart/alternative; boundary="047d7b10ca47b1952405210925ba"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FxX8CoUIR6ogk1ovJPxcTU0U4_M>
Cc: dnsop <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>
Subject: Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 01 Oct 2015 11:14:16 -0000

Dick Franks
________________________


On 1 October 2015 at 11:12, Shane Kerr <shane@time-travellers.org> wrote:

>
> In the case where people just want to reduce the damage of ANY queries
> in reflection attacks, I quite like the PowerDNS option of forcing ANY
> queries to TCP via truncation. I'm not sure if this has been documented
> in any RFC, but if not then perhaps it bears mentioning too?
>

That rests on two assumptions:

1)  that damage limitation from reflection attacks is the primary concern
here, which appears no longer to be the case.

2) that there is some plausible reason for doing ANY queries, in which case
it would be interesting to know what that might be.

v2.23.0 | Report a Bug | By Email