Periodic errors unable to resolve go.mongodb.org

Connor_Hillerby · 2025-04-15T06:04:09.978Z

We are receiving periodic errors in our Golang tests where the image build is unable to pull down the mongodb drivers at go.mongodb.org/mongo-driver. The builds only ever fail to pull down from this domain and all the other packages are pulled fine (mostly hosted on github.com). An example error below, slightly redacted:

go.mongodb.org/mongo-driver/bson: unrecognized import path "go.mongodb.org/mongo-driver": https fetch: Get "https://go.mongodb.org/mongo-driver?go-get=1": dial tcp: lookup go.mongodb.org on <internal DNS server>: no such host

I am able to reproduce this locally. I believe the issue actually lies with the MongoDB hosting of their DNS zones, and some failure in replicating their records across the different providers that they use. If you query for the name servers for mongodb.org, you will find that the zones are served by 2 sets of 4 authoritative name servers, AWS and Google Domains. Below are some DNS queries that showcase this - firstly querying for the mongodb.org name servers against the public Google DNS servers returns the 2 sets of name servers a few seconds apart. Next a query for go.mongodb.org specifically against these returned name servers, where the query against the Google Domain server fails to respond but the AWS name server responds successfully. Lastly, querying against the public Google DNS servers returning successfully one time and then failing the next (as the query is sent to one of the 2 sets of name servers, where one fails and the other doesn’t).

$ dig NS +multiline @8.8.8.8 mongodb.org

; <<>> DiG 9.10.6 <<>> NS +multiline @8.8.8.8 mongodb.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;mongodb.org.		IN NS

;; ANSWER SECTION:
mongodb.org.		21600 IN NS ns-cloud-c1.googledomains.com.
mongodb.org.		21600 IN NS ns-cloud-c3.googledomains.com.
mongodb.org.		21600 IN NS ns-cloud-c4.googledomains.com.
mongodb.org.		21600 IN NS ns-cloud-c2.googledomains.com.

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 14 15:03:16 BST 2025


####################################################################################


$ dig NS +multiline @8.8.8.8 mongodb.org

; <<>> DiG 9.10.6 <<>> NS +multiline @8.8.8.8 mongodb.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;mongodb.org.		IN NS

;; ANSWER SECTION:
mongodb.org.		19889 IN NS ns-996.awsdns-60.net.
mongodb.org.		19889 IN NS ns-1409.awsdns-48.org.
mongodb.org.		19889 IN NS ns-466.awsdns-58.com.
mongodb.org.		19889 IN NS ns-1810.awsdns-34.co.uk.

;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 14 15:03:19 BST 2025


####################################################################################


$ dig @ns-cloud-c2.googledomains.com. +short go.mongodb.org
$ dig @ns-466.awsdns-58.com. +short go.mongodb.org
glb.mongodb.com.


####################################################################################


$ dig @8.8.8.8 go.mongodb.org

; <<>> DiG 9.10.6 <<>> @8.8.8.8 go.mongodb.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;go.mongodb.org.			IN	A

;; ANSWER SECTION:
go.mongodb.org.		630	IN	CNAME	glb.mongodb.com.
glb.mongodb.com.	1815	IN	A	52.206.222.245
glb.mongodb.com.	1815	IN	A	52.21.89.200
glb.mongodb.com.	1815	IN	A	54.175.147.155

;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 14 15:16:25 BST 2025


####################################################################################


$ dig @8.8.8.8 go.mongodb.org

; <<>> DiG 9.10.6 <<>> @8.8.8.8 go.mongodb.org
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;go.mongodb.org.			IN	A

;; AUTHORITY SECTION:
mongodb.org.		300	IN	SOA	ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 14 15:16:26 BST 2025
;; MSG SIZE  rcvd: 136

I’m not sure if anyone else as experienced this or if maybe the above is inaccurate, but it’s causing a lot of issues in our automated tests and it would be great if we were able to get a fix for it. At some point we may just have to opt for hosting the package internally where the DNS resolution is more reliable.

Julia_Tazin · 2025-04-15T21:15:50.872Z

Hi @Connor_Hillerby! Thanks for providing the details of your issue. We’re currently looking into this internally.

Connor_Hillerby · 2025-04-23T11:49:13.877Z

Hi Julia, thanks for responding! Do you know if there has been any investigation/progress made on this?

Julia_Tazin · 2025-04-24T18:07:12.146Z

Hi @Connor_Hillerby, we’re still following up internally.

Julia_Tazin · 2025-04-29T15:50:14.638Z

Hi @Connor_Hillerby, we’ve fixed this on our end. Could you retry your scenario and let me know if your issue has been resolved?

Connor_Hillerby · 2025-04-29T16:15:11.896Z

@Julia_Tazin yes my tests are indicating this is fixed, thank you! We’ll be re-enabling our e2e tests shortly but I expect them to be working from here on out, I’ll let you know if otherwise.

Julia_Tazin · 2025-04-29T16:31:55.962Z

Great, let us know if anything else is needed

system · 2025-05-19T11:53:07.224Z

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.