<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 23, 2015 at 9:07 PM, Roland Dobbins <span dir="ltr"><<a href="mailto:rdobbins@arbor.net" target="_blank">rdobbins@arbor.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 24 Dec 2015, at 8:26, Robert Edmonds wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
spoofed traffic from compromised "dedicated servers" sitting in data centers?<br>
</blockquote>
<br></span>
This is by far the most significant set of attack initiators, IMHO.</blockquote><div><br></div><div>Another one is customer owned open resolvers. No surprise there, but a large number of these devices go on to forward the queries back into the ISP's DNS servers. It defeats the receiving ISP's BCP38 implementation, and the result is the ISP's DNS servers participating in attacks in a manner similar to the protections not being in place. As if it weren't already hard to objectively measure how well an ISP implements it.</div><div><br></div><div>It's useless prattling on my part, but it's interesting to me because the lack of BCP38 on the transmitting side ends up being "laundered" by the receiving party. Port 53 filters (similar to port 25 filters) becoming an industry standard for residential customers is another part of the solution, but it gets sticky because you then break anything customer owned that assumes it needs to source all outbound queries on port 53.</div><div><br></div></div></div></div>