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:

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:

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:

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:

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

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:

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

You've heard it a thousand times: we've run out of IPv4 addresses. ARIN, RIPE, APNIC — every Regional Internet Registry (RIR) will tell you their free pool is depleted. And technically, that's true. The RIRs have no more fresh allocations to hand out. But the addresses didn't disappear. They got hoarded.

What actually happened is that IPv4 space became digital real estate. Companies, speculators, and holding entities scooped up massive blocks — some dating back to the earliest days of the internet when /8 allocations were handed out like candy — and now they sit on them, sub-leasing ranges to anyone willing to pay. The "exhaustion" isn't a technical crisis. It's a landlord problem. The addresses exist. They're just behind a paywall now, controlled by middlemen who've turned a public resource into a rental market.

What is IP Leasing?

Normally, if you need IP address space, you go to a Regional Internet Registry. There's a process. You justify your need, you provide documentation, your organization is tied to the allocation through WHOIS records, and there are policies governing how those addresses are used. The RIR system was built around accountability — every block is traceable to a responsible party.

IP leasing is the alternative that skips all of that.

IP leasing companies bypass all of that. You don't need to justify anything. You don't need to be a network operator. You pay, you get addresses, and depending on the provider, you can white-label them so your name never appears in any public record. Some of these companies will even register an ASN on your behalf under any RIR you want — you can be sitting in the United States and walk away with a RIPE (EU RIR) ASN that is geolocated to Africa. There's nothing stopping you. You get a fully functional routing identity without ever having to interact with an RIR directly or prove you operate a legitimate network. The accountability chain that the RIR system was built on — the entire reason we have WHOIS, IRR databases, and routing policy — gets severed the moment these addresses enter the leasing market. What you're left with is anonymous, untraceable address space that can be geolocated anywhere, cleaned of any spam history, and rotated on demand, announced by an ASN that exists on paper but answers to nobody.

And the services built on top of this leasing infrastructure should raise serious red flags. We're talking about paying to get IPs delisted from spam blacklists, choosing arbitrary geolocations with no validation, buying "unattributable" white-labeled address space, and renting residential IPs that make traffic look like it's coming from someone's house. These aren't niche services. They are the backbone of how major VPN and proxy providers operate, and they are actively undermining the trust infrastructure the internet depends on.

The uncomfortable truth is that none of this is strictly illegal. The IP leasing market exists in a gray area — much like the residential proxy industry it feeds into. There are no laws against leasing IP addresses, no regulations against choosing a geolocation for your block, no prohibition on white-labeling address space. The companies doing this have terms of service and acceptable use policies, but enforcement is thin and the incentives point the wrong direction. It's muddy water all the way down. The infrastructure isn't criminal, but what it enables often is, and the line between "legitimate IP brokerage" and "anonymization-as-a-service for abuse" gets blurrier every year.

Behold! The Man Behind the Curtain

After digging into this space, here are some of the more notable IP leasing providers I found. These are the companies supplying the address space, the geolocation tricks, and the reputation laundering that make the rest of this ecosystem possible.

LogicWeb

LogicWeb offers bulk IP address leasing bundled with web hosting and domain registration. They supply addresses to VPN providers like NordVPN, ExpressVPN, CyberGhost, and Private Internet Access (PIA). Their leasing portal lets customers pick geolocation for their IP blocks, meaning the addresses can be made to appear as if they originate from wherever the buyer wants.

IPXO

IPXO runs one of the larger IP address management and leasing platforms, with a pool of over 3 million IPv4 addresses. VPN providers like ExpressVPN and ZenMate tap into their inventory. Their automated reputation management system actively maintains the "cleanliness" of leased IPs, ensuring they don't end up on blacklists — which is a polished way of saying they launder IP reputation as a service.

INIZ

