Joe, On Fri, 16 Oct 2015 13:58:00 -0400 "Joe Abley" <jab...@hopcount.ca> wrote:
> On 16 Oct 2015, at 13:15, Paul Hoffman wrote: > > > On 16 Oct 2015, at 10:07, Darcy Kevin (FCA) wrote: > > > >> Let's see, millions of full-service resolvers, times the packet-count > >> differential between UDP and TCP, times the average reload/restart > >> frequency of those full-service resolvers per day/week/month. Can't a > >> case be made from sheer volume? > > > > The root operators have shown no concern about legitimate resolvers > > asking a lot more queries. Given that using TCP for priming helps > > mitigate an injection attack, > > Have we characterised this attack at all? Seems like quite an easy attack at first blush. One could send a constant stream of priming answers to resolvers since they would get made once a day. While the chance of poisoning any one resolver with such a response is low, the impact is catastrophic to a non-validating resolver, as an attacker basically owns your view of the Internet at that point. For resolvers that do validate, the only issue is information leakage that a random party can see all of your root queries (or possibly a DoS). > We're talking principally about a risk to resolvers that prime but don't > validate, right? This draft also says that you MUST NOT set the DO bit on priming queries, so any resolver following this draft isn't validating. While a resolver could validate the NS RRSET, as you know the ROOT-SERVERS.NET domain is not signed, so the A and AAAA records (what you really care about) cannot be validated. I know there is discussion about signing the root servers somehow, so perhaps a resolver that cares could someday validate the priming query... but we should probably remove the MUST NOT text around the DO bit then, perhaps replacing it with a SHOULD recommending validation. Cheers, -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
