I have a client with an internal AD domain setup for Dome Shield protection. All clients point their DNS to the internal DNS server. On the DNS server it has its forwarders configured for 8.26.56.26 and 8.20.247.20 only.
This client has a dynamic public IP so I have installed and activated.they Dynamic IP updater on the server. It shows as active and shows the correct public IP in the portal. I have created and applied a security, category and black/white list policy to the network.
The issue is, sometimes blocking of websites work, sometimes not. No changes are ever made and it just decides to stop working. I’ll use the test sites on the server (http://category.test.cdome.net/) and sometimes it shows green, then refresh a couple times and shows orange (not applied). I have gone through the config a ton of times, rebuilt policies…etc. The dynamic IP hasnt actually changed anyway, and this still happens.
Is there a special configuration for Windows DNS server to make this work (again all clients only use Windows AD server as their DNS). No roaming agents are configured or in use. The AD server does not have root hints enabled (to make sure that it only uses Comodo DNS for forwarders). I have tried setting root hints, same results. I have tried adding Comodo DNS to each internal client as a way to test (cant keep it that way) but still same sporadic results.
We have created ticket for you regarding this concern, as we need additional information from you and your client.
But rest assured that the resolution will also be provided on this forum post to provide assistance to all.
You did the right config but in that sense, I really suspect there should be secondary dns setting either on endpoint or on internal DNS server (or root hints).
Have you tried with endpoint directly coming to Comodo DNS servers with IP Updater enabled?
Best detection can be done via wireshark on endpoint and DNS server monitoring where the dns packets goes.
Our team will connect to help you on both analysis.
Yes originally I had 3 DNS servers on each endpoint. First was AD server and the others the 2 Comodo DNS servers. However that caused AD name resolution issues and its not best practice in an AD/DNS environment to have any external DNS configured on the endpoint. (At least via DHCP while its inside the network)
I do have both DNS servers configured on the Windows AD DNS server, so there is a secondary. I did have the ISP’s DNS in there as well, but took that out (didn’t make any difference).
I have tried an endpoint directly with IP updater enabled. Again it works sometimes, I would go as far to say “most” of the time it works. But far to many times it doesnt. Here are the steps I’ve found to “fix” the issue most of the time
Edit the policy in Dome Shield applied to the network. Dont even make a change, just edit and "update"
Do a ipconfig /flushdns and clear cache on the DNS server
Test policy sites (http://category.test.cdome.net/)
It usually takes a few minutes, but if I do those steps in that order specifically, it usually starts working again for a while.
I can also add that it seems like all web traffic is still reported to dome. If I look at reports, I see traffic that should be blocked via category or black list in the reports as Allowed. So its definately seeing it. The issue must be in applying the rules somehow.
Actually, updating the rule doesn’t make any difference in the Shield side. If you have seen the category test page as blocked even at least once, it means that the Shield has your rule set correctly applied. This means, the problem may be due to where DNS packets are going to.
We would like to help you by a remote session so that we can observe what is happening once rules are not getting applied.
We will be reaching out over the support ticket created…
One question, Do you use IPv4 or IPv6 ? It might be regarding applying policy over IPv6 domains on IPv6 networks.
We already resolved that issue previously but we might be still related with that.
I would never suggest putting anything but your AD and DC servers as DNS for internal devices as this is the best way to cause login, file access and other issues that will keep you scratching your head for hours.
The way you done it for forwarding is perfect for a business without a software file wall in place.
Ideal way would be to have your internal DNS servers pass external requests off to your software firewall (Comodo Dome Firewall, IPFire or PFSense), this then speaks to Dome Shield for you and passes the info back. The only reason for this is that your AD/DNS servers are not actually leaving your network then giving them even more protection.
I would never suggest it either. I did so temporarily as a test just trying to get this to work. I would love to put in a software firewall (or better yet a better hardware firewall than they have), but they do not have the hardware to support it and currently are not willing to buy it yet (hopefully soon). I pitched Dome Shield as a “lower” level protection service until they can buy something better, but I’m regretting it since it doesn’t seem to work consistently. I’d say better than nothing but speed has been an issue too. If I use google DNS or openDNS servers, web browsing is much faster. When using Comodo DNS it is noticeably slower. Not always, again just inconsistent like most of their products. I’m trying really hard not to blame the Comodo products (I want to champion them), but its hard not to when there have been so many issues with this entire platform recently.
I see a problem on applying policy on your network starting 66. I have corrected that. I think you experienced the problem on that network. Can you check that again?
Regarding the speed, can you provide us DNSBenchmark results on your network if possible?
We are significantly expending the DNS pops next month. Adding 3 additional pop to tackle the traffic burst. Those temporary slow-downs will totally be resolved.