INIZ provides dedicated IP leasing marketed toward VPN and "secure browsing" use cases. Their client list includes HideMyAss (HMA), PureVPN, and SaferVPN. The IPs are used to build out anonymous connection infrastructure with misrepresented geolocation — the kind of setup that makes it trivial to circumvent regional content restrictions and access controls.

IPFoxi

IPFoxi straddles both sides of the market — they lease IP address space and simultaneously sell high-speed datacenter and ISP proxies built for web scraping and bypassing geo-restrictions. Their customers include VeePN, WLVPN, GeoEdge, ProtonVPN, NordVPN, and SpiderVPN. The fact that they offer IP leasing and proxy infrastructure on the same platform makes the pipeline from "rented address space" to "anonymized abuse tool" about as explicit as it gets.

Heficed

Heficed operates an IP marketplace for monetizing and leasing both IPv4 and IPv6 address space. They service a long list of VPN providers including PureVPN, Windscribe, IPVanish, StrongVPN, Witopia, Avast, and LE VPN. Like IPFoxi, they also offer datacenter proxy infrastructure alongside their leasing business, providing the full stack needed to route traffic through anonymous, geolocated address space.

AnyIP / IPv4Deals

These two providers run IP marketplaces for monetizing and leasing IPv4 and IPv6 blocks. Their customer base leans toward the residential proxy side — BrightData and Oxylabs, two of the largest residential proxy networks in existence, source address space from these platforms. That means the "residential" IPs those proxy networks sell to their own customers may have been leased from a marketplace and re-labeled, rather than coming from actual ISP allocations.

These are just some of the more well-known providers. There are many others operating in this space, and new ones pop up regularly. The market is large and growing.

Why This Matters

This isn't about streaming providers losing a few subscriptions. The real problem is what this infrastructure enables and what it erodes:

• IP reputation is meaningless — When you can pay to delist an IP from every major spam blacklist, those blacklists stop being useful. Security teams, mail servers, and abuse desks all depend on IP reputation data. If anyone with a credit card can launder a dirty IP range, the entire system is compromised.

• Geolocation data can't be trusted — These companies let you assign any country you want to a leased IP block with zero validation. Every geolocation database, every fraud detection system, every compliance tool that relies on IP-to-location mapping is working with poisoned data.

• Residential IPs as cover — Leasing IP space marked as "residential" means malicious traffic gets routed through address ranges that look like ordinary home connections. Real people's ISP ranges get associated with abuse they had nothing to do with. It also makes it significantly harder to distinguish bot traffic from real users.

• Unattributable address space — White-labeled, anonymous IP blocks with no public WHOIS trail create a perfect environment for fraud, credential stuffing, scraping, and other abuse with zero accountability.

• The pipeline is explicit — Some of these companies sell IP leases and proxy subscriptions on the same platform. They aren't hiding the use case. The entire business model is built around obfuscation.

The Geolocation Problem

IP geolocation is not simple. There's no single authoritative source that says "this IP is in Germany." Geolocation providers like MaxMind and IP2Location build confidence scores from multiple vectors — latency measurements, traceroute data, reverse DNS hostnames, BGP routing tables, user-submitted corrections, WHOIS records, and increasingly, geofeeds. The final "location" you see for an IP is the output of a model weighing all of these signals together. If enough of the inputs say a given location, the confidence score tips and the databases reflect it.

When you lease IP space from these providers, you get to pick what country your addresses appear to be from. There's no verification that you or your infrastructure are actually located there. You just select a country from a dropdown (logicweb.com) and the geolocation databases get updated to reflect your choice. Every fraud detection system, every compliance tool, every geo-restriction check that relies on IP-to-country mapping is now being fed whatever fiction the lessee decided to tell. This is how VPN providers can offer exit nodes in 90+ countries without actually having hardware in most of them.

