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

dagon <> Thu, 25 June 2020 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDF1C3A0FE1 for <>; Thu, 25 Jun 2020 12:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDEIvmWj4l6W for <>; Thu, 25 Jun 2020 12:14:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55F063A0FD4 for <>; Thu, 25 Jun 2020 12:14:51 -0700 (PDT)
Received: by (Postfix, from userid 1000) id 7954F19F03B; Thu, 25 Jun 2020 19:14:51 +0000 (UTC)
Date: Thu, 25 Jun 2020 19:14:51 +0000
From: dagon <>
To: Mukund Sivaraman <>
Cc:, Cricket Liu <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-thundering-herd-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2020 19:14:55 -0000

On Thu, Jun 25, 2020 at 10:20:49PM +0530, Mukund Sivaraman wrote:

> 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.
> The current revision is a work in progress. We are still developing some
> mitigations for NIOS, and some more introductory text also has to be
> added.

This might be another mitigation:

3) "EFMB Caching: Endless Forms Most Beautiful Caching" [0]

    Since DNS messages are often disposed of in tens of ms, and
    authorities express TTL in whole second increments, recursive
    pools might adjust the 'smaller TTLs' (perhaps defined as <5 min)
    to any prime number within, say, +/-10% or more of the answer TTL.
    So a 60 second TTL become perhaps 53, 59, 61, 67, or 71 etc.

    Such adjustment is picked uniquely (perhaps using L2 internals or
    UUIDs) by nodes in a recursive farm.  Upon expiration, the herd of
    expired recursives forms an in-order refresh to the authority,
    spaced by seconds or more.  The software changes for this behavior
    appear minimal, as it slightly adjusts a TTL just prior to
    caching, with reference to some UUID, MAC, etc.

    This avoids the need to share cache additions among a recursive
    pool---an expensive and complex task that amplifies mass cache
    ejection attacks cause by, e.g., Facebook's session-specific
    dynamic domains.

    Using your "thundering herd" metaphor, this is like the natural
    selection of prime numbers in insect swarming populations (e.g.,
    13-year cicadas are common, since the 2- 4- and 6- year cicada
    populations coincided with periodic predator increases, and were
    not selected over generations.  (Cf. ).

This is a very interesting problem, so thanks for addressing this,
even if this idea doesn't prove useful.

[0] Darwin: "whilst this planet has gone cycling on according to the
fixed law of gravity, from so simple a beginning endless forms most
beautiful and most wonderful have been, and are being, evolved."  So
too has DNS followed seemingly fixed basic laws, and yet changed
endlessly to address complex problems, real or perceived.

David Dagon
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717