<div dir="ltr"><div dir="ltr">On Sun, Feb 23, 2025 at 4:38 AM Meir Kraushar via dns-operations <<a href="mailto:dns-operations@dns-oarc.net">dns-operations@dns-oarc.net</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">The .sl ccTLD (Sierra Leone) is being used as an amplifier for reflection attacks.</div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)"></div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">It looks like the domain is horribly misconfigured:</div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)"><br></div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">As a result,</div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">The reply size of "dig sl any" is 5814 (!)</div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">Again, this is being used as an amplifier for reflection attacks (victims referred to us for help).</div><div style="font-family:"arial black",sans-serif;color:rgb(7,55,99)">If anyone knows someone there who can fix this?</div></div></blockquote><div><br></div><div><div id="gmail-:4342" class="gmail-Am gmail-aiL gmail-aO9 gmail-Al editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label="Message Body" role="textbox" aria-multiline="true" tabindex="1" style="direction:ltr;min-height:85px" aria-controls=":46j8" aria-expanded="false">Focusing on specific records, domains, DNS servers, or even the DNS protocol itself will not solve your problem.  There are a dozen different protocols which are abused for UDP amplification.<div><br></div><div>The only viable solution, as explained in my 2019 NANOG talk "Practical Solutions for Amplification Attacks", is to stop the spoofed packets at the source networks that emit them.  Spoofing is fairly straightforward to trace, and several people in the operational community are doing it, but it's often challenging to explain to network engineers why they should care about outbound abuse... especially in cases where their companies are profiting from that abuse.</div><div><br></div><div>So, if you want to solve this, push hard on your network team to learn to trace spoofing.  Feel free to contact me for tips (though unless your network has a global presence you probably need to ask your upstream to do it).</div><div><br></div><div>Damian</div><div>-- </div><div>Damian Menscher :: Security Reliability Engineer :: Google :: AS15169</div></div></div></div></div>