One of the key input vectors being exploited is the geofeed — a mechanism defined in RFC 8805. A geofeed is just a CSV file published by the address holder that says "this prefix is in this country, this region, this city." Geolocation providers like MaxMind, Cloudflare, and Google actively scrape these files and use them as a data source. The problem? There is essentially nothing to validate them. If you control a block of IP addresses — or lease one — you can publish a geofeed that claims those IPs are in Tokyo, São Paulo, or anywhere else you want. There's no verification against physical infrastructure, no cross-referencing with actual routing paths, nothing. You write a CSV, you host it, and the geolocation databases eat it up.

Then there's the WHOIS country field. When IP space is registered or transferred, the WHOIS record includes a country code. Geolocation providers use this as another signal. If an IP leasing company transfers a block to you and sets the country in the WHOIS record to whatever you requested, that feeds directly into the geolocation models. Between geofeeds and WHOIS manipulation, you can control two of the key inputs to the confidence score without ever physically moving a single piece of hardware. The geolocation system wasn't designed to be adversarial. It was built on the assumption that the people publishing this data are acting in good faith. That assumption is now being exploited at industrial scale.

Shady Services on the Dollar

IP leasing providers have been observed offering the ability to not only choose your own geolocation for leased IP space, but allowing concerning things, such as paying to remove an IP from popular spam lists that we depend on, offering IP space that is marked as residential, and even offering service packages to use their un-leased IP space as PROXIES.

Geolocation Choice Without Validation

LogicWeb's leasing portal lets you pick the geolocation for your IP block from a dropdown. No proof of physical presence, no infrastructure verification. You select a country, and the geolocation databases get updated to match. This is how VPN providers offer exit nodes in 90+ countries without hardware in most of them — and why every fraud detection system relying on IP-to-location mapping is working with poisoned data.

Source: logicweb.com

Residential IP Space for Rent

You can rent IP space explicitly categorized as "residential" — meaning it shows up in geolocation databases as belonging to a home ISP, not a datacenter. Traffic routed through these addresses looks indistinguishable from a regular person browsing from their house. Bot detection, fraud scoring, rate limiting — all treat residential IPs with a lighter touch because they're supposed to be real people. When you can rent that classification on demand, the distinction becomes meaningless.

Residential IPs are also nearly impossible to block safely. ISPs use CGNAT, anycast, and shared pools where a single address might serve an entire neighborhood. Blocking one residential IP risks cutting off thousands of legitimate users. Because of this, most operators don't block residential ranges at all — they focus on known VPN endpoints and datacenter space. The residential proxy industry knows this and exploits it deliberately.

Source: leaseipx.com

Spam List Removal

Multiple IP leasing companies offer paid "cleaning" services to get your IP ranges delisted from Spamhaus, Barracuda, SORBS, and other major blacklists. How exactly does that work? Are these companies in some kind of partnership with the blacklist operators? Is it pay-to-play? Or are they automating the delisting request process that's supposed to require the actual network operator to demonstrate the abuse has been resolved? A dirty IP range gets a fresh slate for a fee, and every security tool that trusts these blacklists is now working with corrupted data.

Source: interlir.com

IPv4 "Cleaning" Service

Voldeta openly advertises an "IPv4 cleaning service" to delist your subnets from spam listings. They market it as a value-add for IP space you've purchased or leased. The result is that whoever buys or leases a block next starts with a clean reputation they didn't earn. Every mail server, every abuse desk, every security tool downstream is now making decisions based on laundered reputation data.

Source: voldeta.com

Anonymous White Labeled IP Space

IPV4Depot literally markets "unattributable" IP addresses. White-labeled space where the lessee's identity doesn't appear in WHOIS or any public registry. The entire point of WHOIS is that you can look up who's responsible for an IP range — it's how abuse reports get routed, how incident responders trace attacks, how law enforcement identifies infrastructure. When you can buy address space designed to have no ownership trail, you've created a black hole in the internet's accountability system.

Source: ipv4depot.com

Proxy Subscriptions on the Same Platform

