Score:0

Is it common for nested subdomains to get blocked due to phishing detection?

is flag

I have a domain that uses subdomains for users, for example:

user1.example.com

To distinguish between other official subdomains and user subdomains I reserved "at" for all such cases. For example, some official subdomains are:

api.at.example.com, releases.at.example.com, support.at.example.com

I've twice now come up against blocks due to false positive phishing detection. So far from Google and Cisco. They seem to suggest my site is trying to impersonate "api.at" or "releases.at".

It's rather annoying that services are blocking subdomains with no other signs of malicious activity, simply based on a fairly generic name they are given. Especially annoying with Cisco as they block fetch/xhr requests with the user having no option to bypass. Google at least doesn't block fetch/xhr, only if you visit the domain in browser as a page.

I'd like to know how common this is? I'm considering reserving some first level subdomains instead just to get around it (e.g. api.example.com), but it seems silly for services to effectively block all nested subdomains. If it isn't common then I might just try submit support tickets to the offending services.

(this is for a brand new domain with no previous owner and no malicious content whatsoever as I wrote the whole app myself)

shadow-light avatar
is flag
Yea maybe I shouldn't have used ".at." since it is a TLD. Still seems way too overzealous to block such domains though.
Score:1
fr flag
anx

Yes, while I agree that is its reckless to cause widespread problems with such overblocking, this is not limited to single entities that you could get to individually fix this for you.

I installed similar blocking rules in desktop systems I administer and have confirmed with significant commercial entities that they enforce such blocks across their device fleets. My rules at least only apply to domains containing or resembling owned and associated brand names. Other companies claim to use "machine learning" to determine their "URL threat classification", which to me sounds even more likely to result in what you experienced with Cisco.

This sort of detection is definitely common in email context - you should expect to be instantly classified as a spam source if you are seen relaying unauthorized mail for <brandname>.<tld>.<otherdomain>.<tld>.

You are expected to vet & monitor your customers to never let things like bankofamerica.com.yourdomain.example be used by scammers. If your domains looks like you neglected choosing safe defaults, expect problems with particularly sensitive heuristics. I recommend you stay clear of any popular ccTLD (e.g. .at) and uTLD (e.g. .com) for labels you use in the middle of your longer domain names.

Depending on the kind of services you offer to users, it may even be appropriate to have that domain added to the public suffix list. Even if it is not, go read related documentation, it may help you determine whether it is a good idea in the first place to host user content below a domain also in use for other services (hint: browser are complex beasts these days).

shadow-light avatar
is flag
Yea it came up again with another user so I've moved everything to single level subdomains (api.example.com). A bit annoying but it is what it is. thanks
shadow-light avatar
is flag
Turns out the domain had a previous owner and was blacklisted. Was very hard to discover since the domain name system doesn't keep records of previous owners, so we assumed we were the first one. That being said, nested subdomains can still be an issue too, so it may have been a combination of both.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.