Can Someone Turn Down the Volume?

I run a honeypot cluster comprised of hundreds of open recursive resolvers, deliberately, with every query logged into Elasticsearch: source address, source port, query name, record type, protocol, flags, EDNS parameters, all of it. They exist to observe what the internet sends to an open resolver, and the internet finds them the same way it finds everything else: by scanning the whole address space for port 53.

What I've observed often is reflection traffic. Somebody picks a victim, forges that victim's IP as the source address on a DNS query, and fires it at every address that answers on port 53. The resolver has no way to know the source is a lie, so it sends the answer where it was told to: to the victim, who never asked anything. Do that from enough places at once and the victim drowns in replies to questions they never sent.

One TLD, 3.9 Billion Queries

Here are the top ANY query names across the cluster, by volume, with the number of distinct source addresses that sent each one:

Query name	Queries	Distinct sources
sl.	3,928,056,477	3,570
paypal.com.	90,231,892	2,034
isc.org.	26,083,779	1,882
look.com.	14,068,306	842
uwgb.edu.	10,980,800	866
. (root)	9,913,315	13,092
google.com.	4,389,971	10,963
amazon.aws.	3,145,008	10,909
moba.net.	2,642,015	331
mjyule.top.	1,925,448	14
fibk.com.	1,771,414	374
ap.gov.	404,762	38
diux.mil.	369,288	14

sl. is the Sierra Leone country-code TLD. The queries are not for a domain registered under it like example.sl, they are for .sl itself, the apex of the TLD. Nearly four billion ANY queries, 43 times the next name on the list, and nearly 24 times more than every other name in the table put together.

Why .sl Was Worth Attacking

This is not a new problem, and I want to be clear about what was already known before I started looking.

In February 2025, Meir Kraushar of ISOC-IL posted to the DNS-OARC dns-operations list that .sl was being used as a reflection amplifier, with victims being referred to him for help. His diagnosis of the zone: four DNSSEC keys where two would do, all four of them signing the DNSKEY set, every other record signed twice, no DS in the root, and an ANY response of 5,814 bytes.

A 5,814 byte response to a query of about 30 bytes is an amplification factor near 200. That is an excellent cannon, and it explains the volume.

The trick is picking a question with a big answer. The query itself is tiny, thirty bytes or so. Ask for ANY and a nameserver hands back every record type it holds for that name at once, or find a name stuffed with TXT records and you get all of those too. Thirty bytes out, several thousand bytes back, and the attacker is not the one paying for the return trip. That multiplier is the entire point, and it is why a specific handful of names get used over and over while the rest of the DNS is ignored.

John Kristoff of Dataplane replied that .sl ANY reflections had already been going on for years, and pointed at the nameservers themselves, sitting in OVH AS16276 and Kamatera AS204548, in the hope someone on the list had contacts at either.

That delegation is unchanged today. ns1.neoip.com is 51.195.14.249 in OVH AS16276, and ns2.neoip.com is 45.83.41.38 in Kamatera AS204548, exactly as he described twenty months ago.

Petr Spacek of ISC then made the correction that matters most. The .sl nameservers absolutely do produce that 5,814 byte answer, but they will not hand it to you in a single UDP packet. Ask over UDP and they truncate, setting the TC bit and telling you to come back over TCP, which is what dig quietly did to get the 5,814 byte figure in the first place. TCP is useless for reflection because the three way handshake means you cannot forge your source address and still receive anything. So the zone cannot be the amplifier by itself. Somebody else has to be willing to take that big answer and spray it over UDP anyway, ignoring the buffer size the client advertised.

In other words... OPEN RESOLVERS, which is exactly what my cluster is and why this traffic lands in my logs at all. The attack is not aimed at Sierra Leone, it is aimed through anything on the internet that will answer the query.

Marco Davids of SIDN (the registry that runs the Dutch .nl TLD) tried the contacts listed in IANA's root database and got no response.

Damian Menscher of Google closed the thread out with the only durable answer: chasing individual records, domains, servers or even the DNS protocol itself will not fix anything, because a dozen protocols get abused for UDP amplification the same way. The only thing that works is stopping the spoofed packets at the networks that emit them.

Case closed. The solution: block the spoofers with BCP38. The problem: it didn't fucking work. BCP38 has been the answer since RFC 2827 in May 2000, and the traffic in my logs is proof that a great many networks still do not filter what leaves them.

What .sl Looks Like Now