Some of these companies don't even try to maintain plausible deniability. IPWay sells IP leasing and proxy subscriptions on the same website. The quiet part is said out loud: you can lease IP space from them, or just buy access to their proxy network directly. It's the full pipeline — from address space acquisition to anonymized traffic routing — offered as a product catalog.

Source: ipway.com

Residential ISP Partnerships for Proxies

Some proxy providers are forming direct partnerships with residential ISPs to route traffic through real ISP infrastructure. This isn't datacenter IP space being labeled as residential — it's actual ISP networks being leveraged as proxy pipes. Real subscribers' network ranges are being used to funnel proxy traffic, and the ISPs are apparently willing participants. It blurs the line between "legitimate network operator" and "proxy-as-a-service" in a way that makes residential IP-based detection almost impossible.

Source: reddit.com

What A Mess

The IP leasing industry operates in plain sight, selling services that directly undermine the trust systems the internet was built on. Spam blacklists, geolocation databases, IP reputation scoring, WHOIS attribution — all of it becomes unreliable when anyone can rent clean, geolocated, anonymous address space on demand. These aren't obscure darknet services. They have websites, pricing pages, and sales teams.

Next time you're blocking traffic based on geolocation, trusting a spam blacklist to filter your mail, or assuming an IP's WHOIS record tells you who's actually behind it — think twice. The infrastructure described in this article exists specifically to make all of those assumptions wrong. Location can be faked. Reputation can be bought. Ownership can be hidden. The signals we've relied on for decades to make security decisions are being manipulated at industrial scale, and the companies doing it are selling the tools to do so as a product.

Understanding this infrastructure is the first step toward recognizing how much of the internet's "trust layer" is already compromised.

These servers have never been advertised publicly. No zone files reference them. No domain points to them. They exist solely to observe what the internet sends to an open resolver when nobody knows it's there.

I was bored one day and started digging through the honeypot logs. What I found sent me down a rabbit hole that I figured, when all was said and done, was worth writing up.

The Expected Noise

Within 24 hours of spinning up the cluster, traffic began arriving. This was expected. People scan the entire IPv4 address space (0.0.0.0/0) for port 53 constantly. Botnets probe for open resolvers. Researchers enumerate. Scanners scan. This is the background radiation of the internet and exactly what the honeypot was built to capture.

Then something caught my eye. Here are the top 5 queried domains on my honeypot over a 24-hour period:

Top Queries (24h)
─────────────────────────────────────────────
1  asjo.org                          462,894
2  pizzaseo.com                        3,615
3  subscribe.insight.synology.com      1,266
4  stingbox.twocyber.com               1,096
5  checkipv6.quickconnect.to           1,047

Read that again. The #1 domain has 128x more queries than #2. It's not even close. Everything else on the list is explainable — Synology NAS devices phoning home, security research probes, SEO garbage. And then there's asjo.org, towering above everything else by two orders of magnitude. I brushed it off as "LOL DDOS, MY HONEYPOT IS WORKING!" and simply dropped the IP address using iptables.

46 Million Queries

I woke up one morning to find 46 million DNS queries logged against my nameservers. All of them identical:

Query: asjo.org
Type:  ANY
Class: IN
Proto: UDP

Every single one — a DNS ANY request for asjo.org. The source was a DigitalOcean IP address. My first thought was obvious: this is a DNS amplification attack. Someone was using my open resolver to reflect amplified responses at a victim. Classic DDoS playbook. I dropped the IP with iptables and went about my day.

Hours later, it happened again.

The Department of Defense

The next wave came from 33.44.22.33 — an IP address belonging to ASN 749, United States Department of Defense. The 33.0.0.0/8 block has been allocated to the DoD since January 1970.

Same query. Same record type. Same domain. ANY for asjo.org, over and over, from a Pentagon IP block.

I dropped that one too. Hours later, the flood resumed from a Comcast residential IP. Then Cox. Then it just kept going.

It's Not Even a Large Response

