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

[Michael Sinatra <[e-mail]>]

On 03/16/15 18:07, Yunhong Gu wrote:
> 
> 
> On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 3/16/15 4:15 PM, P Vixie wrote:
>     >
>     >
>     > On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra <[e-mail] <mailto:[e-mail]>> 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