-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS/Linux - DNS Failing when connected to a VPN #253
Comments
Same with me... |
This indicates that the default resolvers are not reachable and you should set resolvers that can be used within your environment. This can be achieved using the ‘-r’ and/or ‘-rf’ flags |
Hi @caffix, thanks for the response! I should have mentioned that I did try passing in resolvers and still somehow got the same error. I took the resolvers directly from the etc/resolv.conf file (including the ones that my VPN automatically adds when it connects), and tried a bunch of different ones with the same results. So, that is pretty odd and led me to come across this: Apparently there have been issues reported with Golang DNS resolution behind VPNs on Mac before - the procedure in that article didn't work for me, but I did some more research and found this older issue: Specifically this response:
This issue is from 2015, so I'm not sure if this could still be related - it also only mentioned macOS, while I'm having the issue on Ubuntu as well (and I can see that my VPN is updating the resolv.conf file on Ubuntu). I had originally downloaded Amass directly in the binary form, so I did try to compile Amass myself with the CGO_ENABLED flag with no luck, though I will admit I've never coded with Go myself so I may have been doing something wrong (I'm going to play around with it this week and see if I have any luck). Anyway, I'm still not sure if this issue is actually an issue with Amass itself, so I'm not expecting you guys to have a solution - if it does turn out to be a problem with Golang and the OS DNS settings itself, that would make sense to me since dig, nslookup, dnspython, etc are still working. If I do end up figuring this out, I will let you guys know! Also, @syedumercg - are you also using ExpressVPN specifically? I did turn off their setting 'Only use ExpressVPN DNS servers while connected", but I guess it could be possible that there is some problem with the VPN itself (although that wouldn't explain why dnspython and other command line lookups still work). Thanks! Update: Adding some screenshots of what's going on using Ubuntu (10.21.0.1 is one of ExpressVPN's DNS servers - when I connect to the VPN it automatically updates the resolvers.conf file) |
Hi! Not sure if anyone is still looking at this, but I had been having the same problem on a Mac with the 'No DNS Resolvers passed the sanity check' message. However, I just updated to Amass 3.1.9 and am now getting an interesting error:
I've honestly never used golang before, but I'm going to try and look into what's going wrong - it seems like it is an issue with Amass not being able to locate any valid DNS servers. I'll post an update if I find anything! |
@allyomalley Thank you very much for your help! I have a small fix coming in v3.1.10 |
Hi, I'm using amass v3.1.10 on macos and have a similar issue when connected to a VPN (tested with Private Internet Access). I get the error "The enumeration was unable to build the pool of resolvers" even when explicitly specifying PIA's DNS resolvers using the -r flag. |
having the same issue here i have looked for anyway around this but with -r is just does not return anything and with -rf it gives me Failed to parse the esolver file: Error opening the file 10.161.0.1: open 10.161.0.1: no such file or directory @caffix is there anyway around this issue?would love to know thank you in advance. |
Same problem with Mullvad DNS |
@spazbg You experienced a problem when using a VPN? Or, are you referring to something else? Also, what version of Amass are you using? |
I have Mullard installed on my Windows 10 host, and I have Kali Linux on a Virtual box, I have the latest version of amass, and when I run it on my Kali machine a got no results. If I stopped my VPN on my windows 10, Amass is working perfectly on my Kali machine. |
This issue has likely been addressed while resolving #444 |
I still get this issue with Mullvad on MacOS 😢 |
I started seeing the "The system was unable to build the pool of resolvers" error for the first time in the last couple weeks. I'm running Kali 2020.4 update 1 on VirtualBox, Amass now updated to v3.11.2, and I'm using Private Internet Access VPN. While connected to the PIA VPN and running I reconnected to PIA VPN, ran |
Hi,
I've been struggling with this for a while and was wondering if anyone here had already solved this issue before. When I connect to my VPN (I am using ExpressVPN specifically) and try to run Amass with active enumeration, I get back the '
No DNS resolvers passed the sanity check
' error. At first I thought this was an issue with my system/DNS configuration and not Amass itself - but I noticed that DNS lookups via the command line, in browsers, all worked fine, and I also wrote a quick script with dnspython and confirmed that that all seems to be working too - so now I'm wondering if this is an issue with Amass, or perhaps something to do with golang in general?I also tried the same thing on Linux - same VPN and all, and I get back the same error. On Linux I've tried adding Google's NS to the etc/resolv.conf file, and still no luck - similarly in Mac I added 8.8.8.8 to my DNS servers in System Preferences with no luck. I'm going to try installing by building from source and see if that changes anything, but I'm not hopeful.
The reason I'd really like to get this working is that I seem to get rate limited by either the DNS servers or my ISP pretty quickly whenever I try to use brute force mode, even when I lower the max concurrent DNS queries setting. Has anyone seen this before, or have any insight into why this might be happening?
Thanks in advance!
The text was updated successfully, but these errors were encountered: