Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt

Robert Edmonds <edmonds@mycre.ws> Thu, 25 June 2020 20:07 UTC

Return-Path: <edmonds@mycre.ws>
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 819603A0FE8 for <dnsop@ietfa.amsl.com>; Thu, 25 Jun 2020 13:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 SIPRwD0IT3vc for <dnsop@ietfa.amsl.com>; Thu, 25 Jun 2020 13:07:28 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA71D3A0F56 for <dnsop@ietf.org>; Thu, 25 Jun 2020 13:07:28 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id D5A3812C9F25; Thu, 25 Jun 2020 16:07:25 -0400 (EDT)
Date: Thu, 25 Jun 2020 16:07:25 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: Mukund Sivaraman <muks@mukund.org>
Cc: dnsop@ietf.org, Cricket Liu <cricket@infobox.com>
Message-ID: <20200625200725.GA1081237@mycre.ws>
References: <159310275958.28219.2228183649424027878@ietfa.amsl.com> <20200625165049.GA22173@jurassic.vpn.mukund.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200625165049.GA22173@jurassic.vpn.mukund.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K0lvjMPGcn153yjkS4Eeoks0vaI>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.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: Thu, 25 Jun 2020 20:07:31 -0000

Mukund Sivaraman wrote:
> On Thu, Jun 25, 2020 at 09:32:39AM -0700, internet-drafts@ietf.org wrote:
> > 
> > A new version of I-D, draft-muks-dnsop-dns-thundering-herd-00.txt
> > has been successfully submitted by Mukund Sivaraman and posted to the
> > IETF repository.
> > 
> > Name:		draft-muks-dnsop-dns-thundering-herd
> > Revision:	00
> > Title:		The DNS thundering herd problem
> > Document date:	2020-06-25
> > Group:		Individual Submission
> > Pages:		6
> > URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-thundering-herd-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-thundering-herd/
> > Htmlized:       https://tools.ietf.org/html/draft-muks-dnsop-dns-thundering-herd-00
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-thundering-herd
> > 
> > 
> > Abstract:
> >    This document describes an observed regular pattern of spikes in
> >    queries that affects caching resolvers, and recommends software
> >    mitigations for it.
> 
> For whoever is interested, this is a description of a pattern of queries
> noticed at busy public resolvers that has led to issues in at least 4
> different sites in the last 2 months.

This seems like a description of a resolver implementation vulnerable to
the infamous VU#457875. Perhaps an update to the standards track RFC
5452 ("Measures for Making DNS More Resilient against Forged Answers")
would be more appropriate than a new document? That document mentions
the security problem caused by having multiple outstanding queries for
the same question but doesn't clearly state a requirement to
de-duplicate, perhaps because that mitigation was already very common in
resolver implementations at the time the document was published.

-- 
Robert Edmonds