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

Mukund Sivaraman <muks@mukund.org> Fri, 26 June 2020 12:23 UTC

Return-Path: <muks@mukund.org>
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 CB1963A12A8 for <dnsop@ietfa.amsl.com>; Fri, 26 Jun 2020 05:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org
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 RO8YKKfgM9Kn for <dnsop@ietfa.amsl.com>; Fri, 26 Jun 2020 05:23:49 -0700 (PDT)
Received: from jupiter.mukund.org (jupiter.mukund.org [46.4.226.158]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C693A12A7 for <dnsop@ietf.org>; Fri, 26 Jun 2020 05:23:49 -0700 (PDT)
Date: Fri, 26 Jun 2020 17:53:42 +0530
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1593174227; bh=lkcb1Z6w39b/EL1vnW2UkxisRNAQTEiptRPWmGd9CrQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kEVa2HzM0tgZx73R49aJ0TqubBXchO0yI4QCtjHIC8r8documGb+J6dBGjRmUd8+u ewxs269Fz0bvlyAj1C9o2MWk0AwdRy5sj5OJigiwO8ipyIG+MK+Ra3pKSQce+DgAcb pG3d1WR0qG9rXDGGTjCvdMU1FYybtlfOWXuLlbRU=
From: Mukund Sivaraman <muks@mukund.org>
To: Robert Edmonds <edmonds@mycre.ws>
Cc: dnsop@ietf.org, Cricket Liu <cricket@infobox.com>
Message-ID: <20200626122342.GB12168@jurassic.vpn.mukund.org>
References: <159310275958.28219.2228183649424027878@ietfa.amsl.com> <20200625165049.GA22173@jurassic.vpn.mukund.org> <20200625200725.GA1081237@mycre.ws>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE"
Content-Disposition: inline
In-Reply-To: <20200625200725.GA1081237@mycre.ws>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vXwHLhyps6t3j97UTC6yKif66lU>
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: Fri, 26 Jun 2020 12:23:53 -0000

Hi Robert

On Thu, Jun 25, 2020 at 04:07:25PM -0400, Robert Edmonds wrote:
> 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.

I've been familiar with de-duplication in fctx_match() in BIND (and only
what was the obvious benefit, i.e., just de-duplication of work). I was
not aware of VU#457875; thank you for pointing to it.

The draft describes a query pattern problem. De-duplication of queries
is one mitigation that helps upstream NS query spikes. The spikes on the
resolver side are also a nuisance, and they can be smoothed.  It is also
not just one herd - with the popularity of apps, there are several
address queries that happen for names that humans don't normally observe
or enter anywhere, to do with analytics, image webservers, etc. These
are high frequency (TTLs of 60s and under). So the resolver gets hit
again and again by different groups of clients in spikes, whereas they
can be a smoother query curve.

		Mukund