About the solution detailed in the link, I tried formatting the string as instructed (using the mongodb protocol and a lista of the URLs for each shard separated by a comma) but still can’t get a connection (it does seem to be able to resolve the IP address, though).
Current Mongosh Log ID: 6166f8446f2747e87b767609
Connecting to: mongodb://<credentials>@cluster0-shard-00-00.c0tbu.mongodb.net:27017,cluster0-shard-00-01.c0tbu.mongodb.net:27017,cluster0-shard-00-02.c0tbu.mongodb.net:27017/test
MongoServerSelectionError: connection <monitor> to 22.214.171.124:27017 closed
I also tried to connect to the Covid19 DB as suggested by Maxime but get the same error.
However, I found out that I do can connect through mongoshell
Current Mongosh Log ID: 61680c1143666d0fa2a10a77
Connecting to: mongodb+srv://<credentials>@covid-19.hip2i.mongodb.net/covid19
Using MongoDB: 4.4.9
Using Mongosh: 1.1.0
For mongosh info see: https://docs.mongodb.com/mongodb-shell/
Atlas covid-19-shard-0 [primary] covid19>
So I’m guessing I can work through here, but if you have any further idea on why the connection though Compass isn’t working I’d love to hear, as I’d rather work that way if possible.
What’s your OS & are you up-to-date ? Looks like there is definitely something wrong with your Internet connection. Are you behind a VPN maybe? Firewall? Or maybe it’s just a DNS issue as @steevej suggested.
Can you try a different internet connection & disable everything than can cause connection issues? Antivirus software can block connections sometimes as well. If it works reactive them one by one and eliminate the troublemaker !
Your work probably disabled connections to port 27017 or maybe they have even more restrictive rules in place. You need to talk to your IT support. Pity that your work system & network doesn’t allow you to work . I guess they are just missing an exception on this port in their gateway rules. But I’m not an expert .
This is happening to me now after Windows automatically updated to version 10.0.19042 Build 19042.
Last night things were working fine, got up today and my machine had restarted & updated. Skipped Windows 11 spam at startup, started up my dev environment in WSL1 like always, and now I can’t work. Anyone else experiencing this?
I can connect with Compass just fine.
I’m not connected to VPN (which does mess up connections to Atlas, although with a different error). Until today I have never seen the error in OP’s post.
telnet portquiz.net 27017 is failing, so I’m guessing something in the Windows update affected Windows Defender.
Having run into a host of issues using private endpoints, some or most self inflicted, I have come the assumption that the “Error: querySrv ENOTFOUND” has to do with the inability of the driver to resolve a FQDN of the “mongodb+srv” to names of the replica set members.
The error generally indicates the FQDN for the associated host(s) for the SRV record were not able to be resolved by the DNS in use.
As of the time of this message, the SRV record prefix for Atlas clusters is _mongodb._tcp.
Below is a reproduction that shows this error. Let’s say I have a cluster which has an associated SRV record which resolves to the following hostnames:
nslookup -type=SRV _mongodb._tcp.cluster0.k0ke7qa.mongodb.net
_mongodb._tcp.cluster0.k0ke7qa.mongodb.net service = 0 0 27017 ac-omkxrjv-shard-00-00.k0ke7qa.mongodb.net.
_mongodb._tcp.cluster0.k0ke7qa.mongodb.net service = 0 0 27017 ac-omkxrjv-shard-00-01.k0ke7qa.mongodb.net.
_mongodb._tcp.cluster0.k0ke7qa.mongodb.net service = 0 0 27017 ac-omkxrjv-shard-00-02.k0ke7qa.mongodb.net.
Although not exactly the case for all similar errors generated and only for demonstration purposes, I will pass through an invalid SRV record (to some degree attempt to mimic the DNS being unable to resolve the SRV records):
In conclusion, the error querySrv ENOTFOUND was caused by DNS resolving issues, likely from the client side. Also as several people have noted in this thread, if you’re using VPN and encountering this issue only on the VPN (i.e. Connection works fine without querySRV error outside of the VPN connection) then it is probably due to how the VPN is configured. To my knowledge there are some VPN’s which assign a new DNS for the VPN session which could result in this error.