Blocking rules completely fail to block subdomains if the subdomain contains a backwards slash

[DandelionSprout]

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• [x] I am running the latest version (v0.102.0)
• [x] I checked the documentation and found no answer
• [x] I checked to make sure that this issue has not already been filed

Issue Details

While looking into the usual useless spam requests that my AGH server gets, I noticed to my surprise that two particular requests had not been blocked, despite them being almost identical with most of the other requests:

From the looks of it, it appears that AdGuard Home is currently completely unable to block domains with backwards slashes through ||-type entries, in my case t\\.t.a.cnamedot.d7e8406fdirect.bakeryfun.ml:

I presume this is something that should be fixed somehow.

• Version of AdGuard Home server:
  • v0.102.0
• How did you setup DNS configuration:
  • N/A
• If it's a router or IoT, please write device model:
  • Raspberry Pi 4
• Operating system and version:
  • N/A

Expected Behavior

Domains containing backwards slashes are blocked if they are covered by a ||-type blocking rule.

Actual Behavior

Domains containing backwards slashes are not blocked, even if they are covered by a ||-type blocking rule.

Screenshots

Shown above in order to explain the context better.

Additional Information

I was able to rule out that it was my list setup's use of ||ml^ that had been flawed, since the "Check the filtering" feature confirmed this also applied to ||bakeryfun.ml^.

[ammnt]

I have exactly the same issue: https://github.com/AdguardTeam/AdGuardHome/issues/1698.

[ameshkov]

The thing is that this is not a valid domain name, and it's surprising that it is resolved.

To block it you should use a regexp rule.

[ameshkov]

Hmm, it seems that the resolver discards invalid character, you can check it with dig g\oogle.com

We'd better do the same

[DandelionSprout]

It was surprising to me too that the requests were resolved. Though after all, spambots on cloud hosting servers who consistently use ml addresses, constantly surprise me with their scummy strategies.

[szolin]

Use /bakeryfun.ml$/ rule - it works for domain names with backslash characters.

I'm not sure if it's a good idea to process on our side the backslash characters in host name in request. The way we currently match ||hostname^ rules via regexp ^(http|https|ws|wss)://([a-z0-9-_.]+\\.)? in urlfilter isn't so reliable for such cases. For example, what if the host name contains # character - we won't match it either!

[szolin]

UI may use regexp rules e.g. /bakeryfun.ml$/ instead of ||bakeryfun.ml^ for the domain names that contain invalid characters.

[ameshkov]

Wait, the UI seems to do okay after all: https://uploads.adguard.com/up04_AdGuard_Home_6hbv3.png