DNS Leak Protection

I recently came to the realization that I was suffering from a DNS leak. I enabled the DNS protection in the client (and it works), but I still have some questions on what I should do. I was giving a warning that DNS leak protection could cause problems and I know that you can manually set your network to use PIA's DNS servers using this method. My question is which one should I do? So far I'm not having any connection issues, but I've noticed the amount of DNS Client warnings (Event ID 1014 - "Name resolution for the name {example} timed out after none of the configured DNS servers responded.)  have doubled since enabling DNS leak protection, especially when I disconnent/connect. I think there's also been an increase in Dhcp-Client errors (eventID 1002).

I've been considering using the above method, but from the instructions it sounds like I can't have the DNS protection feature enabled at the same time (since it says to uncheck it in step 2). Is that really the case?

Would I encounter any problems when using my regular network (PIA disconnected) using the linked method above?

Do I have to reboot every time I enable/disable DNS leak protection in the client like I'd have to in the linked method above? (I haven't rebooted since enabling it so I was wondering if that was the reason for the extra warnings/errors)

Comments

  • Even if there is a leak your sending and receiving is encrypted.
    my system is
    Win10 64 bit, using Opera browser, Windows defender on
    use the default recommendation use PIA DNS settings
    https://helpdesk.privateinternetaccess.com/hc/en-us/articles/219460397-How-to-change-DNS-settings-in-Windows

    check if you are leaking here
    https://ipleak.net
  • That's the article I linked, I was wondering if I should use that or the DNS leak protection that's built into the client. If the one doesn't throw as many errors/warnings I'd rather use that, but I wanted to double check.

    On an unrelated note, is it possible to get my forum account fixed? I created it several months ago and I have yet to receive a confirmation email. I've resent it probably over a hundred times already. I can't even access my profile or PM until I confirm.
  • In that case I'll stick with the DNS leak protection feature. So far I've noticed no connection issues or slow downs. The Dhcp-Client errors and DNS timeout warnings don't seem to be causing any issues and appear to resolve themselves. I've always had them and I'm only just realizing now that they were related to switching between the VPN and regular network. With DNS leak protection enabled the DNS timeout warnings have increased, but considering I was having a DNS leak before that makes sense and is almost a sign the leak has been fixed.
  • Not to discount what PIAJeffery said, but the static DNS assignment is a viable solution. It should be considered if there is any doubt in protecting your DNS request. I personally use PIA DNS in my local machine and my router. There is no doubt that if one of them goes wacko the other will keep me on PIA DNS.

    Do keep your options open.
  • edited January 2018
    I always recommend using the official application over any third-party option because I simply feel safer when using the official application. The application does everything for you so you don’t have to worry about anything unless you want to dive into the advanced settings but I always recommend turning the killswitch and leak protection on to ensure that you are safe.
  • Not to discount what PIAJeffery said, but the static DNS assignment is a viable solution. It should be considered if there is any doubt in protecting your DNS request. I personally use PIA DNS in my local machine and my router. There is no doubt that if one of them goes wacko the other will keep me on PIA DNS.

    Do keep your options open.
    Oh I am and in fact I just started using the static DNS assignment today. I like to use sleep mode and I've noticed that using PIA with DNS leak enabled causes connection issues when coming out of sleep mode. It's not anything serious, but it's the difference between instant reconnection vs waiting a minute for any internet access. It's probably something that can be solved by manual disconnecting before entering sleepmode, but I haven't tried that yet.

    That being said, I wanted to ask if there was any downside to using the static DNS assignment with the VPN disconnected? Does it even make a difference? There's a site I use occasionally that won't let you access with VPNs like PIA and when I tried it with the static DNS it was loading kind of slow. No one else was having this issue. Other webpages didn't really have an issue (some did load a little slow, but only the first time entering the site). I've ruled out my browser as well. This isn't a major issue, I just want to know more about using static DNS in general.
  • No visible down side for me. I use PIA DNS connected or not. I looked at rankings of DNS servers once and although it was rated #1, I could see not difference in response time between my ISP DNS and PIA DNS. So I left well enough alone. My thinking was simple, close any possible loopholes that might get me in trouble. "Trouble" is being used loosely here. LOL
  • No visible down side for me. I use PIA DNS connected or not. I looked at rankings of DNS servers once and although it was rated #1, I could see not difference in response time between my ISP DNS and PIA DNS. So I left well enough alone. My thinking was simple, close any possible loopholes that might get me in trouble. "Trouble" is being used loosely here. LOL
    Also worth keeping in mind however that some ISPs hijack DNS. My former ISP, Bell, used to do this: even if I used PIA's DNS exclusively, a DNS leak test while disconnected still showed their DNS which means that they were redirecting all DNS requests to their servers regardless of the one I had picked.

    I've personally found PIA's DNS to have short blips there and there when used outside of PIA compared to my ISP's DNS, but most OS and browsers also cache DNS records so apart from unknown domains that might take slightly longer to resolve, DNS rarely make a difference in loading times. DNS only affects loading time when you load a big website with lots of external resources to domains you have never resolved before (so the browser has to wait for DNS to know what IP to connect to). Past this initial stage, DNS is out of the way anyway so it won't affect download speeds or anything.

    PIA's DNS is also a bit special as when connected to the VPN in that we run PIA's DNS servers locally on each server, so when you're connected to PIA the DNS is effectively the same server to minimize latency a bit further.


    But yes overall, no issues using PIA's DNS outside of PIA. They're publicly accessible precisely for this purpose :)
  • edited January 2018
    Thanks for all the helpful info. There's something else I wanted to ask. Within 48 hours of using static DNS assignment my Event Viewer got swamped with the DeviceSetupManager warnings
    • 200 A connection to the Windows Update service could not be established.
    • 202 The Network List Manager reports no connectivity to the internet.
    • 201 A connection to the Windows Metadata and Internet Services (WMIS) could not be established.
    I've had these warnings every once in a while in the past, but never at such intensity and for two days in a row. Yesterdays was rather normal like past instances, but today's racked up 128 entries within 6 minutes (all 200 and 202 warnings). I'm not actually experiencing any connection issues or any other issues and there's no errors associated with these events. All my devices and services are working properly. But since changing to a static DNS is the only thing I've done in the past few days I wanted to rule it out, to make sure there isn't another major issue lurking around the corner.

    So is this something switching to a static DNS assignment could cause or should I start looking at other avenues?

    Edit: I've been able to replicate the issue just by manual starting the DeviceSetupManager service/triggering it by installing a new device. The thing is, I can't tell if this an error related to connectivity issues (such as problems connecting to the URL linked in the registry) or an issue with the DeviceSetupManager service itself having problems linking up to other services (ei. Windows Update). My attempts at looking elsewhere has me thinking it's the former. One person who had the "issue" had it go away after reseting their router and modem and thought it was a firewall issue. Other solutions I've seen involved changing the connected URL in the registry to an alt microsoft link (which I have done).

    I apologize if this issue (it isn't really one for now) has nothing to do with the DNS, I'm just ruling out possibilities.

    Edit2: The issue hasn't popped up since, probably because DeviceSetupManager hasn't needed to run and usually only runs periodically. The connection issue itself is probably unrelated to VPN use, but why this service decided to run so long two days in a row is still unknown. It was probably a coincidence that it happened while I was switching to a static DNS assignment.





  • Harry2 said:
    Even if there is a leak your sending and receiving is encrypted.
    my system is
    Win10 64 bit, using Opera browser, Windows defender on
    use the default recommendation use PIA DNS settings
    https://helpdesk.privateinternetaccess.com/hc/en-us/articles/219460397-How-to-change-DNS-settings-in-Windows

    check if you are leaking here
    https://ipleak.net

    ============================
    Hello Harry and others, you should actually use https://whoer.net/ instead to see if you have a DNS leak. I used to rely on
    https://ipleak.net, which always told me I was in the clear. However, it wasn't true. After discovering https://whoer.net/ could find out my real IP etc, I made some changes to both openvpn .ovpn files and Firefox and now as far as I can tell there is no more leakage. I even went as far as changing my MAC-address on regular basis.
Sign In or Register to comment.