Mukund Sivaraman wrote:
> On Thu, Jun 25, 2020 at 09:32:39AM -0700, [email protected] 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
