[Bug]: DNS traffic abuse mass TXT lookups for iantem.io

[rlees85]

What happened?

Not sure where to report this I've never heard of Lantern until recently. I host some public DNS revolvers and over the past week or so have seen an abusive amount of TXT lookups for really long random domain names ending in iantem.io which I understand is associated with this project. They are from many different IPs.

At this point I am trying to understand is this something that Lantern does or something trying to abuse Lantern does? If the former I really need you to stop. I am not CloudFlare or AWS.

Version

No response

Which platform(s) does this affect?

• Android
• iOS
• Desktop (Windows)
• Desktop (MacOS)
• Desktop (Linux)

Related Support Tickets

No response

[josephbu]

Likewise I host public DNS resolvers reachable on DOH/DOT/DOQ that are included in various lists eg: dnscrypt-resolvers.

Since around 18th June I've seen a large uptick in queries variants of the domain above, queries that never resolve and as such can't be cached, resulting in vastly higher workloads.

It would be nice to understand what we can do to help or improve the situation.

[rlees85]

Sadly very little interest in this very serious problem by Lantern so far. Ive had no other choice than to instantly ban (by packet dropping) any IP that requests any domain relating to Lantern.

I tried other rate limiting techniques but its so distributed it just doesn't help.

Only concern now is that the banlist is getting big enough to cause its own set of performance issues.

@josephbu unrelated but do you mind me asking what resolver software you are using? I'm using Knot Resolver, which I like a lot but it does have some funny moments especially with unusual traffic.

[josephbu]

@rlees85 My resolvers are running Adguard for the Internet facing DOH/DOT/DOQ + caching and Unbound for DNS resolution.

I'm not sure what queries for this domain are meant to look like, or how they are meant to behave, but thousands of queries for rotating/random sub-domains that are often empty and take multiple seconds to resolve, it's just not great for small public resolvers.

I assume the project is using DNS as a data transport layer, which isn't conducive to caching resolvers really.

[WendelHime]

Hi @rlees85 and @josephbu — thank you for the reports, and apologies for the load on your resolvers and for the delay in responding.

We're rolling out a configuration change that removes operators in your category, so this traffic should taper off on its own as existing clients pick up the update. You're of course free to continue filtering it in the meantime, and doing so won't cause problems on our side.

[josephbu]

@WendelHime Thanks for the update :-)

For my resolvers I did a temporary forward to cloudflare as upstream, which solved most of my load issues.

I found the lame NS delegation for t.iantem -> tns.iantem was causing issues and timeouts for my config.

All the best with the rollout!

[josephbu]

For what it's worth, it seems the domain in question was added to 1Hosts Lite block list (and maybe other lists) around the end of June.

https://github.com/badmojr/1Hosts

Just mentioning it in case it's causing any issues.

[WendelHime]

As an update, we've been investigating the issues related to the dns authority being unreachable and it has been disabled in recent beta tests until we make into return to a stable state.

@josephbu thanks letting us know! It looks like it started to become blocked around the end of May (or maybe it was added to another blocklist).