Tiny Tiny RSS: Community

Android client access strange domains

PLEASE READ THIS BEFORE POSTING: Read before posting / reporting bugs

Describe the problem you’re having:

I am running the Andorid client. AFter I launch the app, it seems to be access stange domains. Names like ubaqevvnbky or gleeyzuhcdqo and it keeps creating new weird combos like that.

If possible include steps to reproduce the problem:

I have a piece of software called blokada that creates a loopback vpn so it can do blocking of ad kits and trackers and the like. Luanch tt-rss and wait a few secs and then you’ll see these appear in the log.

tt-rss version (including git commit id):

latest android client from play store

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

Please provide any additional information below:

This looks like what a bit net does and am wondering if you’ve linked to some infected library of other kit.

I have no idea what you’re talking about but I’m reasonably certain there’s no “infected libraries” within the APK and it shouldn’t access any “strange domains”.

what’s likely to be happening is that your feeds have links to those “strange domains” within article content or headline images, ads or something, and you’re just being paranoid.

anyway, if you have doubts, build the app yourself and compare the results.

Maybe also try it without this blokada app… My guess is the problem lies there.

It is caused by the internal web browser. Same happens if you open Chrome on Android.

I can’t paste links (new registration), but google for “chrome weird domains lookup” and the following will popup:

As it turns out this is actually legitimate behaviour caused by Google Chrome. Some ISPs will respond to DNS queries for non-existent domains (often due to typo’s) with an often unwanted advertisement along the lines of “did you mean this thing?”.

As per the RFC, when a DNS request for a non-existent domain is made, the appropriate response is to answer with NXDOMAIN. However that is not what some ISPs are doing.

Some ISPs have been improperly responding to DNS requests for non-existent domains with an A record for a page that they own, which is typically an advertisement. An overview of this type of manipulation and associated consequences can be seen here.

As this behaviour is more than likely unwanted, Google began combatting it by sending 3 requests shortly after startup and checks to see what the response is. If Google Chrome see’s that these requests are all resolving to the same A record instead of resulting in an NXDOMAIN it knows to respond accordingly and to not display these ads to the end user.

This is not the only cause for random looking DNS requests, but is quite common. The key to identifying Chrome as the cause would be seeing the queries sent in groups of 3 per internal host.

oh, this is pretty clever actually.

e: imagine not using DoT etc.

In other words it probably is Blokada that is triggering this, since it is - in effect - a DNS service.

Thanks. Weird that I haven’t seen this before and only in tt-rss. But then again, I use firefox on android.

And Fox, Blokada is just seeing domain lookups and so wasn’t the issue. Blokada is great for stopping all the spying by ad kits and the like in mobile apps. Over about 3-4 months on my phone it has blocked 300K plus requests to ad tracking sites from apps. It has to be sideloaded because for some reason Google doesn’t like things that block spying and adware.

there’s also DNS-66 which does the same thing with less fancy UI and doesn’t try to push related services.

Hadn’t found that and thanks, fox. will take a look. I do dislike the stuff that blokada pushes