I don’t discuss I write for them. Maybe they will read…
Although a bug report about this issue was post about 3 years ago 
here :-\
Can you please check and see if this is fixed with the newest version (7.0.313494.4115)? Please respond to this topic letting us know whether it is fixed or if you are still experiencing the problem.
Thank you.
PM sent.
Hello
I did not understand, where I can download the new version of COMODO
I see “Release Date: September 24, 2013” in Best Internet Security Software 2022 | Antivirus Total Security
COMODO CIS finds no updates
The new version can be downloaded from this topic:
https://forums.comodo.com/news-announcements-feedback-cis/comodo-internet-security-703134944115-released-t102577.0.html
Thanks.
Not fixed
Thank you for checking this. I have updated the tracker.
I’m sorry, but the devs have informed me that this is a consequence of the way in which CIS was designed. It appears that if a site has a very large range of IP addresses, that this can cause other sites to be affected as well. I will therefore move this to Resolved. Please let me know if you have any questions and I will do my best to answer them.
Thank you.
Not solved
Developers read carefully the description of the defect
This defect can be fixed by handle DNS queries correctly and TCP packets and does not require an http-level processing.
The cause of the defect mentioned above in the subject and not an architectural feature (which CIS was designed)
Please reopen the request.
Hi fdsc
I understand the frustration, but I think the devs do understand.
What the devs have said is that they ‘WontFix’ because the value to users is too low. I’m guessing they think you should use URlfilter instead. Any reason why that would not work for you? Please forgive if you have already answered this.
The issue is a consequence of design of blocked zones in CIS. There is no ability to store a discontinuous set of IP ranges as a zone. Indeed I wonder if this makes sense conceptually - maybe Outpost implements it as a different firewall concept - not a zone? Maybe as a URlfilter?
Anyway please post an Outpost screenie of the functions GUI so we can judge.
Many thanks
Mouse
Hello
use URlfilter instead
Any reason why that would not work for you?
URIFilter is add-on for FireFox. At the same time, there are other programs that, for example, request updates from various IP and one http-domain. There are also other programs. There are FTP clients, SMTP/IMAP clients. All this can be conveniently locked only from the firewall.
I would like to emphasize that for most programs I use white list access and block other access. It is very difficult to make because of this bug.
I would also like to draw attention to the fact that in IPTables in Ubuntu this function works correctly a long time ago. In recent versions, there is convenient graphical interface that is included with Ubuntu by default.
There is no ability to store a discontinuous set of IP ranges as a zone.
I think the developers could have created each time the set of blocked IP areas.
Does IPtables. When adding the domain name based rules IPtables deploys domain name in the rules to IP ranges. I don’t understand, why not do as well. Adding more zones manually in COMODO’s quite possible.
maybe Outpost implements it as a different firewall concept
I don’t use Outpost.
I know that iptables implement this feature (blocking IP zone by domain name) correctly.
of the functions GUI
The defect is not related to the graphical interface. With a graphical interface in COMODO’s all true.
In recent versions, there is convenient graphical interface that is included with Ubuntu by default.
This is error. require installation, but it is work with Ubuntu in console interface to iptables by default
Sorry URLfilter is the original internal name for Webfilter, the CIS function.
To use WebFilter impossible in my way.
Everything written above applies to it.
WebFilter is suitable to set the black list, but not in the whitelist with application granulated rules.
Read the description of the defect, which was originally sent me too.
I again suggest that the original defect, sent me was not read by you and was not read by the developers
Pay attention to the fact that my defect is a duplicate of the defect described in the beginning of the topic and located below.
I repeat that I am using a white list of IP addresses for each application.
Unfortunately, I have to repeat the same thing several times, and this horrific defect is not corrected. Although he had already more than a year.
Please reopen the defect until 1 October. I don’t want developers reported that this defect is closed and won an award for that again left uncorrected critical defect.
I once again would like to emphasize that the information provided by me in the issue concerns not black address list.
Any attempt to circumvent the defect is only the desire of developers to close it before the new quarter.
The function should either be fixed or removed, because it works incorrectly.
I understand your frustration, but please calm down or you risk being moderated - neither you nor I can know what motivates the developers. :P0l
In fact there is a simpler explanation of the confusion.
The original defect relates to blocked zones, and that is how it is described in the tracker.
You have raised a more general and probably causally-related issue regarding DNS resolution and its affect on firewall rules more generally. This is probably better as a separate new issue with a noted causal link to M276. I am sorry we have not worked that out before now. I think it’s a valid issue, though that’s without hearing what the devs have to say.
I agree that you cannot use WebFilter to control access at an application level, but the original (topic head) issue here was not about application level control! It was about zone control. So this contention makes sense for the new issue, but not for the original (topic head) issue.
Just FYI I am a volunteer moderator not a developer I am not aware of any quarterly bug fix targets.
If you agree, Chiron and fdsc, shall we separate out fdsc’s issue by splitting the topic? The new topic should be about DNS name resolution to multiple discontinuous IP ranges in FW rules generally, and can mention zones as an additional example, but I would suggest the focus should be firmly on application rules. It should say that Webfilter is not an adequate substitute because of the lack of application level control. I would suggest it be logged as a debatable from the start in the tracker to avoid a loop where the devs say it’s by design, and therefore a wish.
Best wishes
Mouse
mouse1, I know that you are not the COMODO developer. Believe me, all exactly as I say - developers simply close all opened defects at any occasion.
If we want to split a single defect on the two, we need to know exactly what both defect.
however, when the separation is that both defect will be one and the same function name resolution DNS.
This is one defect. If developers don’t understand, you have to explain to them that this defect just described on the example of the black list, however, affect the rules in General.
I think it is possible in any bug tracker.
I don’t see any of the two defects. This is one defect resolution DNS rules to IP rules.
Please describe to them the example of white list in this defect.
Clarify
You can create a description of the second defect is another defect.
But I would like to note that this defect should be reopened. Because the functionality is not working properly. Regardless of the possibility of its replacement.
And it can’t be “by design”, because the possibility to make domain name rule provides a concrete and unambiguous function that should surely work. It does not work correctly.
You can create another defect. However, this defect should be open anyway.
The new defect will be an open defect, it will be more general than the current defect and flagged as the probable cause of it.
You can ask for it to be opened as a bug if you wish, but it may take longer to be confirmed. I agree from a user perspective this is a bug, and should be reported in this board. The devs would probably say that a bug is something that is in conflict with their specification documentation, if it is not in conflict, it is not a bug, even if the specification is wrong.
That is why we have the debatable status. It means users say bug, devs say (or probably will say) wish. So Chiron can either log it as a debatable from the start or can log it as a bug. The right thing to do is to log it as a bug - but it may be quicker to log it as a debatable. Maybe Chiron will decide what is best!
I hope that makes thing clear
Best wishes
Mouse