go: net: "cannot unmarshal DNS message" for SRV lookup
$ go version go version go1.13.1 darwin/amd64
Does this issue reproduce with the latest release?
Yep.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env➜ ~ go env GO111MODULE=“” GOARCH=“amd64” GOBIN=“/Users/$USER/go/bin” GOCACHE=“/Users/$USER/Library/Caches/go-build” GOENV=“/Users/$USER/Library/Application Support/go/env” GOEXE=“” GOFLAGS=“” GOHOSTARCH=“amd64” GOHOSTOS=“darwin” GONOPROXY=“” GONOSUMDB=“” GOOS=“darwin” GOPATH=“/Users/$USER/go” GOPRIVATE=“” GOPROXY=“https://proxy.golang.org,direct” GOROOT=“/usr/local/go” GOSUMDB=“sum.golang.org” GOTMPDIR=“” GOTOOLDIR=“/usr/local/go/pkg/tool/darwin_amd64” GCCGO=“gccgo” AR=“ar” CC=“clang” CXX=“clang++” CGO_ENABLED=“1” GOMOD=“” CGO_CFLAGS=“-g -O2” CGO_CPPFLAGS=“” CGO_CXXFLAGS=“-g -O2” CGO_FFLAGS=“-g -O2” CGO_LDFLAGS=“-g -O2” PKG_CONFIG=“pkg-config” GOGCCFLAGS=“-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wg/8x33rs4j5d7bgr5z58_4ql0m0000gn/T/go-build827220434=/tmp/go-build -gno-record-gcc-switches -fno-common”
What did you do?
I compiled the following program and executed the resultant program on an AWS EC2 instance passing the URI specified by the package vendor’s documentation.
package main
import (
"context"
"flag"
"log"
"time"
"go.mongodb.org/mongo-driver/mongo"
"go.mongodb.org/mongo-driver/mongo/options"
"go.mongodb.org/mongo-driver/mongo/readpref"
)
func main() {
uri := flag.String("uri", "mongodb://localhost:27017", "URI of the mongo server of interest")
flag.Parse()
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
client, err := mongo.Connect(ctx, options.Client().ApplyURI(*uri))
if err != nil {
log.Fatalf("connection error: %s", err)
}
if err := client.Ping(ctx, readpref.Primary()); err != nil {
log.Fatalf("pinging error: %s", err)
}
log.Println("exiting")
}
Compiled on my MacBook Pro using different go versions, all the way to gotip version
go version devel +ccb95b6492 Fri Feb 21 05:04:06 2020 +0000 darwin/amd64
Compiled using GOOS=linux GOARCH=amd64 go build . since I’m building for an Ubuntu 18.04 EC2 instance.
I then scped the binary to the remote machine.
What did you expect to see?
Using the mongo client binary to connect succeeds with proper DNS resolution. So, I expected that…
What did you see instead?
After sshing to the remote box I executed
./mongoConnectTest -uri=mongodb+srv://$USER:$PASSWORD@$HOST/$TESTDB
and received the following error.
2020/02/21 17:28:56 connection error: error parsing uri: lookup $HOST on 127.0.0.53:53: cannot unmarshal DNS message
Notes
I’m using a DNS seedlist provided by an SRV record to access a cluster of machines exposing a mongo interface to me. The documentation for that DNS resolution process by which a list of hostname:port pairs and connection options are acquired is here.
This problem seems related to net’s inability to parse the resolved DNS entries. So, I’ve included the relevant DNS records below.
SRV record
ubuntu@ip-172-31-32-188:~$ dig SRV _mongodb._tcp.staging-vduzy.mongodb.net
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> SRV _mongodb._tcp.staging-vduzy.mongodb.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4811
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_mongodb._tcp.staging-vduzy.mongodb.net. IN SRV
;; ANSWER SECTION:
_mongodb._tcp.staging-vduzy.mongodb.net. 60 IN SRV 0 0 27017 staging-shard-00-02-vduzy.mongodb.net.
_mongodb._tcp.staging-vduzy.mongodb.net. 60 IN SRV 0 0 27017 staging-shard-00-00-vduzy.mongodb.net.
_mongodb._tcp.staging-vduzy.mongodb.net. 60 IN SRV 0 0 27017 staging-shard-00-01-vduzy.mongodb.net.
;; Query time: 9 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Feb 21 17:39:47 UTC 2020
;; MSG SIZE rcvd: 206
TXT record
ubuntu@ip-172-31-32-188:~$ dig TXT staging-vduzy.mongodb.net
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> TXT staging-vduzy.mongodb.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20788
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;staging-vduzy.mongodb.net. IN TXT
;; ANSWER SECTION:
staging-vduzy.mongodb.net. 60 IN TXT "authSource=admin&replicaSet=Staging-shard-0"
;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Feb 21 17:40:15 UTC 2020
;; MSG SIZE rcvd: 110
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 24 (3 by maintainers)
Commits related to this issue
- feat: database — committed to sysu-yunz/fund-minitor by deleted user 4 years ago
For anyone still got this error, it’s happen when you’re using DNS from shared network like coffee shop or mobile phone hotspot. I suggest to use an other “deep” DNS server. As my experiences, I suggest to use WARP from 1.1.1.1 on MAC Ventura. In almost cases, it’s work. iCloud Relay maybe the problem.
Was facing the same issue with
mongo-driverusing Go1.14. Using a loong mongo connection string(without srv) is a temporary fix.This doesn’t sound like a
golangissue, then. It just seems like a DNS issue. Note thatnet.Dialreads/etc/resolve.conf.@ismailyenigul It looks like your DNS resolution using
digworked before you prepended 8.8.8.8 to/resolve.conf. Is that true? If so, then I’m confused.@toothrot I believe we have another user experiencing this issue with the
mongo-driverlibrary using Go1.14. The last comment in #36718 mentions reverting #10622 when the trees open up. Can you give a sense of when this might be fixed? I’m not familiar with the language development process and code freezes.Also, my understanding is that the revert will temporarily solve this issue and #24870 will update the code to correctly follow RFC 6762. Is this correct?