First of all, if this is not the right category, please let me know which one is.
I’m new to MongoDB. Made a local deploy and it’s running fine. Now I’m trying to set up an Atlas instance, but can’t seem to be able to connect to it.
I’m trying to use the string
I’ve also tried connecting through mongosh and get the same error
C:\Users\OS16S8898>mongosh “mongodb+srv://cluster0.c0tbu.mongodb.net/myFirstDatabase” --username pdantas
Enter password: *******
Current Mongosh Log ID: 6165e8a56936fb42f0cbf229
Connecting to: mongodb+srv://cluster0.c0tbu.mongodb.net/myFirstDatabase
Error: querySrv ENOTFOUND _mongodb._tcp.cluster0.c0tbu.mongodb.net
I’ve whitelisted my IP, and even added 0.0.0.0/0 to the IP access list, to no avail. Can someone please help me find out what is it that I’m doing wrong?
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).
C:\Users\OS16S8898>mongosh mongodb://pdantas:pdantas@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
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 108.129.24.16:27017 closed
The 2 IPs I provided are not at all related to the white list of your cluster. It has to do with host name resolution, aka DNS. In the link I provided you will find instructions for
Configure your network settings to use the IP addresses 8.8.8.8 and 8.8.4.4 as your DNS servers.
Your ISP or VPN provider probably uses old DNS software that cannot resolve SRV connection strings.
I have just notice that your original post contains 2 different connection strings, one with c0tbu and one with n2hlh.
Try to connect using the above connection string in Compass to see if it works. This is the public cluster where I’m hosting the Open Data COVID-19 data set.
If that doesn’t work - then you have a DNS problem like @steevej explained and you have to add 8.8.8.8 and/or 8.8.4.4 in your DNS list.
For me on linux, I would have to add on the first line of /etc/resolv.conf:
nameserver 8.8.8.8
<keep the former DNS line in here>
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
C:\Users\OS16S8898>mongosh mongodb+srv://readonly:readonly@covid-19.hip2i.mongodb.net/covid19
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
<REDACTED INFO>
Non-authoritative answer:
_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.