We have to big issue in Turkey to use Dns Protection. In the starting of computers Dns Protection agent cannot resolve any websites like 5 minutes. After 5 minutes Dns agent working properly. This is a very big issue, a lot of customers, and potential customer affected from that problem.
Page 1 / 2
I am seeing the same issue in the USA. Did you find a resolution for this?
Hello @ and @
Thank you for the note - I (PM) would like to work with you to ensure we resolve this for you. Can you please provide me with some details and I'll have our support team reach out to you guys to troubleshoot this for you.
- Keycode (Site or Parent):
- DNS-P agent version you are running on.
- How many machines having impacts ?
- Contact email/phone:
- Best date/time to contact
Thanks
-Kiran
Product Mgr, DNS.
Thank you for the note - I (PM) would like to work with you to ensure we resolve this for you. Can you please provide me with some details and I'll have our support team reach out to you guys to troubleshoot this for you.
- Keycode (Site or Parent):
- DNS-P agent version you are running on.
- How many machines having impacts ?
- Contact email/phone:
- Best date/time to contact
Thanks
-Kiran
Product Mgr, DNS.
Sorry, but I resolved this by turning off WebRoot DNS filtering on the affected machine after seeing it occur multiple times. My clients are not beta testers for WebRoot. When I see some possible causes and solutions for this issue I may revisit it. Or more likely move them to another solution.
Hi
We are also seeing the same issue with a number of our customers using the DNS filtering Service as their roaming client - Since the last update where the DNS IP Address has changed to the loopback address customers are complaining about loss of Internet connection and also access to network resources such as Mapped Drives and Redirected Folders - so Group Policy is not being applied due to this..
I already have a ticket open with support (#152919) and for the moment have also had to disable the DNS Filtering policy until a fix is found
Rob
We are also seeing the same issue with a number of our customers using the DNS filtering Service as their roaming client - Since the last update where the DNS IP Address has changed to the loopback address customers are complaining about loss of Internet connection and also access to network resources such as Mapped Drives and Redirected Folders - so Group Policy is not being applied due to this..
I already have a ticket open with support (#152919) and for the moment have also had to disable the DNS Filtering policy until a fix is found
Rob
SmoothRob, Thanks for chiming in. Please update us if a solution is found for this issue in your case.
No problems - have you also noticed any of the DNS filtering Clients now getting blank DNS Server addresses on the NIC?
Tjhe IPv4 Properties on the NIC are set to "Use the following DNS Server Address" - which before the last Webroot update was always the IP Address of the PC to allow the DNS filering service to "proxy" the request - it seems the latest version now changed that DNS address to the 127.0.0.1 Loopback, and this is where the problems arised. Now today we are seeing customers calling in with the DNS Server Address missing! So, have had to talk a number of customers through the process to set the DNS to Obtain Automatically to allow the machines to connect again..
Rob
Tjhe IPv4 Properties on the NIC are set to "Use the following DNS Server Address" - which before the last Webroot update was always the IP Address of the PC to allow the DNS filering service to "proxy" the request - it seems the latest version now changed that DNS address to the 127.0.0.1 Loopback, and this is where the problems arised. Now today we are seeing customers calling in with the DNS Server Address missing! So, have had to talk a number of customers through the process to set the DNS to Obtain Automatically to allow the machines to connect again..
Rob
In the cases I saw, the IPv4 DNS address was manually set to another address within the LAN, but not the computer's address, and not an address assigned to any other device on the network. Ex: Computer's IP - 192.168.0.5, DNS address - 192.168.0.8, where it was normally "Automatic" as you pointed out.
After seeing that in conjuction with the no surf condition, I shutdown DNS filtering and no more issues. Never saw the loopback address or a blank address field for the DNS setting. But as you say, that was after an update.
After seeing that in conjuction with the no surf condition, I shutdown DNS filtering and no more issues. Never saw the loopback address or a blank address field for the DNS setting. But as you say, that was after an update.
This morning, on a computer on which WebRoot DNS Filtering had been turned off last week, the DNS address had been set to "Manual" and the address was the same IP as the computer. And the computer ws unable to communicate with the internet due to a failure of DNS.
Doesn't WebRoot check in with the mothership every 24 hours? Why are the DNS settings contuing to be changed on the client?
WebRoot may need to be removed and replaced with something else. I can't keep revisiting this issue with clients even after DNS Filtering has been turned off.
Doesn't WebRoot check in with the mothership every 24 hours? Why are the DNS settings contuing to be changed on the client?
WebRoot may need to be removed and replaced with something else. I can't keep revisiting this issue with clients even after DNS Filtering has been turned off.
Hi everyone,
After reviewing the logs from those impacted customers, I want to provide some insight into what caused the loss of connectivity on select devices. This occurred due to the time the OS takes to make the NIC available. On those select devices, we saw that the NIC was made available after the new agent had started. We are working on and testing the timing of NIC availability by putting in extra fail-safe measures and we will have a patch build very soon. In the meantime, there’s a manual workaround to fix the issue:
I assure you that this was an isolated event that occurred only on select devices and has nothing to do with the new agent moving to loopback address.
I understand the impact this has caused you. That's why I would like to ask that you please contact our expert Support team to resolve your situation or send me your contact details and I will have our Support team contact you.
Thank you,
Kiran Kumar
DNS Product Manager
After reviewing the logs from those impacted customers, I want to provide some insight into what caused the loss of connectivity on select devices. This occurred due to the time the OS takes to make the NIC available. On those select devices, we saw that the NIC was made available after the new agent had started. We are working on and testing the timing of NIC availability by putting in extra fail-safe measures and we will have a patch build very soon. In the meantime, there’s a manual workaround to fix the issue:
- Stop the DNS-P service from the service manager
- Set the DNS settings to Dynamic (DHCP)
- Restart the DNS-P service from the service manager
I assure you that this was an isolated event that occurred only on select devices and has nothing to do with the new agent moving to loopback address.
I understand the impact this has caused you. That's why I would like to ask that you please contact our expert Support team to resolve your situation or send me your contact details and I will have our Support team contact you.
Thank you,
Kiran Kumar
DNS Product Manager
Hi everyone,
After reviewing the logs from those impacted customers, I want to provide some insight into what caused the loss of connectivity on select devices. This occurred due to the time the OS takes to make the NIC available. On those select devices, we saw that the NIC was made available after the new agent had started. We are working on and testing the timing of NIC availability by putting in extra fail-safe measures and we will have a patch build very soon. In the meantime, there’s a manual workaround to fix the issue:
I assure you that this was an isolated event that occurred only on select devices and has nothing to do with the new agent moving to loopback address.
I understand the impact this has caused you. That's why I would like to ask that you please contact our expert Support team to resolve your situation or send me your contact details and I will have our Support team contact you.
Thank you,
Kiran Kumar
DNS Product Manager
After reviewing the logs from those impacted customers, I want to provide some insight into what caused the loss of connectivity on select devices. This occurred due to the time the OS takes to make the NIC available. On those select devices, we saw that the NIC was made available after the new agent had started. We are working on and testing the timing of NIC availability by putting in extra fail-safe measures and we will have a patch build very soon. In the meantime, there’s a manual workaround to fix the issue:
- Stop the DNS-P service from the service manager
- Set the DNS settings to Dynamic (DHCP)
- Restart the DNS-P service from the service manager
I assure you that this was an isolated event that occurred only on select devices and has nothing to do with the new agent moving to loopback address.
I understand the impact this has caused you. That's why I would like to ask that you please contact our expert Support team to resolve your situation or send me your contact details and I will have our Support team contact you.
Thank you,
Kiran Kumar
DNS Product Manager
Hello @
Hopefully the message I just posted reg. the loss of connectivity on select machine helps understand the root cause of the issue. At this point, I think it may be best we have our support team look into it and assist you. You mention above that you have have uninstalled/stopped DNS-P and in that case Webroot DNS-P should not be interferrring with the settings.
Again, My offer stands for assistance. Pls. Let me know how we can help.
Thanks
-Kiran
Hopefully the message I just posted reg. the loss of connectivity on select machine helps understand the root cause of the issue. At this point, I think it may be best we have our support team look into it and assist you. You mention above that you have have uninstalled/stopped DNS-P and in that case Webroot DNS-P should not be interferrring with the settings.
Again, My offer stands for assistance. Pls. Let me know how we can help.
Thanks
-Kiran
Hi - I'm new to the community, but have joined because some of my users are having the same problem.
We have Endpoint Security with DNS Protection enabled.
Users that are on desktop computers don't have any issues at all, but I have one user on a laptop that is quite mobile and works from wherever he can get a wifi connection. His laptop has all sorts of website resolution issues.
I logged into his computer this morning and noticed the Primary DNS was now using 127.0.0.1 instead of the local IP like it used to. This shows as no DNS server however.
I manually added the 45.54... addresses and 8.8.8.8 as additional DNS servers. Did a Webroot SecureAnywhere DNS Protection Agent service restart, did the ipconfig /flushdns and tried the problem websites again... nothing!
So I changed the IPv4 config DNS servers from manual to automatic and it got the DNS of the local internet gateway. Service restart, flushdns and still nothing!
So I just stopped the service entirely, flushdns and all of a sudden everything starts working perfectly! However, no DNS filtering and restricted sites are accessible.
So why does the service seem to be the issue?
Why not just set the DNS servers to the 45.54... ones and do away with the service altogether?
Anyway - is there going to be a fix for this issue soon?
We have Endpoint Security with DNS Protection enabled.
Users that are on desktop computers don't have any issues at all, but I have one user on a laptop that is quite mobile and works from wherever he can get a wifi connection. His laptop has all sorts of website resolution issues.
I logged into his computer this morning and noticed the Primary DNS was now using 127.0.0.1 instead of the local IP like it used to. This shows as no DNS server however.
I manually added the 45.54... addresses and 8.8.8.8 as additional DNS servers. Did a Webroot SecureAnywhere DNS Protection Agent service restart, did the ipconfig /flushdns and tried the problem websites again... nothing!
So I changed the IPv4 config DNS servers from manual to automatic and it got the DNS of the local internet gateway. Service restart, flushdns and still nothing!
So I just stopped the service entirely, flushdns and all of a sudden everything starts working perfectly! However, no DNS filtering and restricted sites are accessible.
So why does the service seem to be the issue?
Why not just set the DNS servers to the 45.54... ones and do away with the service altogether?
Anyway - is there going to be a fix for this issue soon?
Hello @
Thanks for the note. Setting the servers manually is not ideal as we are constantly looking at new infrastructures and you will have to update it. Let's address the issue you are facing first as I can assure you there's defty something going on (caching, etc) .. so if I can pls ask you to contact our support .. so that we can help you. Else please provide me your contact details and I'll have our suppor team reach out to you.
Support contact #:
https://tel:+18662548400
Thanks
-Kiran
Thanks for the note. Setting the servers manually is not ideal as we are constantly looking at new infrastructures and you will have to update it. Let's address the issue you are facing first as I can assure you there's defty something going on (caching, etc) .. so if I can pls ask you to contact our support .. so that we can help you. Else please provide me your contact details and I'll have our suppor team reach out to you.
Support contact #:
https://tel:+18662548400
Thanks
-Kiran
@ , There is definitely something going on and it is definitley not isolated to rdodds computers. It's affecting others as well.And while it may not be ideal to set the servers manually, what would be ideal is if the DNS Filtering service worked reliably, or at all on the affected systems. WebRoot's "ideal" is a complete failure of the service on the affected systems.
And what is support going to have rdodds do that has not alredy been sated in his/her posts? Remove and re-install? Send logs? Flushing of the cache and restarting of the service has been done multiple times.
Our "Ideal" would be to see this thread die a slow death because WebRoot resolved the core issue and no one is coming here as a result of DNS Filtering failures.
Yes, I am still frustrated that WebRoot rolled out such a half baked product over a year ago now and we're still discussing this issue.
HI, This is a rather old thread, we rolled out DNS P to our client base about 3 months ago and have seen multible problems with the DNS P agent. Sometimes people boot up there laptop and have no DNS resolution at all for about 5 minutes, others have no issues.
Another issue I have spotted is that even though DNS is working if you perform an nslookup it works! but you can't resolve anything on the local domain in the office correctly, then all of a sudden the problem disappears.
Some other users will randomly get resolution to internet sites but not internal and vice versa on random occasions.
We like the product but it is flakey, we have it rolled out to 900 PCs and we see probably a few a day with the issue.
Generally it seems as though the DNS P agent crashes alot which can cause a lot of strange issues for users
Another issue I have spotted is that even though DNS is working if you perform an nslookup it works! but you can't resolve anything on the local domain in the office correctly, then all of a sudden the problem disappears.
Some other users will randomly get resolution to internet sites but not internal and vice versa on random occasions.
We like the product but it is flakey, we have it rolled out to 900 PCs and we see probably a few a day with the issue.
Generally it seems as though the DNS P agent crashes alot which can cause a lot of strange issues for users
Hello @
Thank you for the note and appreciate your feedback. While I can understand your comment around reliability, lots of times the connection to network matters a lot since we use the loopback address and we rely on the OS to identify the network. I am happy to work with you on some of those m/c where you are seeing issues. Please let me know and I'll get some time set up as we are committed to making this work for you.
Can you please private message me with your SiteKeycode and parent keycode?
thanks
-Kiran
Thank you for the note and appreciate your feedback. While I can understand your comment around reliability, lots of times the connection to network matters a lot since we use the loopback address and we rely on the OS to identify the network. I am happy to work with you on some of those m/c where you are seeing issues. Please let me know and I'll get some time set up as we are committed to making this work for you.
Can you please private message me with your SiteKeycode and parent keycode?
thanks
-Kiran
Hi @
I am unable to PM you as I get the following message
You have reached the limit for number of private messages that you can send for now. Please try again later.
I have never sent a PM on this forum before?
I am unable to PM you as I get the following message
You have reached the limit for number of private messages that you can send for now. Please try again later.
I have never sent a PM on this forum before?
Wizzkidy,
There are other DNS filtering services available which are stable, less expensive and just simply work. I trialed the WebRoot DNS Protection fiasco, and experienced the same issues as you. I have been on another service which requires an agent only for mobile devices, and is IP or host based for fixed localized networks. I've been running it on 6 different networks for two years without a single failure of DNS services. And it has excellent reporting of total requests, blocked and allowed sites.
Why is this thread still active after 5 months? Because WebRoot DNS Protection was not finished when it was introduced, and whatever core issue is causing the service failures is either not repaired or is unrepairable.
There are other DNS filtering services available which are stable, less expensive and just simply work. I trialed the WebRoot DNS Protection fiasco, and experienced the same issues as you. I have been on another service which requires an agent only for mobile devices, and is IP or host based for fixed localized networks. I've been running it on 6 different networks for two years without a single failure of DNS services. And it has excellent reporting of total requests, blocked and allowed sites.
Why is this thread still active after 5 months? Because WebRoot DNS Protection was not finished when it was introduced, and whatever core issue is causing the service failures is either not repaired or is unrepairable.
Hi @ ,
You should be able to send a PM, so I am troubleshooting for you. I just sent you a test message.
Thanks!
You should be able to send a PM, so I am troubleshooting for you. I just sent you a test message.
Thanks!
Well I was contacted by someone who seemed interested with the issue, I sent an email to this person with logs attached from a workstation with the issue, then all has gone quiet for weeks, I have chased twice over the last 3 weeks but no response back at all.
Am thinking more and more that this either cannot be fixed or I am being ignored for other reasons. May start looking at other products for next year.
Am thinking more and more that this either cannot be fixed or I am being ignored for other reasons. May start looking at other products for next year.
Sorry to necro this thread
We are having a similar problem with RRAS servers losing DNS settings when using DNS protection. The NIC will randomly lose DNS setting then VPN users get no DNS at all - since they are set to automatic. The end point initiating the VPN has DNS protection as well.
So far the only 2 solutions are to manually assign the DNS on the client VPN or uninstall DNS protection from the server.
Thoughts?
Hello
Since this an old thread I will ping a couple of Webroot Business experts and they will reply most likely during the week.
Thanks,
Thanks - doing some more internal research - this seems to only happen on DNS servers - which is usually the DC on our managed networks.
Here is what is looks like when it happens - the DNS setting on the NIC is just blank (we found another one this morning)
Even after we set the IP again, it often is blank again after a few minutes. We have to add the DNS several times - sometimes 3 or 4 times before it finally keeps the setting.
Sometimes, it never sticks and we have uninstall DNS filtering completely.
Sometimes, this happens: we set the preferred DNS and it moves it to the Alternate and adds loopback to preferred.
Even when we manually add the DNS in this way - it still doesn't always take on some servers and still blanks it out.
Some servers are fine for weeks and then just lose the setting -apparently at random. We find out then when other things break (DNS is kinda important on a server ) :-)
If so, that’s not a good practice as the WR DNS Protection Service will conflict with the existing AD servers DNS and is definitely not a best practice we recommend. In essence, you’re creating contention between two DNS services and will cause the system to be unstable.
https://download.webroot.com/WSA_DNSProtection_AdminGuide.pdf - Page 5 (This guide is being updated, but the update will say the same about servers. Terminal servers are supported, but any server running existing AD or DNS should NOT have the WR DNS Protection enabled.)
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.