Error: queryTxt ETIMEOUT cluster0.gvnqt.mongodb.net

Sujeet76 — Mon, 16 Jun 2025 04:53:19 +0000

When your ISP Breaks Your MongoDB Connection: A DNS Resolution Nightmare

Picture this: It's a regular Tuesday morning, you grab your coffee, fire up your code editor ready to add that shiny new feature to your app. Everything was working perfectly yesterday, your production build is humming along nicely, and life is good.

Then you try to connect to your MongoDB Atlas cluster and... nothing complete silence.Your heart skips a beat.

The Problem That Made Me Question Everything

Here's exactly what happened. I'd been working on a node.js project that was connecting beautifully to my mongodb atlast cluster. Everything was deployed, users were happy, and I was feeling pretty good about life. But when I sat down to add a new feature. I got slapped with this lovely error:

Error: queryTxt ETIMEOUT cluster0.gvnqt.mongodb.net
    at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/promises:293:17) {
  errno: undefined,
  code: 'ETIMEOUT',
  syscall: 'queryTxt',
  hostname: 'cluster0.gvnqt.mongodb.net'
}

Now this queryTxt timeout error is specifically related MongoDB's SVR(service record) connection string. When you use a mongdb+srv:// connection string. MongoDB need to perform a DNS TXT record lookup to get additional connection options. This error means the DNS query for those TXT records is timing out.

My first instinct? "Oh great, I probably messed up my connection string". We've all been there, right? You stare at the connection string for what feels like an eternity, checking every character, every special symbol. But nope, it was perfect.

The Debugging Rabbit Hole

Like any good developer, I started going through my mental checklist:

Connection string issue? Nope, triple-checked it.
MongoDB Atlas having problems? Their status page looked green.
My code broke somehow? But it was working few day ago!

Then I though, "Let me try my local MongoDB instance." Surely that would work, right? Wrong. Same timeout error. Now I'm starting to panic because this makes no sense what so ever.

That's when the DNS error stated making sense. The queryTxt ETIMEOUT was screaming "DNS resolution problem" but my brain was too focused on MongoDB to notice.

The Lightbulb Moment

Here's where it gets interesting. I remembered that I'd recently switched internet provider(you know how it is, always chasing that better deal). On a whim, I decided to hotspot from my phone and try to connecting again.

Boom. Connected instantly.

That's when it hit me - my new ISP's DNS server couldn't resolve MongoDB's TXT records properly. This is actually a common issue that many developer face. Some ISPs or home networks can block or improperly proxy DNS requests, especially for TXT records that MongoDB's SRV connection string rely on. It wasn't my code, it wasn't MongoDB, it was my internet provider's DNS servers causing the problem or it is because of me. Few days back have have done some experimentation on my router which may cause this issue.

Solution 1 Tried (And What Actually Worked)

What Didn't work:

Switching to localhost connection string: mongodb://localhost:27017/ same timeout because local MongoDB also uses DNS resolution.
Reinstalling MongoDB drivers: Went down this rabbit hole thinking maybe something got corrupted
Restarting everything: You know, the classic "turn it off an on again"

What Actually Worked:

Switching to Google's DNS servers (8.8.8.8 and 8.8.4.4)
This solution works because Google's public DNS servers properly handled the MongoDB's TXT record queries that are essential for SRV connection string. Many ISP DNS servers either block these queries or don't proxy theme correctly.

Here's how I did it on windows

Open Network and Sharing Center
Click on your active connection
Properties -> Internet Protocol Version 4 (TCP/IPV4)
Select "Use the following DNS server address"
Primary: 8.8.8.8, secondary 8.8.4.4

On macOS/Linux, you can add these to your /etc/resolv.conf or use your network manager.

The Real Lesson Here

This whole experience taught me something important: not all connectivity issues are code issue. Sometimes the problem exists at a completely different layer of the stack that you not even think to check.

The queryTxt ETIMEOUT error specifically indicates that your system can't retrieve the DNS TXT records that MongoDB Atlas uses for SRV connection strings. This is a networking/DNS issue, not an application issue.

When you're dealing with timeouts and DNS-related errors, especially after changing your network setup, consider:

ISP DNS limitations: Some ISPs have restrictive or slow DNS servers that don't properly handle TXT record queries
Corporate network restrictions: Company firewalls often block certain DNS record types
Regional DNS issues: Some DNS servers don't properly proxy specific record types
MongoDB SRV requirements: The mongodb+srv:// connection format requires both SRV and TXT record lookups to work properly

Tools That Could Have Saved Me Time

Looking back, I could have diagnosed this faster with:

# Test DNS resolution directly for SRV records
nslookup -type=SRV _mongodb._tcp.cluster0.gvnqt.mongodb.net

# Test TXT record resolution (this is what was failing!)
nslookup -type=TXT cluster0.gvnqt.mongodb.net

# Or use dig for more detailed info
dig TXT cluster0.gvnqt.mongodb.net
dig SRV _mongodb._tcp.cluster0.gvnqt.mongodb.net

# Check what DNS servers you're using
cat /etc/resolv.conf  # Linux/macOS
ipconfig /all         # Windows

If the TXT record query times out or fails, that's your smoking gun for this specific MongoDB issue.

Key Takeaways

The queryTxt ETIMEOUT error is specifically about DNS TXT record resolution - it's not a general connectivity issue
MongoDB SRV connection strings require both SRV and TXT record lookups - if either fails, your connection fails
ISP DNS servers vary wildly in quality and capabilities - some don't properly handle TXT record queries that MongoDB Atlas requires
Test with different networks - mobile hotspot testing is a quick way to isolate DNS-specific problems
Public DNS servers (Google 8.8.8.8, Cloudflare 1.1.1.1) are often more reliable for handling all DNS record types
Alternative solution: You can also use the non-SRV connection string format to bypass TXT record requirements entirely

Have you ever run into weird DNS issues that made you question your sanity?

P.S. - My production app kept working the whole time because the servers were using different DNS resolvers. Always fun when dev breaks but prod keeps humming along!

DEV Community: Sujeet76