Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

[Shane Kerr <[e-mail]>]

Joe,

On Fri, 16 Oct 2015 13:58:00 -0400
"Joe Abley" <[e-mail]> 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