Here is the same query Kraushar ran, asked directly of the delegated nameserver, with DNSSEC requested and a 4096 byte EDNS buffer advertised, in October 2026:

$ dig +norecurse +notcp +ignore +bufsize=4096 +dnssec ANY sl. @51.195.14.249

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20057
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;sl.                            IN      ANY

SL.                     21600   IN      SOA     ns1.neoip.com.sl. adam.neoip.com. 3583375206 600 900 7200 3600
SL.                     1800    IN      TXT     "Generation Time: 1791687603"
SL.                     1800    IN      NS      ns1.neoip.com.
SL.                     1800    IN      NS      ns2.neoip.com.

;; MSG SIZE  rcvd: 201

201 bytes. Four records. No RRSIGs, no DNSKEYs, nothing. The response is 29 times smaller than the one Kraushar measured. What is left is a single-digit amplification factor, which is not worth building an attack around when there are protocols out there offering three figures.

The zone is not signed at all any more:

$ dig +norecurse +dnssec DNSKEY sl. @51.195.14.249

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44784
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
SL.                     3600    IN      SOA     ns1.neoip.com.sl. adam.neoip.com. 3583375206 600 900 7200 3600

;; MSG SIZE  rcvd: 125

Zero DNSKEY records, answered authoritatively. And the root still publishes no DS for it, which was true in 2025 and remains true:

$ dig +norecurse DS sl. @j.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18097
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Somewhere between February 2025 and now, the four-key double-signing arrangement that made .sl worth 200x to an attacker was taken out and the zone was left unsigned. Nobody announced it. Nobody followed up on the mailing list thread. The vector simply stopped working.

The zone is smaller now, it is fixed, and it is no longer a useful target for an amplification attack. I cannot say exactly when that happened, because every sl. response my cluster has ever stored is already the small unsigned kind. Whoever cleaned it up did so sometime between Kraushar's post and the day my sensors started looking.

And They Are Still Firing

The vector was already dead before my dataset begins, which has a consequence worth stating plainly:

Every single one of those 3,928,056,477 queries was fired at a target that had already stopped amplifying. Not the recent ones. All of them. The entire four billion.

It includes the 1,996,131 queries that arrived in the last 48 hours, still coming in while I write this.

That is a steady twelve queries a second, every second, for two days, aimed at a response of 201 bytes. Not a burst, a baseline. A DDoS vector that does not work anymore is still being sprayed at enormous volume for no result whatsoever, and has been for years.

It Is Not 3,570 Attackers

3,570 distinct source addresses sounds like a botnet. It is not. It is a handful of tools with a spoofing loop, and you can prove that from packet structure alone without needing a single operator to confirm anything.

Those addresses fall into only 460 distinct /24 blocks, and 63 of those blocks hold 3,173 of the addresses. Here is every block where at least 100 of the 256 addresses showed up. The last column is not how long traffic kept coming from the block. It is how long it took for every address in it to appear for the first time:

Prefix	Organization	Addresses seen	.0	.255	Whole block used in
24.3.146.0/24	Comcast, US	128 / 256	no	yes	9 seconds
205.151.65.0/24	Cogeco Connexion, CA	256 / 256	yes	yes	13 seconds
81.6.41.0/24	Init7, CH	256 / 256	yes	yes	13 seconds
73.246.137.0/24	Comcast, US	128 / 256	no	yes	15 seconds
68.224.97.0/24	Cox Communications, US	256 / 256	yes	yes	27 seconds
71.14.142.0/24	Charter, US	256 / 256	yes	yes	29 seconds
24.98.117.0/24	Comcast, US	256 / 256	yes	yes	12 days
174.165.229.0/24	Comcast, US	256 / 256	yes	yes	27 days
98.110.185.0/24	Verizon, US	256 / 256	yes	yes	39 days
72.135.102.0/24	Charter, US	254 / 256	no	yes	39 days
107.149.231.0/24	PEG TECH, US	109 / 256	no	no	12 hours

There are clearly different behaviours in there: six blocks consumed in well under a minute, four worked through slowly across weeks, and one hosting block that was only ever partly used and never touched .0 or .255. The fast six are the interesting ones, and three things settle what they are:

The .0 and .255 addresses are present. In a conventionally subnetted /24 those are the network and broadcast addresses, assigned to no host, and nothing legitimately sources a packet from them. Something is iterating an integer range and converting it to dotted quads. It is not enumerating real machines.

