<div dir="ltr">Hey Dan,<div><br></div><div>Yes, the old Dyn days!</div><div><br></div><div>topQueries works well for an automated way to find the top offending traffic and we also use dnstop which works very nicely for the same thing plus a lot of other functionality to see what's going on with queries.<br></div><div><br></div><div>Salt works very well for updating dnsdist configs and reloading them. We currently run 2 different instances of dnsdist per server because we have multiple backends to different dns platforms. So far we haven't run into any issues with controlling instances individually and we never reload all at the same time in case of any config issues. There is always a test system to update and check validity. </div><div><br></div><div>If you ever want to chat more on this just contact me off list and we can talk some more about it.</div><div><br></div><div>Cheers,</div><div>Jeff</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 2, 2024 at 10:52 AM Dan McCombs <<a href="mailto:dmccombs@digitalocean.com" target="_blank">dmccombs@digitalocean.com</a>> wrote:<br></div><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">Hey Jeff,<div><br></div><div>Thanks for the info, and it's good to hear from you since our days at Dyn together!<br><br>That topQueries call is a good way to quickly find this kind of attack when it accounts for the majority of traffic like we've been seeing.<br><br>We've considered using Salt to manage our DNS infra but lack of time/resources and internal headwinds have stopped us. I assume you've liked it, have you run into any notable issues and how does it handle limiting the number of dnsdist instances in a single DC that get restarted with a configuration change so they don't all restart at once?<br><br>Take care,<br><br>-Dan<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><table width="100%" style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:15px;line-height:22px"><tbody><tr><td width="55px" valign="top" style="padding-right:12px"><br><img src="https://digitaloceanspace.nyc3.digitaloceanspaces.com/do-sig_files/do-email_signature.png" style="width: 50px;"></td><td><div style="color:rgb(34,34,34);font-weight:bold;margin-top:4px"><br>Dan McCombs</div><div style="color:rgb(34,34,34);margin-bottom:12px">Senior Engineer I - DNS</div><div><a href="mailto:dmccombs@digitalocean.com" style="color:rgba(51,51,51,0.75);font-size:14px" target="_blank">dmccombs@digitalocean.com</a></div></td></tr></tbody></table></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 29, 2023 at 4:39 PM Jeffrey Cronstrom <<a href="mailto:jeff.cronstrom@cloudfloordns.com" target="_blank">jeff.cronstrom@cloudfloordns.com</a>> wrote:<br></div><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 dir="auto">Hi Dan, <div dir="auto"><br></div><div dir="auto">We see these types of attacks on a regular basis anywhere from 5 minute bursts to days at a time and have been seeing them for quite some time. We do not have anything that dynamically handles any of this yet but rather update the dnsdist configs on an as needed basis. We simply add a domain name to a list and run a given Salt State (we use SaltStack for config management) across the DNS network and this mitigates quickly against the domain name and helps with any backend impact.</div><div dir="auto"><br></div><div dir="auto">addAction("<a href="http://example.com" target="_blank">example.com</a>.", QPSAction(50)) <br></div><div dir="auto"><br></div><div>On the automated front, we've started to develop a program to run against the dnsdist API so we can evaluate the current QPS and upon a certain deviation of that metric we can look at a domain name that may be getting impacted by a flood of queries and automatically apply a temporary rule. This command would be run remotely against all dnsdist instances. This is only conceptual and not in use but is the start of an outline for a program to help with this type of activity.</div><div><br></div><div dir="auto">disthost = "http://%s:8083/jsonstat?command=stats" % (IPv4)<br></div><div dir="auto"><a href="https://dnsdist.org/guides/webserver.html" target="_blank">https://dnsdist.org/guides/webserver.html</a><br></div><div dir="auto"><br></div><div>From this lookup we can establish the deviation of QPS and a rule can be applied locally via the dnsdist API and also removed after any offending traffic has subsided. The rule would also be dropped upon a restart because it wouldn't be part of the startup configuration of dnsdist.</div><div dir="auto"><br></div>Some local instance calls for evaluation.<br>/usr/bin/dnsdist -e 'topQueries(10,2)' - <a href="http://example.com" target="_blank">example.com</a><br>/usr/bin/dnsdist -e 'topQueries(10,3)' - <a href="http://example.co.uk" target="_blank">example.co.uk</a></div>/usr/bin/dnsdist -e 'showRules()'<br>/usr/bin/dnsdist -e 'addAction("<a href="http://example.com" target="_blank">example.com</a>.", QPSAction(50))'<br>/usr/bin/dnsdist -e 'mvRuleToTop()'<div><br></div><div>One thing to note is the domain getting hit will be affected by limiting their QPS but it will help the backend from further impact.<br><div><br></div><div>This may not be exactly what you are looking for but may help and someone else on this list might have better suggestions however I thought I would share.</div><div><br></div><div>Best Regards,</div><div><br></div><div>Jeff<br><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 29, 2023, 14:11 Dan McCombs via dnsdist <<a href="mailto:dnsdist@mailman.powerdns.com" target="_blank">dnsdist@mailman.powerdns.com</a>> wrote:<br></div><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">Hi all,<br><br>I'm wondering if anyone has suggestions of reasonable ways to handle this type of abusive traffic with dnsdist.<br><br>We've had on and off attacks recently targeting legitimate domains delegated to our authoritative service flooding queries for random subdomains of varying length and characters/words. i.e. <a href="http://12345.example.com" rel="noreferrer" target="_blank">12345.example.com</a>, <a href="http://fred.example.com" rel="noreferrer" target="_blank">fred.example.com</a>, <a href="http://abc178371jd.example.com" rel="noreferrer" target="_blank">abc178371jd.example.com</a>, where <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> is a different domain we're authoritative for each attack.<br><br>The dnsdist nodes can handle the traffic, but breaking cache and going through to our backends is having more of an impact.<div><br></div><div>We have thousands of domains, so it doesn't seem reasonable to apply individual rate limits to them all, but if there is a straight forward way to do something like that I'd be happy to hear it. The source addresses are well known public resolvers that we shouldn't rate limit either.<br><br>I'm wondering if there's any way to detect and apply a rule dynamically to respond to queries for one of these domains without affecting the source IP address entirely, and not require us to manually add a rule for each domain as it occurs.<br><br>Any ideas would be appreciated.<br><br>Take care,<br><br>-Dan<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><table width="100%" style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:15px;line-height:22px"><tbody><tr><td width="55px" valign="top" style="padding-right:12px"><br><img src="https://digitaloceanspace.nyc3.digitaloceanspaces.com/do-sig_files/do-email_signature.png" style="width: 50px;"></td><td><div style="color:rgb(34,34,34);font-weight:bold;margin-top:4px"><br>Dan McCombs</div><div style="color:rgb(34,34,34);margin-bottom:12px">Senior Engineer I - DNS</div><div><a href="mailto:dmccombs@digitalocean.com" style="color:rgba(51,51,51,0.75);font-size:14px" rel="noreferrer" target="_blank">dmccombs@digitalocean.com</a></div></td></tr></tbody></table></div></div></div></div></div>
_______________________________________________<br>
dnsdist mailing list<br>
<a href="mailto:dnsdist@mailman.powerdns.com" rel="noreferrer" target="_blank">dnsdist@mailman.powerdns.com</a><br>
<a href="https://mailman.powerdns.com/mailman/listinfo/dnsdist" rel="noreferrer noreferrer" target="_blank">https://mailman.powerdns.com/mailman/listinfo/dnsdist</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div dir="ltr"><span style="font-size:small">Jeffrey Cronstrom<br><a href="https://www.cloudfloordns.com/" style="color:rgb(17,85,204)" target="_blank">CloudFloorDNS</a>, LLC<br></span><span style="font-size:small">M - </span><span style="font-size:small"><a href="tel:%2B1.978.835.3617" style="color:rgb(17,85,204)" target="_blank">+1.978.835.3617</a><br></span><span style="font-size:small">O - </span><a href="tel:%2B1.781.819.5172" style="color:rgb(17,85,204);font-size:small" target="_blank"><span>+1.781.819.5172</span></a><br></div><div dir="ltr"><br></div><div dir="ltr"><span style="color:rgb(34,34,34);font-family:arial,sans-serif">Schedule a Meeting</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif"><a href="https://calendly.com/jeff-cronstrom" target="_blank">https://calendly.com/jeff-cronstrom</a><br></div></div></div></div></div></div></div></div></div></div></div>