<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 21, 2016 at 11:24 AM Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>> wrote:<br>
> Robertz C. wrote:<br>
> ><br>
> > <a href="https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/" rel="noreferrer" target="_blank">https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/</a><br>
> ><br>
> > A nice article. how about your thoughts?<br>
><br>
> that article is significantly wrong-headed, though in a well-meaning way.<br>
><br>
> i wrote several extensive comments on the blog itself, which i won't copy<br>
> here.<br>
<br>
Damian Menscher's comment is helpful:<br>
<a href="https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/#comment-2578422987" rel="noreferrer" target="_blank">https://blog.cloudflare.com/a-deep-dive-into-dns-packet-sizes-why-smaller-packet-sizes-keep-the-internet-safe/#comment-2578422987</a><br>
<br>
I have seen the kind of attack traffic he describes. My authoritative<br>
servers were getting ANY queries from a large number of recursive servers.<br>
Evidently the attackers were using lots of recursive servers as reflection<br>
amplifiers - enough of them that the traffic on my authoritative servers<br>
became a problem. And RRL didn't block the traffic because it is not<br>
designed to do that.<br>
<br>
To mitigate the attack I implemented draft-ietf-dnsop-refuse-any (link<br>
below) which stopped the recursive servers from switching to TCP (reducing<br>
the rec/auth load) and which also made my domains much less useful as<br>
recursive amplifiers.<br>
<br>
I'm grateful to Cloudflare for talking about this problem, because the<br>
discussion about draft-ietf-dnsop-refuse-any meant I knew how to mitigate<br>
the attack without having to invent my own half-arsed blocking rules.<br>
<br>
<a href="https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/03b54c557b19652c4abd8561f572a370b54b096e" rel="noreferrer" target="_blank">https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/03b54c557b19652c4abd8561f572a370b54b096e</a></blockquote><div><br></div><div>Nice. Much respect. </div><div>W</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Tony.<br>
--<br>
f.anthony.n.finch  <<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>>  <a href="http://dotat.at/" rel="noreferrer" target="_blank">http://dotat.at/</a>  -  I xn--zr8h punycode<br>
Northwest Fitzroy: Northeasterly 4 or 5 becoming variable 3 or 4. Moderate.<br>
Fair. Good.<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-jobs mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
</blockquote></div></div>