Entire /24 blocks in 9 to 29 seconds. Every address in the range, used once, faster than you can read this section. Residential customers do not coordinate like that.

Two Comcast blocks show exactly the 128 odd-numbered addresses. .1, .3, .5, all the way to .255, and none of the even ones. That is a loop with a step of 2 and it is an implementation artifact, not a network property.

The Source Port Is The Victim List

Amplification honeypots have been used to enumerate DDoS victims since at least AmpPot in 2015, and Millions of Targets Under Attack built a two-year macroscopic census of the DoS ecosystem partly on that data. A 2023 survey of the field, A Data-driven View on Methods to Detect Reflective Amplification DDoS Attacks Using Honeypots, treats the source port as one of four components of an attack flow identifier, and notes that paired source ports are a known attacker fingerprint, with ports 80 and 123 together accounting for more than half of observed NTP attacks.

In a reflection attack the spoofed source address is where the response goes, and the spoofed source port is the port that response lands on. A real DNS client picks a random high port for every query. These do not. They pin one port for an entire run.

Which means every distinct source port in my logs is a target, and the port number tells you what service is being hit:

Source port	Queries	Spoofed addresses	First seen	Target service
80	3,925,195,947	980	2026-03-10	HTTP
1505	1,048,886	4	2026-10-09	active right now
53	385,877	1,885	2026-07-26	DNS
43000	276,545	1	2026-10-10	unknown
31450	101,764	1	2026-05-18	unknown
443	70,451	9	2026-09-06	HTTPS
22	34,964	6	2026-08-27	SSH
25565	23,900	4	2026-09-09	Minecraft
25	20,344	257	2026-10-07	SMTP
24	13,017	256	2026-10-01	unknown
10123	2,022	2	2026-03-10	dead, never returned

99.93% of the entire 3.9 billion carried source port 80.

The same survey concludes that source port is "useful to track a specific pattern belonging to an attack entity, but is otherwise unsuitable as a more generic traffic classifier." On this dataset it is both. Every campaign I can separate out, I separated out by source port.

Look at the port 25 and port 24 rows, each with 256 spoofed addresses. Those are the Init7 and Cogeco /24 sweeps from the table above, and they are fast:

port 25   15,564 queries   256 addresses   2026-10-07 19:43:19 - 19:44:31   (72s)
port 24   13,017 queries   256 addresses   2026-10-01 14:04:24 - 14:05:35   (71s)

Those are the full runs. The /24 table above lists the same two events at 13 seconds each, which is not a contradiction: 13 seconds is how long it took to cycle through all 256 addresses, and the run then kept going for another minute reusing them.

Sit with what those two rows describe. The forged source address is where the answer lands, so a run that forges all 256 addresses of a /24 is a run that sprays the reflected traffic across every host in that subnet at once. Not one server. The whole block, on one port.

That is carpet bombing, and it is deliberate. Most DDoS mitigation triggers on traffic to a single address crossing a threshold. Spread the same volume thinly over 256 addresses and no individual host looks exceptional, while the aggregate still saturates the uplink the subnet sits behind. The attacker is not trying to kill one machine. They are trying to make a network's transit hurt, in a way shaped to slip under per-host detection.

This is also well known and has a literature. That same survey describes carpet bombing as attacks that "target IP prefixes as opposed to a single victim address" by randomising the low bits of the spoofed source, and notes that honeypot platforms have had to change how they group attack flows to cope: one keys on the source prefix rather than the address, another only infers carpet bombing once 16 separate flows hit the same /24. What is worth showing here is simply how blunt it looks from the inside. Not 16 flows into a prefix. All 256 addresses, including the two that cannot exist, inside thirteen seconds.

Six of the blocks in the table were consumed that way in under thirty seconds. The targets were a Swiss ISP, a Canadian cable operator, and residential ranges at Comcast, Cox and Charter. These are not datacenter subnets full of hardened servers. They are people's home internet connections.

Every address in a residential /24 used as a forged source, on the SMTP port, inside about a minute, roughly 60 reflected responses per address from my resolver alone. The port 25 row totals slightly more than the sweep because a separate single-address burst arrived on the same port on the morning of the snapshot.

Port 25565 is the Minecraft default. Four addresses, 23,900 queries over a month. That is small, and on its own it would not take anything down, but my resolver is one of an unknown number being used the same way, and the aggregate is what lands on the target.

This is a view you only get from inside a reflector. The attacker's own target list, read off the packets they spoofed, service by service.

One Morning In April