DNS amplification attacks work because a small query produces a large response. The attacker sends a tiny packet, the resolver replies with something much bigger, and the victim gets hammered with the amplified traffic. The ANY record type is the classic choice because it returns everything — A, AAAA, MX, TXT, NS, SOA, DNSKEY, RRSIG, all of it.

So I ran dig asjo.org ANY myself:

The total response is 1,518 bytes. That's it. For context, domains commonly abused in amplification attacks return responses of 4,000+ bytes. The amplification factor here is mediocre at best. If you were building a DDoS cannon, you would pick almost any other domain.

As the domain owner himself put it on his blog:

"For looking up asjo.org, for crying out loud: the zone is 36 lines long"

36 lines. The entire zone file. This is a personal domain with a handful of records, not a juicy amplification target.

Not a Normal DDoS

At first glance this looks like a textbook DNS reflection attack. But the more I looked at it, the less it made sense:

• Duration — This has been going on for over two years. Reflected DDoS attacks are typically short bursts, not multi-year campaigns.

• Source diversity — The queries come from residential ISPs (Comcast, Cox, Verizon, Sky UK, Orange France), cloud providers (DigitalOcean, Amazon), telecom carriers (AT&T, HKT, HiNet, TransTeleCom), hosting companies, and the United States Department of Defense.

• Single target domain — Always asjo.org. Always ANY. Never anything else.

• Legacy address space — The DoD 33.0.0.0/8 block is legacy space from the earliest days of the internet. Spoofing it in a reflection attack would send the amplified responses to the DoD, not a useful DDoS target.

• Poor amplification — A 1,518 byte response is a terrible choice for amplification when domains returning 4x that size are freely available.

If this were a reflection attack, the attacker would be DDoSing... the Pentagon? For two years? With DNS ANY queries for a Danish man's personal domain that returns 1.5 KB? It doesn't add up.

The Domain Owner Knows

asjo.org belongs to Adam Sjøgren, a Danish developer who runs his own infrastructure. A WHOIS lookup shows the domain was created on May 17, 2002 — he's owned it for over two decades. The domain hosts a personal site with some photographs, a music collection, a few links, and pictures of bread. That's it. A 23-year-old personal domain. This is what's at the center of all of this:

He has been documenting this exact phenomenon on his blog since March 2024 — four separate posts chronicling the same pattern I was seeing on my honeypots, two years before I ever set them up.

March 2024 — "Under attack?!": His home router started dropping 40-80% of packets. named was pegged at 100% CPU. A single IP in China was sending thousands of ANY requests for his own domain. His VPS hoster warned him about the traffic spike. When he blocked the IP, another one immediately took its place.

May 2024 — "DNS DoS again": Same thing, different IP, again from China. His jukebox kept rebooting because it couldn't ping the router. 998 out of 1000 packets on his network were ANY queries for asjo.org. He had to reboot the router just to access the firewall interface.

June 2024 — "Another DoS": Hit again. Router latency spiked, CPU maxed, VPS transfer quotas blown. Same pattern. He still had no idea what it was about.

October 2024 — "Stupid DNS DoS again": He gave up. After months of blocking /8 networks and still getting hit with thousands of packets per second, he moved DNS for asjo.org to his registrar domæne.shop. A man who believes in self-hosting, forced off his own nameservers by a mystery flood that nobody can explain.

He wrote: "I really like hosting things myself. I think it healthy for me and the internet in general that people do so — instead of having megacorps silo everything." But the flood won.

I Emailed Him

I reached out to Adam directly. Here is his reply:

Hi,

acidvegas writes:

> I am currently running a dns honeypot network right now logging all
> queries and your domain "asjo.org" has showed up 46 million times in
> the last 24 hours for a "ANY" request.

Yikes!

> What's odd is I did the same as you, started dropping the IP's but
> new ones showed up.

Yes, I ended up not hosting DNS for asjo.org myself anymore, I moved
handling of DNS for that domain to my registrar, who is better at
handling this than I was. My tiny VPS's were running out of transfer
per month(!)

