On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <mich...@brokendns.net> wrote:
> On 3/16/15 4:15 PM, P Vixie wrote: > > > > > > On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra < > mich...@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. > Sounds to me this is the root cause of the problem and ANY is the just a scapegoat. > > * 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 > > _______________________________________________ > dns-operations mailing list > dns-operati...@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