The single largest event in the whole dataset ran for six and a half hours on the morning of April 30th. Five forged source addresses, two US hosting networks, one query name, handed off to each other in sequence as the morning went on:

Spoofed source	ASN / Organization	Queries	Window
107.173.11.14	AS36352 ColoCrossing	2,402,272,645	05:30:58 to 09:11:20
107.178.115.246	AS53755 IOFlood	910,962,698	03:05:31 to 04:33:48
104.161.32.234	AS53755 IOFlood	410,182,873	04:49:41 to 05:30:37
107.173.11.13	AS36352 ColoCrossing	96,114,926	09:19:32 to 09:29:12
23.95.186.30	AS36352 ColoCrossing	77,288,830	09:11:58 to 09:19:02

Every one of them on source port 80, so every reflected answer landed on a web server. The totals:

Metric	Value
Queries	3,896,825,340
Active minutes	372
Median rate	179,635 qps
Peak minute	246,145 qps
EDNS	none

A sustained quarter of a million queries a second, at one honeypot cluster, for six and a half hours.

And note the last line. Not one of those 3,896,825,340 queries carried EDNS at all. Plain DNS over UDP caps a response at 512 bytes. EDNS exists to lift that: the client advertises how large a UDP response it is willing to accept, in a 16 bit field, so it can ask for up to 65,535 bytes. That one field is the difference between a 512 byte reply and the 5,814 byte one that made .sl worth attacking in the first place, and this flood did not set it. Even if the zone had still been signed, every single one of those four billion queries would have pulled back 512 bytes at most.

That is specific to this event, though. One flood this big skews any average it is included in, so the EDNS numbers have to be read in three parts:

Window	Queries	Carry EDNS
Whole dataset	3,928,056,477	0.05%
Excluding April 30th	31,231,137	6.6%
Last 48 hours	1,996,131	87.2%

The April flood was the badly built one. The traffic arriving right now is not.

Two Things I Noticed In The Zone

While verifying all this I ended up reading the .sl zone more carefully than I intended. Two details are worth recording.

The SOA serial is twice the Unix epoch. Look at the ANY response again:

SL.  21600  IN  SOA  ns1.neoip.com.sl. adam.neoip.com. 3583375206 ...
SL.  1800   IN  TXT  "Generation Time: 1791687603"

3583375206 / 2 = 1791687603

Exactly. The zone publishes its own generation timestamp in a TXT record, and the serial is that timestamp doubled. It advances by 2 every second, and it is already at 83.4% of the 32 bit ceiling of 4,294,967,295.

Here is the nice part. A serial that simply tracked the clock would be an unsigned 32 bit counter holding a Unix timestamp, and it would not run out until 2106-02-07. Doubling it halves the headroom, so this one runs out when the epoch reaches 2,147,483,647, which is 2038-01-19 03:14:07 UTC. That is the Y2038 moment exactly, the one that comes from signed 32 bit time. The multiplication by two cancels out the sign bit and arrives at the same second from an entirely different direction.

It is not a recent change either. A response captured on 19 February 2026 carries serial 3542972419 against a generation time of 1771486209. The same relationship, a second out, eight months earlier.

The SOA MNAME does not exist. The primary server field says ns1.neoip.com.sl., with the zone origin appended to what should have been ns1.neoip.com. That is a missing trailing dot in a zone file, the oldest mistake in DNS. The resulting name is NXDOMAIN. What makes it interesting is that the generator does it to every zone it produces:

sl.        ns1.neoip.com.sl.      adam.neoip.com. 3583375206 ...
com.sl.    ns1.neoip.com.com.sl.  adam.neoip.com. 3583375206 ...
org.sl.    ns1.neoip.com.org.sl.  adam.neoip.com. 3583375207 ...
gov.sl.    ns1.neoip.com.gov.sl.  adam.neoip.com. 3583375207 ...
edu.sl.    ns1.neoip.com.edu.sl.  adam.neoip.com. 3583375206 ...
net.sl.    ns1.neoip.com.net.sl.  adam.neoip.com. 3583375206 ...

ns1.neoip.com.com.sl. is a particularly good one. Note also that all six zones share essentially the same serial, so whatever generates them regenerates the entire TLD in one pass. The RNAME sitting right beside it, adam.neoip.com., has its trailing dot and comes out correct in all six, so the missing dot is in whatever template produces the MNAME field rather than in any one zone.

Everyone Else Sees It Too

