Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael Sinatra writes:
> On 3/16/15 4:15 PM, P Vixie wrote:
> > 
> > 
> > On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra <michael@brokendns.
> net> wrote:
> >>
> >>
> >> On 03/16/15 07:23, bert hubert wrote:
> >>
> >>> Separately, I fail to see why we actually need to outlaw ANY queries
> >> when we
> >>> can happily TC=1 them. 
> >>
> >> If the public recursives also support TC=1 on all ANY queries, then
> >> this
> >> works.  If not, the issue arises where just-below-the-radar attacks are
> >> using many public recursives, in which case you're not stopping much.
> > 
> > Michael, what attacks do you think we can stop by limiting ANY? Paul
> 
> The attack that I have had to grapple with is this:
> 
> * Someone sets up a bot to query public recursives (google, opendns,
> level3, etc.) for a particular domain whose ANY response is large.
> (This _usually_ means DNSSEC-signed.)
> 
> * The query from each <client,domain,qtype> tuple is just barely slow
> enough not to trigger rate limiting from the public recursive service.
> 
> * The backend of the public recursive service queries my authoritatives
> for some of the involved domains.  Suppose the response is just under
> the usual typical default EDNS0 buffer size of 4096.
> 
> * These domains are DNSSEC-signed with NSEC3.  Many tools set the TTL of
> NSEC3PARAM to 0 when signing zones with NSEC3.  The NSEC3PARAM RR is
> part of the ANY response.
> 
> * The public recursive servers use an implementation that clears all
> records from the cache when the TTL of one record expires, so the next
> time the recursive server gets an ANY query, it must re-query the
> authoritative server.
> 
> In this situation, if I set TC=1 for all ANY queries on my authoritative
> server, but the public recursives don't, then the victim still gets hit
> with a pretty big amplification attack, and my authoritative servers get
> hammered with TCP queries.  It's annoying for me--not insurmountable,
> but annoying, as the thousands of simultaneous TCP connections require
> some tuning to manage reasonably.  But for the victim?  Who knows--I
> can't see who the victim is in this case.  The more I tune my servers,
> the more data gets likely thrown at the victim.
> 
> I have seen this in the wild, even where the response is bigger than
> 4096, so the TC bit should be set all around.  Note also that if my
> response is bigger than 4096, I'll send an empty response back with TC=1
> (I am using BIND-latest).  I have seen some recursive implementations (e.g.
> unbound) that will dutifully send the victim everything right up to the
> next RRset that would push it over 4K and set TC=1 for good measure.  So
> the victim still gets a ~4000-byte UDP response, even with TC set.
> 
> So my point is that if we're going to specify TC=1 for ANY queries, it
> has to be mandatory, and all implementations have to handle it the same:
> Send an empty NOERROR and set TC=1.  If I am the only one setting TC=1,
> it won't doing any good for the attack described above, even if my
> domains are the ones being used in the attack.
> 
> The other option is to allow the authoritative servers to control what
> gets set out in response to QTYPE=ANY.  But I see devils in the details,
> just as with NOTIMP and other proposals.
> 
> michael
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

Lets get DNS cookies finalised so that TC=1 isn't needed for repeat
legitimate clients.  There is a open question about whether the
error field is needed or not and I'm of the opinion that it isn't
needed.

TC=1 for amplification suppression should be triggered by response
size and whether you are a known repeat client or not rather than
{meta} query type.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]