I wrote about it a couple of times on my blog:

 · https://koldfront.dk/under_attack_1870
 · https://koldfront.dk/dns_dos_again_1877
 · https://koldfront.dk/another_dos_1880
 · https://koldfront.dk/stupid_dns_dos_again_1903

> What I found interesting is some of the IP addresses making 10,'s of
> thousands of ANY requests for your domain, were from like Saudi
> Telecom, the United States Department of Defense, etc.

It is very odd indeed.

> If you have any insight into why people seem to be (i can only assume
> spoofing) your domain so much, I would love to chat with you.

I have no idea what so ever, so if you find something out, I would
love to hear about it!

One thing I did notice lately is that my employer (by way of
Microsoft, I assume) has blocked asjo.org:

 · https://koldfront.dk/blocked_by_it_1964

  Best regards,

    Adam

--
 "This whole business of Santa rewarding good kids          Adam Sjøgren
  and neglecting bad kids really bugs me."             asjo@koldfront.dk

He has no idea either. But that last link he sent led me to something else.

Collateral Damage

In January 2026, Adam discovered that his employer's network — via Microsoft Defender SmartScreen — had blocked asjo.org entirely.

His personal domain, which contains a photo collection, a music list, and a few links, is now flagged as dangerous by Microsoft's threat intelligence. He also noted that people in Asia have been using asjo.org as a spoofed From address when sending spam. The DNS flood, the spam spoofing, the reputation damage — this one man's personal domain has become collateral in something he has no control over and no understanding of.

As he put it: "But great for my bad boy reputation at work, I'm the one with the blocked domain!"

Ranked #646 in the World

Akamai publishes a ranking of the top 10,000 domains by DNS query volume. I pulled the CSV and searched for asjo.org.

asjo.org is ranked #652 globally. Let that sink in. To put this in perspective, here are some of the domains it outranks:

asjo.org            #652
x.com               #671
telegram.org        #689
ebay.com            #719
intel.com           #727
huawei.com          #742
hotmail.com         #760
discord.com         #778
uber.com            #836
dropbox.com         #838
amazon.co.uk        #893
python.org          #906
booking.com         #928
duckduckgo.com      #962
slack.com           #966
nvidia.com          #968
oracle.com          #973

A one-person Danish blog about bread and photographs is generating more DNS query volume than X (Twitter), Telegram, eBay, Discord, Uber, Dropbox, Slack, Nvidia, and Oracle. That is not organic traffic. The sheer volume required to outrank these platforms — some of the most visited sites on the internet — is staggering. Something is generating an astronomical number of DNS queries for this domain across the global internet.

This raises an interesting thought experiment: can you spoof your way into the top 1 million domains? Cloudflare, Akamai, and others publish these popularity rankings based on DNS query volume. If sheer volume of spoofed queries is enough to land a personal blog at #646 globally, what stops anyone from artificially inflating any domain into these lists? These rankings are used by security tools, threat feeds, and allowlists everywhere. We may have to put this to the test. 😈

Dataplane.org Sees It Too

Dataplane.org operates a network of sensors that observe unsolicited DNS queries — essentially the same thing my honeypot does, but at larger scale and run by operators for operators. They publish a report of type/name pairs observed from unsolicited DNS query attempts.

asjo.org appears in their current report:

dnstypename  |  ANY               |  asjo.org

This is independent, third-party confirmation. Dataplane's sensors, my honeypot cluster, my colleague's nameserver, and Adam's own infrastructure — all observing the same phenomenon, completely independently.

Corroboration

A colleague who operates his own independent nameserver grepped his logs after I mentioned this. He found 17 unique source IPs responsible for 1.4 million queries for ANY asjo.org on his server alone. These are the IPs, resolved via bgp.tools:

Look at the diversity. US military. European residential ISPs. Asian telecom carriers. Middle Eastern mobile operators. Russian transit providers. Israeli broadband. Turkish gaming companies. Cloud providers. Small Dutch hosting shops. This is not a single botnet. This is not a single attacker. This is something distributed across the global internet at a scale that is difficult to explain.