After writing all of the above I went looking for anyone else who had logged this, and found that Johannes Ullrich at the SANS Internet Storm Center published it two and a half years before the OARC thread. His diary entry of 10 August 2022 lists the queries then arriving at his own rate-limited open-resolver honeypot:

Two things in there. The first is simply ANY? sl. sitting in the list, which independently confirms the abuse and brackets its age. His earlier census of March 2020 ran the same exercise and sl is not in it, the top names then being access-board.gov and the root hints. So ANY sl. became a going concern somewhere between March 2020 and August 2022, which fits Kristoff's "going on for years" in 2025 and predates my own data by four years.

The second is that he arrived at this article's conclusion in 2022, in better words than mine:

"But the systems they are hitting with these persistent attacks are not even acting as DNS servers anymore (and haven't been open reflectors for years). All they do with their queries is pollute the internet without effect, like throwing a candy wrapper in a stream with the candy still in it."

Worth being precise about the difference, because it is not the same observation. Ullrich was watching attackers fire at reflectors that had stopped reflecting. I am watching them fire at an amplifiable name that stopped amplifying. Different half of the same stale list, four years apart, and in both cases nobody on the sending side noticed.

Dataplane.org publishes the type and name pairs its sensors observe in unsolicited DNS queries. ANY sl is on that list today, and so is most of the table I opened with: paypal.com, isc.org, look.com, uwgb.edu, moba.net, fibk.com, ap.gov, diux.mil. Their list runs to 112 ANY names, 58 of them .gov, plus the root itself.

That matters because it means this is not a quirk of my cluster's address space. Independent sensors, on different networks, run by different people, are seeing the same global target list. Kristoff mentioned in that same 2025 thread that the number of distinct abused name and type pairs is surprisingly small. It is the same few hundred names, sprayed at everything that answers, for years at a time.

Noise That Does Nothing

Step back from the mechanics and look at what this traffic actually accomplishes.

It extracts a 201 byte answer. The zone it targets has been unsigned for over a year. Every query in this dataset was fired after the thing it was aiming at stopped working. The campaign produces, as far as I can measure, nothing.

And the current tooling is not incompetent, which is the part that makes it worse. Of the queries that arrived in the last 48 hours, 87.2% carry EDNS advertising a 4096 byte buffer with the DNSSEC OK bit set. That is precisely, exactly the right way to ask .sl for the 5,814 byte DNSSEC-signed answer Kraushar measured in 2025. Every campaign currently running does it, on ports 1505, 43000, 80, 6672, 53, 30002, 443 and 22:

port 1505    1,048,886 queries    913,677 with EDNS 4096 + DO
port 43000     276,545 queries    239,393 with EDNS 4096 + DO
port 80        209,688 queries    180,868 with EDNS 4096 + DO
port 6672       61,321 queries     52,628 with EDNS 4096 + DO
port 53         47,316 queries     47,316 with EDNS 4096 + DO

These are not broken tools firing blind. They are correctly configured to exploit the exact vector that was reported, and they are getting 201 bytes for it, every single time, and they have been getting 201 bytes for it for as long as I have been able to measure. Nothing anywhere in that chain is checking the size of what comes back.

And yet it is not slowing down. It is not a campaign with a beginning and an end. It is a fixture, a persistent feature of the background radiation of the internet, running at a dozen queries a second on a quiet day and a quarter of a million per second on a bad one, aimed at a target that has been inert since before I started watching. Somewhere there are machines, and somebody is paying for them, doing this continuously, forever, to no effect.

There is a boring explanation and I think it is probably the right one, and as the section below shows I am not the first to land on it: this is abandoned automation. Someone built a booter or a stress-testing service years ago, pointed it at a list of amplifiers that included .sl, and the list was never revalidated. The vector died and the machinery did not notice because nothing in the machinery was ever built to check. It keeps billing customers for attacks that no longer amplify.

But I want to be honest that I cannot prove that, and the alternative is uncomfortable. Nobody involved behaves as though they are measuring results. Not the operators sending it, not the networks letting forged packets out of their borders, not whoever is paying. A system that large, that persistent, and that pointless is at minimum strange, and strange internet traffic that nobody can explain is a category I have run into before.

Last March I wrote up the mystery of asjo.org: tens of millions of ANY queries for a Danish man's personal blog, from DoD address space, residential ISPs and cloud providers across a dozen countries, running for years, with a response too small to be worth amplifying and no explanation from anyone: not the domain's owner, not Dataplane.org, not the operators whose address space it came from.

