Wait for an avast team member to give a final verdict, as we here are just volunteers with relevant knowledge,
but only avast team members can come and unblock. But this could be a DNS error returned by -dns3.sbb.rs,
as we get “Unable to connect to the remote server (-http://dns3.sbb.rs)”.
That domain is not serving a website, it is a IPTV streaming server that is part of a larger CDN, it is not supposed to serve anything on it’s bare (sub)domain (hence 404). There are other endpoints on that domain that will serve the video content (and use HTTPS) for user and apps should never request bare domain name. 404 on bare domain is “by design”.
I am not comfortable discussing security on an public forum but if you need further clarification as to why some things are done the way they are you are free to DM or (better yet) email me, i’ll try to give you as much information as possible.
We’ve already reported some subdomains on url that you provided, but since we have hundreds of possible subdomains we can’t manually whitelist each and every of them and we don’t want to send you a lot of false reports from our side through some automated reporter. Is it possible to report *.domain.name there?
Our CDN nodes all have these domain names in common *.ug.cdn.united.cloud, *.ug-be.cdn.united.cloud and *.ug-af31.cdn.united.cloud, maybe that would be the way to “whitelist” them all?
Whitelisting a node at a time is hardly maintainable as we are adding new nodes all the time and we don’t want to send you a whitelist request before the domain is blacklisted and by that time our users are already affected and we are getting user complaints. And requesting that users create rules to whitelist these domains on their own machines is not exactly good customer experience
We are willing to work with you in order to resolve these issues in a maintainable way.
Some more context - we are IPTV provider with content delivery network consisting of hundreds of nodes and hundreds of thousands of users on multitude of devices.
sbb-bg-ne-s1-3.ug-be.cdn.united.cloud is INDIRECTLY listed in an RFC2 list. An ancestor of sbb-bg-ne-s1-3.ug-be.cdn.united.cloud is causing the domain to be listed. You cannot directly remove sbb-bg-ne-s1-3.ug-be.cdn.united.cloud as it is not directly listed.". After following the ancestor url we get that "cloud IS listed in an RFC2 list.
When we follow ancestor URL we get that
cloud IS listed in an RFC2 list.
Also, their documentation states that:
Some entire TLDs lack a public whois server or have a non-standard whois server (including servers which do not return contact information). These domains are listed in the whois2 zone. Individual hosts cannot be removed from whois2...
However, on the same page they are discouraging blacklisting of subdomains if TLD is blacklisted as subdomains don’t have control over registrar:
We discourage users from blocking eMail solely based on inclusion in the RFC2 lists, and would like to strongly reiterate that in the case of hosts listed only in WHOIS2, as registrar policy is outside their control.
Anyway, we have already sent an email notifying our registrar about this issue even though it is not necessarily their fault.
Regarding the HTTPS redirection and 404 errors, we can make an empty index.html page that will be served after being redirected from http to https, but IMHO this is just a waste of resources as we will be wasting cpu cycles for https termination on an empty webpage. To me, it is very strange that a page should be blacklisted because root (sub)domain is not serving https webpage and clients are not requesting that root subdomain but rather some other path like <subdomain.domain.tld>/stream for example.
Is it possible that we get a response from Avast with root cause of blacklisting so we can target specific reason?
Thank you again and again, you’ve been very helpful with your assistance!
