Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Daniel Stirnimann <daniel.stirnimann@switch.ch> Wed, 06 March 2019 15:10 UTC

Return-Path: <daniel.stirnimann@switch.ch>
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 E77B112705F for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 07:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 fW4ODiQYOdtm for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 07:10:10 -0800 (PST)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9901275E9 for <dnsop@ietf.org>; Wed, 6 Mar 2019 07:10:09 -0800 (PST)
Received: from mailm212.d.ethz.ch (129.132.139.36) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 6 Mar 2019 16:09:53 +0100
Received: from macdst.switch.ch (130.59.18.77) by mailm212.d.ethz.ch (2001:67c:10ec:5603::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 6 Mar 2019 16:09:48 +0100
To: <dnsop@ietf.org>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com> <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com> <4253851.Zqd2zPpPcC@linux-9daj> <92355508-D5AC-46DC-8FF5-C1C4155601D8@isc.org> <alpine.LRH.2.21.1903042240330.32161@bofh.nohats.ca> <23678.40176.492174.37630@gro.dd.org> <3E7AF476-0989-4FA8-8186-F5AAFC87317A@icann.org> <alpine.LRH.2.21.1903051202360.1124@bofh.nohats.ca> <23679.9798.678631.923122@gro.dd.org> <alpine.DEB.2.20.1903061237440.17454@grey.csi.cam.ac.uk> <3BCC02A3-9F05-4A35-A06E-D69719EB7CB5@hopcount.ca>
From: Daniel Stirnimann <daniel.stirnimann@switch.ch>
Openpgp: preference=signencrypt
Message-ID: <7ab1576c-9d51-513b-64f5-76068cb6a71f@switch.ch>
Date: Wed, 6 Mar 2019 16:09:48 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <3BCC02A3-9F05-4A35-A06E-D69719EB7CB5@hopcount.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.59.18.77]
X-ClientProxiedBy: mailm217.d.ethz.ch (2001:67c:10ec:5603::31) To mailm212.d.ethz.ch (2001:67c:10ec:5603::26)
X-TM-SNTS-SMTP: F396CA90DAFE2AF968089C39885EA366CAE3AE3060A22A4571DE30225FE5F1202000:8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/y2US_dYf0QFovg1PBJuix_nrdYI>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Mar 2019 15:10:14 -0000

On 06.03.19 15:37, Joe Abley wrote:

> if you can find a set of DNS authority servers that silently discards
> a particular kind of query, sending such queries through resolvers
> that are known to support serve-stale might suppress other queries
> and trigger the serve-stale behaviour even though the authority
> servers are not actually unresponsive for them.
I can provide some statistics for this behavior.

There are currently around 2 million delegations in .ch. 568 domain
names are hosted on authoritative name servers where all of them do not
respond to some query types. A little more common is that only some do
not respond to some query types.

I had the feeling that this only facilitates kaminsky style cache
poisoning attacks but your example is indeed another attack vector.

Daniel