mongodb dump fails with cannot unmarshal DNS message

Question

I am using a mongo db server version MongoDB shell version v4.0.16 installed on a EC2 instance.

I am able to get into the instance using mongo command

mongo mongodb+srv://dxxxxxxx:xxxxxx[][]@cluster0-vxcen.gcp.mongodb.net 
MongoDB shell version v4.0.16
connecting to: mongodb://cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017/?authSource=admin&gssapiServiceName=mongodb&replicaSet=Cluster0-shard-0&ssl=true
2020-03-05T09:02:45.265+0000 I NETWORK  [js] Starting new replica set monitor for Cluster0-shard-0/cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017
2020-03-05T09:02:45.604+0000 I NETWORK  [ReplicaSetMonitor-TaskExecutor] Successfully connected to cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017 (1 connections now open to cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017 with a 5 second timeout)
2020-03-05T09:02:45.607+0000 I NETWORK  [js] Successfully connected to cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017 (1 connections now open to cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017 with a 5 second timeout)
2020-03-05T09:02:45.707+0000 I NETWORK  [js] changing hosts to Cluster0-shard-0/cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017,cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 from Cluster0-shard-0/cluster0-shard-00-00-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-01-vxcen.gcp.mongodb.net.:27017,cluster0-shard-00-02-vxcen.gcp.mongodb.net.:27017
2020-03-05T09:02:46.010+0000 I NETWORK  [js] Successfully connected to cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-00-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
2020-03-05T09:02:46.028+0000 I NETWORK  [ReplicaSetMonitor-TaskExecutor] Successfully connected to cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-01-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
2020-03-05T09:02:46.439+0000 I NETWORK  [js] Successfully connected to cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 (1 connections now open to cluster0-shard-00-02-vxcen.gcp.mongodb.net:27017 with a 5 second timeout)
Implicit session: session { "id" : UUID("1c7432d5-e09c-45f8-8d84-d47e4f572cbf") }
MongoDB server version: 4.2.3
WARNING: shell and server versions do not match
Error while trying to show server startup warnings: user is not allowed to do action [getLog] on [admin.]
MongoDB Enterprise Cluster0-shard-0:PRIMARY> 

I am trying to connect to a mongo db Atlas to get the database using mongodump

mongodump --uri="mongodb+srv://dxxxxxxx:xxxxxx[][]@cluster0-vxcen.gcp.mongodb.net/xxxxxxxxxx"

I am facing issues with

error parsing command line options: error parsing uri (mongodb+srv://dxxxxxxx:xxxxxx[]@cluster0-vxcen.gcp.mongodb.net/xxxxxxxxxx): lookup cluster0-vxcen.gcp.mongodb.net on 127.0.0.53:53: cannot unmarshal DNS message

Musjid

What is your OS? Also try to login with mongo --uri="URI HERE", should give same error. Check if this helps you – Hydrolysate

Answer 1

This is just a case of incompatible DNS server.

Locate /etc/resolv.conf file and replace the nameserver with 8.8.8.8, and everything should work just fine. If that does not work , try 1.1.1.1.

Gilbertgilberta

On Ubuntu 18.04 this is /etc/resolv.conf – Mongo

This was helpful to me - thank you. On MacOS you can set this by going to System Preferences --> Network --> Advanced then click on the DNS button. Add both 8.8.8.8 and 1.1.1.1 and it should work. – Shogun

This fixed my problem while trying to connect using the Go driver. I'm curious as to what this change actually did though. Are there security implications that I should be aware of? – Knave

This is so helpful! I was going nuts trying to solve this until I found this answer! – Gaudreau

Answer 2

This issue is simmilar to the one reported here. The fix for changing resolv.conf as above seems not to persist reboots. The workaround proposed in the link above is either to use non srv url, or, a simpler way that and as far as I have seen survives reboots as well, is to remove the symlink /etc/resolve.conf and replace it with a static file containing the required DNS server.

Another option, found here Suggests installing resolvconf (for Ubuntu apt install resolvconf), add the line nameserver 8.8.8.8 to /etc/resolvconf/resolv.conf.d/base, then run sudo resolvconf -u and to be sure service resolvconf restart. To verify run systemd-resolve --status.

You should see on the first line your DNS server like here:

         DNS Servers: 8.8.8.8
          DNS Domain: sa-east-1.compute.internal
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa

Hosea

Answer 3

Two solutions that worked for me:

1. Add nameserver with value 8.8.8.8 or 1.1.1.1 additionally to existing ones in /etc/resolve.conf file
2. Use connection string in format mongodb://{db}:{pass}@hostname1.mongodb.net,hostname2.mongodb.net,hostname3.mongodb.net/admin?authSource=admin&replicaSet={replicaSet}&readPreference=primary&ssl=true instead of mongodb+srv:// format

To get the formatted connection string, you can use db.getMongo() command on your cluster

Schertz

Answer 4

In some causes, for example in environment where you can't change resolver you can use old style URL:

client = pymongo.MongoClient("mongodb://<username>:<password>@<cluster>...

After change URL generated by cloud.mongodb.com Atlas in section Cluster -> Connect -> Choose a connection method -> Python - 3.4 or later

It finally started working.

My setup:

• Ubuntu 18.04
• Python 2.7.17 / 2.7.12
• Pymongo 3.11.1
• Google Cloud SDK 319.0.0

Romeyn

this worked for me also in CLI: mongodump "<string generated by cloud.mongodb.com>" but this is not the best solution because this uri is obsolete – Egalitarian

Answer 5

In my case, only MongoDB connections went wrong with my DNS server. However, it worked with Google DNS 8.8.8.8, as suggested above. The solution for me was to decrease the UDP max packet size (same as Google DNS)

cat /etc/bind/named.conf.options
options {
    #...
    listen-on { 127.0.0.1; };
    allow-recursion { 127.0.0.1; ::1; };
    edns-udp-size 512;
    max-udp-size 512;
};

Silverfish