I want to be careful here, because the two are not the same and I have no evidence they are connected. The signatures differ in a way that matters: the big asjo.org sources randomise their source port across the full ephemeral range, while every significant .sl campaign pins one port for an entire run. Different tools, almost certainly different people.

What they share is the shape of the question. Enormous, sustained, globally distributed DNS traffic, aimed at something that gives the sender nothing, continuing for years after any rational operator would have stopped. In both cases the honest answer to "why is this still happening" is that I do not know, and neither does anyone else I have asked.

With .sl I can at least prove the how: forged sources, whole blocks at a time, read straight off the packets. The why is the same shrug as before.

One More For The Pile

So that is another one for the collection. Four billion queries a year arriving at my resolvers for a name that gives the sender 201 bytes, fired from forged addresses belonging to people who have no idea their IP is on somebody's list, at a vector that stopped working before any of it was sent.

I like these because they are completely visible and completely unexplained at the same time. Every packet is right there in the logs. The source addresses, the pinned ports, the carpet bombed subnets, the exact second each block got swept. None of it is hidden. And it still does not add up to a reason.

Go and look at what is hitting your own nameservers sometime. The volume is not the interesting part. The interesting part is how much of it has no purpose at all, and how long it has been going on without anyone on the sending side noticing or caring.

None of this changes my opinion that DNS is NOISY AS FUCK.

Update

After this went up, a friend reached out and pointed me at this, in Phenomite's AMP-Research repository on GitHub, a public collection of amplification research and ready-to-run reflection scripts:

/* using TLD "sl" at the moment */
static const char PAYLOAD[] =
    "\x45\x67\x01\x00\x00\x01\x00\x00\x00\x00\x00\x01\x02\x73\x6c\x00\x00\xff"
    "\x00\x01\x00\x00\x29\xff\xff\x00\x00\x00\x00\x00\x00";
static unsigned int DPORT = 53;

That is a ready-made ANY sl. reflection payload, sitting in a public repository with a comment that says the quiet part out loud. It was added on 26 July 2020 as part of the commit that put all of the amplification scripts in the repository, and that date lands right inside the window from earlier: sl was not in Ullrich's March 2020 census, and it was in his August 2022 one.

I think this may be what started it all. Maybe. A copy-pasteable C file with .sl baked in, in a well known repository that has been forked dozens of times, is exactly the kind of seed that ends up in a booter's amplifier list and never gets taken back out.

I want to be honest about the gaps, though. The bytes in that payload are not the bytes I am logging. Decoded, it is an ANY query for sl. with an EDNS record advertising a 65,535 byte buffer and the DNSSEC OK bit clear. The four billion query flood carried no EDNS at all, and the campaigns running now advertise 4096 bytes with DNSSEC OK set. So this exact file is not what is hitting my resolvers.

Reach Out

If you run a resolver and want to compare notes on reflection traffic, or you want the source port breakdown for your own address space, reach out at acid.vegas@acid.vegas, find me on IRC at irc.supernets.org, join the Zulip, or hit me up on Twitter at @acidvegas4real.

---

Sources & References:

• Sierra Leone (.sl) TLD - Meir Kraushar, DNS-OARC dns-operations, February 2025

• full thread - DNS-OARC archive, February 2025

• DNS Type/Name Report - Dataplane.org

• And Here They Come Again: DNS Reflection Attacks - Johannes Ullrich, SANS Internet Storm Center, August 2022

• A Quick Summary of Current Reflective DNS DDoS Attacks - Johannes Ullrich, SANS Internet Storm Center, March 2020

• AmpPot: Monitoring and Defending Against Amplification DDoS Attacks - Kramer, Krupp, Makita, Nishizoe, Koide, Yoshioka, Rossow, RAID 2015

• Millions of Targets Under Attack: a Macroscopic Characterization of the DoS Ecosystem - Jonker, King, Krupp, Rossow, Sperotto, Dainotti, IMC 2017

• SoK: A Data-driven View on Methods to Detect Reflective Amplification DDoS Attacks Using Honeypots - Nawrocki, Kristoff, Hiesgen, Kanich, Schmidt, Wahlisch, IEEE Euro S&P 2023

• Delegation Record for .SL - IANA

• DNS Flag Day 2020 - on UDP payload sizes and fragmentation

• RFC 2827 / BCP 38 - Network Ingress Filtering

• RFC 8482 - Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY