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.