175

Lots of dead Lemmy/Kbin domains have CNAME records pointing to the same domain parking company (lemmy.pierre-couy.fr)

submitted 5 months ago* (last edited 5 months ago) by pcouy@lemmy.pierre-couy.fr to c/fediverse@lemmy.world

7 comments fedilink hide all child comments

While monitoring my Pi-Hole logs today, I noticed a bunch of queries for XXXXXX.bodis.com, where XXXXXX are numbers. I saw a few variations for the numbers, each one being queried several times.

Digging further, I found out these queries were caused by CNAME records on domains that look like they used to point to Lemmy/Kbin instances.

From what I understand, domain owners can register a CNAME record to XXXXXX.bodis.com and earn some money from the traffic it receives. I guess that each number variation is a domain owner ID in Bodis' database. I saw between 5 to 10 different number variations, each one being pointed to by a bunch of old Lemmy domains.

This probably means that among actors who snatch expired domains, several of them have taken a specific interest with expired domains of old Lemmy instances. Another hypothesis is that there were a lot of domains registered for hosting Lemmy during the Reddit API debacle (about 1 year ago), which started expiring recently.

Are there any other instance admins who noticed the same thing ? Is any of my two hypothesis more plausible than the other ? Should we worry about this trend ?

Anyway, I hope this at least serves as a reminder to not let our domains expire ;)

top 7 comments

sorted by: hot top controversial new old

[-] slazer2au@lemmy.world 43 points 5 months ago

Isn't there a mechanism for this? If the receiving instance doest respond the sending instance marks it as dead.

[-] pcouy@lemmy.pierre-couy.fr 27 points 5 months ago

I think they do get marked as dead after the Bodis subdomain does not act as a Lemmy instance. But I was wondering if a large number of instances "waking up from the dead" and acting maliciously could cause some trouble. Or would such "undead" instances pose no more threat to the fediverse than the same number of newly created malicious instances ? I'm mainly thinking about stuff like being in a privileged position to DoS most instances at once, or impersonation of accounts that used to actually exist on these "undead" instances

[-] otter@lemmy.ca 17 points 5 months ago

From what I can tell, an instance is either 'linked' (federated) or 'blocked' (defederated) on Lemmy. Mastodon has some more granularity. If an instance came back as a zombie, it wouldn't be any more powerful privilege wise than a new instance that is malicious. It would get defederated same as always.

What could be a problem is on the individual user level. Say that a lot of users sort their feed by subscribed. They are not affected by random instances coming and going. However, they will be affected if a bunch of their (dead) subscribed communities suddenly become malicious.

Anyway, I hope this at least serves as a reminder to not let our domains expire ;)

It's an important point for sure.

Your sensitive data and logins are tied to email addresses, which are tied to domains. Lose your domain, someone can access everything.

[-] pcouy@lemmy.pierre-couy.fr 17 points 5 months ago* (last edited 5 months ago)

Your sensitive data and logins are tied to email addresses, which are tied to domains. Lose your domain, someone can access everything.

I recently stumbled upon an article showing how bad this can be when the expired domains were used for important/serious stuff

[-] andrew_s@piefed.social 14 points 5 months ago

My experience from when my backend server died, and Lemmy instances were getting a 502 response to ActivityPub POST activity, they eventually stopped sending anything. They kept trying to GET stuff though (user account details, nodeinfo responses), and lemmy.ml has never stopped POSTing, even though I configured nginx to always respond 403 to anything from them for about a year now.

[-] pcouy@lemmy.pierre-couy.fr 13 points 5 months ago* (last edited 5 months ago)

never stopped POSTing, even though I configured nginx to always respond 403 to anything from them for about a year now.

Lol, there are definitely some stubborn user agents out there. I've been serving 418 to a bunch of SEO crawlers - with fail2ban configured to drop all packets from their IPs/CIDR ranges after some attemps - for a few months now. They keep coming at the same rate as soon as they get unbanned. I guess they keep sending requests into the void for the whole ban duration.

Using 418 for undesirable requests instead of a more common status code (such as 403) lets me easily filter these blocks in fail2ban, which can help weed out a lot of noise in server logs.