What We Know

I don't have a clean answer for what is happening here. Nobody does — not me, not Adam, not my colleague, not the Dataplane.org operators. But here is what the evidence shows:

• DNS ANY queries for asjo.org are being sent to nameservers across the internet at massive scale — enough to rank the domain #646 globally in Akamai's DNS rankings.

• This has been happening for at least two years, documented independently by multiple observers across multiple continents.

• The source IPs span residential ISPs, cloud providers, DoD legacy address space, and international carriers across at least 12 countries.

• The target domain's zone file is 36 lines long and its ANY response is 1,518 bytes — a poor choice for DNS amplification.

• The pattern does not fit a typical DNS amplification DDoS — the duration is too long, the source diversity is too broad, the amplification factor is too low, and the use of DoD legacy address space makes no tactical sense for reflection.

• Blocking individual IPs causes immediate rotation to new sources, suggesting coordination or automation.

• The phenomenon is confirmed by Dataplane.org's independent sensor network.

• The collateral damage is real — Adam was forced off his own nameservers and his domain is now blocked by Microsoft Defender.

Some possibilities:

• Massively distributed botnet — A botnet with nodes across residential, enterprise, and government networks, all hardcoded to send ANY queries for a single domain. But why asjo.org? And why for two years? And why would a botnet operator burn resources on a 36-line zone?

• Misconfigured software — Some widely deployed application or appliance with a hardcoded or default DNS health check target of asjo.org. A monitoring probe gone wrong at planetary scale. This would explain the residential ISP diversity — consumer routers, IoT devices, or embedded systems phoning home with the wrong query.

• Research or measurement — An academic or government project studying DNS resolver behavior using asjo.org as a canary domain. The DoD involvement could support this, though the volume and collateral damage argue against any responsible research program.

• A grudge that outlived its owner — My personal favorite theory. Someone Adam pissed off at some point rooted a box, wrote a spoofing script to flood DNS queries for his domain, and let it rip. Then they lost access to the box. But the script never stopped. It's still running, years later, on some forgotten compromised machine — an automated vendetta in limbo, spoofing asjo.org into the void long after whoever started it moved on or forgot it existed.

• Something else entirely — The internet is weird. Sometimes the answer is boring. Sometimes it never comes. And sometimes a Danish man's personal blog ends up ranked between truste.com and google.us and nobody knows why.

If you run a nameserver, grep your logs for asjo.org. I'd bet money you'll find it.

As of this writing, the queries are still coming in. We are actively monitoring this across our honeypot cluster and the flood has not stopped:

Every few seconds, another ANY query for asjo.org. Still going. Still unexplained.

Sources & References:

• Under attack?! — koldfront.dk, March 2024

• DNS DoS again — koldfront.dk, May 2024

• Another DoS — koldfront.dk, June 2024

• Stupid DNS DoS again — koldfront.dk, October 2024

• Blocked by IT — koldfront.dk, January 2026

• DNS Type/Name Report — Dataplane.org

• Akamai DNS Traffic Rankings

• BGP.tools — IP/ASN lookups

Reach Out

If you run a nameserver and have logs showing queries for asjo.org, I would love to compare notes. Any intel on this mystery is welcome — reach out at acid.vegas@acid.vegas or join us on IRC at irc.supernets.org, join the Zulip, or hit me up on Twitter at @acidvegas4real.

Update — 2026-03-03: Since publishing this article, a network operator responsible for one of the source IP ASNs listed in the corroboration table reached out to confirm that the traffic is not legitimate. The queries for asjo.org originating from their address space are not coming from their infrastructure — the source IPs are being spoofed. We suspected this from the beginning given the source diversity and the presence of DoD legacy space, but this is the first direct confirmation from an operator on the other end. The IPs sending these queries are forged.