On 03/16/15 18:07, Yunhong Gu wrote: > > > On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <mich...@brokendns.net > <mailto: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 <mailto: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.
Giving NSEC3PARAM a positive TTL would prevent my headache, but it wouldn't help the victim of the attack, and would probably make it worse for the victim. michael _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop