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):
nslookup -type=SRV _mongodb._tcp.cluster0.abcdefg.mongodb.net
<REDACTED INFO>
** server can't find _mongodb._tcp.cluster0.abcdefg.mongodb.net: NXDOMAIN
Using the DNS seed list connection format with the invalid SRV record above in Compass results in the querySrv ENOTFOUND error:
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.