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