Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net: "cannot unmarshal DNS message" for SRV lookup #37362

Closed
johnrichardrinehart opened this issue Feb 21, 2020 · 25 comments
Closed

net: "cannot unmarshal DNS message" for SRV lookup #37362

johnrichardrinehart opened this issue Feb 21, 2020 · 25 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@johnrichardrinehart
Copy link 

$ 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
@toothrot toothrot changed the title [net] "cannot unmarshal DNS message" net: "cannot unmarshal DNS message" for SRV lookup Feb 21, 2020
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 21, 2020
@toothrot toothrot added this to the Backlog milestone Feb 21, 2020
@toothrot
Copy link
Contributor

Thanks for the detailed report. I think this has been seen previously at #10622 and #24870.

From the documentation for "go.mongodb.org/mongo-driver/mongo":

Potential DNS Issues
Building with Go 1.11+ and using connection strings with the "mongodb+srv"[1] scheme is incompatible with some DNS servers in the wild due to the change introduced in #10622. If you receive an error with the message "cannot unmarshal DNS message" while running an operation, we suggest you use a different DNS server.

https://pkg.go.dev/go.mongodb.org/mongo-driver/mongo?tab=doc

It seems like closing this issue in favor of #24870 seems reasonable. Do you agree?

@toothrot
Copy link
Contributor

Also #36718 is related.

@johnrichardrinehart
Copy link
Author

@toothrot Thanks for getting back to me. I should have included the version of the mongo client library that I was using.

➜   cat go.sum | grep mongo
go.mongodb.org/mongo-driver v1.1.3 h1:++7u8r9adKhGR+I79NfEtYrk2ktjenErXM99PSufIoI=
go.mongodb.org/mongo-driver v1.1.3/go.mod h1:u7ryQJ+DOzQmeO7zB6MHyr8jkEQvC8vH7qLUO4lqsUM=

I think the issue may be related to this package. I'm going to run a couple of tests in the next few days and will update if I discover anything.

@divjotarora
Copy link

@toothrot I believe we have another user experiencing this issue with the mongo-driver library 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?

@ladrahul00
Copy link

Was facing the same issue with mongo-driver using Go1.14. Using a loong mongo connection string(without srv) is a temporary fix.

@johnrichardrinehart
Copy link
Author

johnrichardrinehart commented Apr 13, 2020 •
edited
Loading

@toothrot @divjotarora @Wolf00 I failed to update the results of my tests. I actually managed to get the original code to work (using a connection URI string of the form mongodb+srv://${USER}:${PASSWORD}@${HOST}.mongodb.net/) by including the root CA certificates in the final layer of the Docker image (/etc/ssl/certs/ca-certificate.crt)....

@Wolf00 My build was using go1.13 but I don't think anything relevant changed between 1.13 and 1.14. Check to make sure it's not a certificate issue for you, too.

@divjotarora
Copy link

@johnrichardrinehart Thanks for the update. Any ideas why adding the CA certs fixed the DNS issue?

@johnrichardrinehart
Copy link
Author

Actually, no. I'm having a hard time, looking through the go source, figuring how that would have fixed anything. It's been a while, but I remember that my binary (outside of a docker image) was able to use the mongo+srv URI string, while inside of a docker image (built on top of alpine) I was unable to use it. The solution ended up being that I needed to copy in the certificates from my build layer. But, yeah, I'm not seeing from the DNS resolution source how that would have helped at all.

@johnrichardrinehart
Copy link
Author

johnrichardrinehart commented Apr 14, 2020 •
edited
Loading

Ah, I remember now. The connection string defaults to TLS/SSL being true. So, it's not a golang issue. It's an issue at the the mongo-go-driver level.

Also, see this.

@divjotarora
Copy link

@johnrichardrinehart I'm happy to continue this discussion elsewhere, but you're right that using an SRV URI internally sets TLS to true. I'm not seeing lack of certs would result in an DNS resolution error though. That part of the code only calls net.LookupSRV and net.LookupTXT. The cannot unmarshal DNS message error comes from the Go stdlib.

@johnrichardrinehart
Copy link
Author

johnrichardrinehart commented Apr 17, 2020 •
edited
Loading

@divjotarora I agree. The issue seems unrelated to TLS certificates. However, I've done some more testing and TLS certificates are, indeed, necessary for my use case: I'm connecting to a Mongo Atlas cluster which requires TLS/SSL - so, if they aren't available (Docker image built on FROM scratch) then I'm unable to connect to my Atlas cluster.

I've ran 3 more tests which I think will shed some light on the issue, although I'm still confused as to the root problem. The first two tests fail (in different ways) and the last test succeeds.

  1. Test 1 executes a binary on an EC2 instance, compiled using go1.14.2 (I tested with a few versions... the results are insensitive to go1.13 vs. go1.14).
  2. Test 2 executes a docker image built using the same go and mongo-driver versions on scratch (without TLS certificates).
  3. Test 3 executes a docker image built using the same go and mongo driver versions on scratch including TLS certificates.

The OS details (for Test 1) are:

ubuntu@some-machine:~/dnstest$ uname -a
Linux ip-172-31-46-120 4.15.0-1057-aws #59-Ubuntu SMP Wed Dec 4 10:02:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@some-machine:~/dnstest$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

The problem may be related to the mongo-driver and not the stdlib, but since I obtained different results between tests 1 and 2 (which I would think should perform identically) I thought I would post my results for discussion, here.

I can run other tests as desired.

All tests use source code within one directory whose contents are:

ubuntu@some-machine:~$ tree dnstest
dnstest
├── Dockerfile
├── Dockerfile_withTLS
├── go.mod
├── go.sum
└── main.go

Their contents are, respectively,

Dockerfile (Test 2) 
FROM golang:1.14.2
ENV GOPATH=/go
ARG BUILDDIR=/build
COPY . $BUILDDIR
WORKDIR $BUILDDIR
RUN go get .
RUN CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -a -o dnstest .

FROM scratch
COPY --from=0 /build/dnstest /dnstest
ENTRYPOINT ["/dnstest"]
Dockerfile_withTLS (Test 3, only different in the 2nd-to-last line) 
FROM golang:1.14.2
ENV GOPATH=/go
ARG BUILDDIR=/build
COPY . $BUILDDIR
WORKDIR $BUILDDIR
RUN go get .
RUN CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -a -o dnstest .

FROM scratch
COPY --from=0 /build/dnstest /dnstest
COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
ENTRYPOINT ["/dnstest"]
go.mod 
module dnstest

go 1.14

require go.mongodb.org/mongo-driver v1.3.2
go.sum 
github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/go-stack/stack v1.8.0 h1:5SgMzNM5HxrEjV0ww2lTmX6E2Izsfxas4+YHWRs3Lsk=
github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
github.com/gobuffalo/attrs v0.0.0-20190224210810-a9411de4debd/go.mod h1:4duuawTqi2wkkpB4ePgWMaai6/Kc6WEz83bhFwpHzj0=
github.com/gobuffalo/depgen v0.0.0-20190329151759-d478694a28d3/go.mod h1:3STtPUQYuzV0gBVOY3vy6CfMm/ljR4pABfrTeHNLHUY=
github.com/gobuffalo/depgen v0.1.0/go.mod h1:+ifsuy7fhi15RWncXQQKjWS9JPkdah5sZvtHc2RXGlg=
github.com/gobuffalo/envy v1.6.15/go.mod h1:n7DRkBerg/aorDM8kbduw5dN3oXGswK5liaSCx4T5NI=
github.com/gobuffalo/envy v1.7.0/go.mod h1:n7DRkBerg/aorDM8kbduw5dN3oXGswK5liaSCx4T5NI=
github.com/gobuffalo/flect v0.1.0/go.mod h1:d2ehjJqGOH/Kjqcoz+F7jHTBbmDb38yXA598Hb50EGs=
github.com/gobuffalo/flect v0.1.1/go.mod h1:8JCgGVbRjJhVgD6399mQr4fx5rRfGKVzFjbj6RE/9UI=
github.com/gobuffalo/flect v0.1.3/go.mod h1:8JCgGVbRjJhVgD6399mQr4fx5rRfGKVzFjbj6RE/9UI=
github.com/gobuffalo/genny v0.0.0-20190329151137-27723ad26ef9/go.mod h1:rWs4Z12d1Zbf19rlsn0nurr75KqhYp52EAGGxTbBhNk=
github.com/gobuffalo/genny v0.0.0-20190403191548-3ca520ef0d9e/go.mod h1:80lIj3kVJWwOrXWWMRzzdhW3DsrdjILVil/SFKBzF28=
github.com/gobuffalo/genny v0.1.0/go.mod h1:XidbUqzak3lHdS//TPu2OgiFB+51Ur5f7CSnXZ/JDvo=
github.com/gobuffalo/genny v0.1.1/go.mod h1:5TExbEyY48pfunL4QSXxlDOmdsD44RRq4mVZ0Ex28Xk=
github.com/gobuffalo/gitgen v0.0.0-20190315122116-cc086187d211/go.mod h1:vEHJk/E9DmhejeLeNt7UVvlSGv3ziL+djtTr3yyzcOw=
github.com/gobuffalo/gogen v0.0.0-20190315121717-8f38393713f5/go.mod h1:V9QVDIxsgKNZs6L2IYiGR8datgMhB577vzTDqypH360=
github.com/gobuffalo/gogen v0.1.0/go.mod h1:8NTelM5qd8RZ15VjQTFkAW6qOMx5wBbW4dSCS3BY8gg=
github.com/gobuffalo/gogen v0.1.1/go.mod h1:y8iBtmHmGc4qa3urIyo1shvOD8JftTtfcKi+71xfDNE=
github.com/gobuffalo/logger v0.0.0-20190315122211-86e12af44bc2/go.mod h1:QdxcLw541hSGtBnhUc4gaNIXRjiDppFGaDqzbrBd3v8=
github.com/gobuffalo/mapi v1.0.1/go.mod h1:4VAGh89y6rVOvm5A8fKFxYG+wIW6LO1FMTG9hnKStFc=
github.com/gobuffalo/mapi v1.0.2/go.mod h1:4VAGh89y6rVOvm5A8fKFxYG+wIW6LO1FMTG9hnKStFc=
github.com/gobuffalo/packd v0.0.0-20190315124812-a385830c7fc0/go.mod h1:M2Juc+hhDXf/PnmBANFCqx4DM3wRbgDvnVWeG2RIxq4=
github.com/gobuffalo/packd v0.1.0/go.mod h1:M2Juc+hhDXf/PnmBANFCqx4DM3wRbgDvnVWeG2RIxq4=
github.com/gobuffalo/packr/v2 v2.0.9/go.mod h1:emmyGweYTm6Kdper+iywB6YK5YzuKchGtJQZ0Odn4pQ=
github.com/gobuffalo/packr/v2 v2.2.0/go.mod h1:CaAwI0GPIAv+5wKLtv8Afwl+Cm78K/I/VCm/3ptBN+0=
github.com/gobuffalo/syncx v0.0.0-20190224160051-33c29581e754/go.mod h1:HhnNqWY95UYwwW3uSASeV7vtgYkT2t16hJgV3AEPUpw=
github.com/golang/snappy v0.0.1 h1:Qgr9rKW7uDUkrbSmQeiDsGa8SjGyCOGtuasMWwvp2P4=
github.com/golang/snappy v0.0.1/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
github.com/google/go-cmp v0.2.0 h1:+dTQ8DZQJz0Mb/HjFlkptS1FeQ4cWSnN941F8aEG4SQ=
github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
github.com/inconshreveable/mousetrap v1.0.0/go.mod h1:PxqpIevigyE2G7u3NXJIT2ANytuPF1OarO4DADm73n8=
github.com/joho/godotenv v1.3.0/go.mod h1:7hK45KPybAkOC6peb+G5yklZfMxEjkZhHbwpqxOKXbg=
github.com/karrick/godirwalk v1.8.0/go.mod h1:H5KPZjojv4lE+QYImBI8xVtrBRgYrIVsaRPx4tDPEn4=
github.com/karrick/godirwalk v1.10.3/go.mod h1:RoGL9dQei4vP9ilrpETWE8CLOZ1kiN0LhBygSwrAsHA=
github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
github.com/klauspost/compress v1.9.5 h1:U+CaK85mrNNb4k8BNOfgJtJ/gr6kswUCFj6miSzVC6M=
github.com/klauspost/compress v1.9.5/go.mod h1:RyIbtBH6LamlWaDj8nUwkbUhJ87Yi3uG0guNDohfE1A=
github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
github.com/konsorten/go-windows-terminal-sequences v1.0.2/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
github.com/markbates/oncer v0.0.0-20181203154359-bf2de49a0be2/go.mod h1:Ld9puTsIW75CHf65OeIOkyKbteujpZVXDpWK6YGZbxE=
github.com/markbates/safe v1.0.1/go.mod h1:nAqgmRi7cY2nqMc92/bSEeQA+R4OheNU2T1kNSCBdG0=
github.com/montanaflynn/stats v0.0.0-20171201202039-1bf9dbcd8cbe/go.mod h1:wL8QJuTMNUDYhXwkmfOly8iTdp5TEcJFWZD2D7SIkUc=
github.com/pelletier/go-toml v1.4.0/go.mod h1:PN7xzY2wHTK0K9p34ErDQMlFxa51Fk0OUruD3k1mMwo=
github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
github.com/pkg/errors v0.8.1 h1:iURUrRGxPUNPdy5/HRSm+Yj6okJ6UtLINN0Q9M4+h3I=
github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
github.com/rogpeppe/go-internal v1.1.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
github.com/rogpeppe/go-internal v1.2.2/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
github.com/sirupsen/logrus v1.4.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
github.com/sirupsen/logrus v1.4.1/go.mod h1:ni0Sbl8bgC9z8RoU9G6nDWqqs/fq4eDPysMBDgk/93Q=
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
github.com/spf13/cobra v0.0.3/go.mod h1:1l0Ry5zgKvJasoi3XT1TypsSe7PqH0Sj9dhYf7v3XqQ=
github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
github.com/stretchr/testify v1.3.0 h1:TivCn/peBQ7UY8ooIcPgZFpTNSz0Q2U6UrFlUfqbe0Q=
github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
github.com/tidwall/pretty v1.0.0 h1:HsD+QiTn7sK6flMKIvNmpqz1qrpP3Ps6jOKIKMooyg4=
github.com/tidwall/pretty v1.0.0/go.mod h1:XNkn88O1ChpSDQmQeStsy+sBenx6DDtFZJxhVysOjyk=
github.com/xdg/scram v0.0.0-20180814205039-7eeb5667e42c h1:u40Z8hqBAAQyv+vATcGgV0YCnDjqSL7/q/JyPhhJSPk=
github.com/xdg/scram v0.0.0-20180814205039-7eeb5667e42c/go.mod h1:lB8K/P019DLNhemzwFU4jHLhdvlE6uDZjXFejJXr49I=
github.com/xdg/stringprep v0.0.0-20180714160509-73f8eece6fdc h1:n+nNi93yXLkJvKwXNP9d55HC7lGK4H/SRcwB5IaUZLo=
github.com/xdg/stringprep v0.0.0-20180714160509-73f8eece6fdc/go.mod h1:Jhud4/sHMO4oL310DaZAKk9ZaJ08SJfe+sJh0HrGL1Y=
go.mongodb.org/mongo-driver v1.3.2 h1:IYppNjEV/C+/3VPbhHVxQ4t04eVW0cLp0/pNdW++6Ug=
go.mongodb.org/mongo-driver v1.3.2/go.mod h1:MSWZXKOynuguX+JSvwP8i+58jYCXxbia8HS3gZBapIE=
golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20190422162423-af44ce270edf/go.mod h1:WFFai1msRO1wXaEeE5yQxYXgSfI8pQAWXbQop6sCtWE=
golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5 h1:8dUaAV7K4uHsF56JQWkprecIQKdPHtR9jCHF5nB8uzc=
golang.org/x/crypto v0.0.0-20190530122614-20be4c3c3ed5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
golang.org/x/sync v0.0.0-20190412183630-56d357773e84/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
golang.org/x/sync v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190403152447-81d4e9dc473e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190419153524-e8e3143a4f4a/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190531175056-4c3a928424d2/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
golang.org/x/text v0.3.2 h1:tW2bmiBqwgJj/UpqtC8EpXEZVYOwU0yG4iWbprSVAcs=
golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
golang.org/x/tools v0.0.0-20181030221726-6c7e314b6563/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
golang.org/x/tools v0.0.0-20190329151228-23e29df326fe/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
golang.org/x/tools v0.0.0-20190416151739-9c9e1878f421/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
golang.org/x/tools v0.0.0-20190420181800-aa740d480789/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
golang.org/x/tools v0.0.0-20190531172133-b3315ee88b7d/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI=
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
main.go (Test 1, and used in both Dockerfiles) 
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"
	"go.mongodb.org/mongo-driver/version"
)

func main() {
	uri := flag.String("uri", "mongodb://localhost:27017", "URI of the mongo server of interest")
	flag.Parse()

	log.Printf("mongo-go-driver version: %s", version.Driver)

	opts := options.Client().ApplyURI(*uri)
	if err := opts.Validate(); err != nil {
		log.Fatalf("invalid options: %s", err)
	}

	ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
	defer cancel()
	client, err := mongo.Connect(ctx, opts)
	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("success... exiting")
}

Note: Credentials have been redacted for security reasons. However, credentials were supplied for each test in the same way.

Test 1 (Native Binary)

Setup/Input

  1. CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -a -o dnstest . (statically linked to imitate the Dockerized tests, later)

Result/Output (credentials redacted)

ubuntu@some-machine:~/dnstest$ ./dnstest -uri="mongodb+srv://<user>:<password>@staging.vduzy.mongodb.net"
2020/04/17 20:30:48 mongo-go-driver version: v1.3.2
2020/04/17 20:30:48 invalid options: error parsing uri: lookup staging.vduzy.mongodb.net on 127.0.0.53:53: cannot unmarshal DNS message

Test 2 (Dockerized without TLS certificates)

Setup/Input

  1. docker build -t dnstest:latest .

Result/Output

ubuntu@some-machine:~/dnstest$ docker run dnstest:latest -uri="mongodb+srv://<user>:<password>@staging.vduzy.mongodb.net"
2020/04/17 20:34:14 mongo-go-driver version: v1.3.2
2020/04/17 20:34:15 pinging error: context deadline exceeded

Test 3 (Dockerized with TLS certificates)

Setup/Input

  1. docker build -t dnstest_tls:latest -f ./Dockerfile_withTLS .

Result/Output

ubuntu@some-machine:~/dnstest$ sudo docker run dnstest_tls:latest 
-uri="mongodb+srv://<user>:<password>@staging.vduzy.mongodb.net"
2020/04/17 20:37:02 mongo-go-driver version: v1.3.2
2020/04/17 20:37:02 success... exiting

sysu-yunz referenced this issue in sysu-yunz/fund-minitor Jun 5, 2020
feat: database
b6b0dbb
@rwynn rwynn mentioned this issue Sep 4, 2020
Closed
@ismailyenigul
Copy link

ismailyenigul commented Nov 16, 2020 •
edited
Loading

I am experiencing the same issue with mongodump 4.2 on Ubuntu 18.04 AWS EC2 instance.


# mongodump --uri mongodb+srv://user:pass@mycluster.abcd.mongodb.net/mydb --ssl -v
2020-11-16T13:13:57.839+0000	error parsing command line options: error parsing uri: lookup mycluster.abcd.mongodb.net on 127.0.0.53:53: cannot unmarshal DNS message
2020-11-16T13:13:57.839+0000	try 'mongodump --help' for more information

# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic



# mongodump   --version 
mongodump version: r4.2.10
git version: 88276238fa97b47c0ef14362b343c5317ecbd739
Go version: go1.12.17
   os: linux
   arch: amd64
   compiler: gc

# cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0
search eu-west-1.compute.internal

 dig srv _mongodb._tcp.mycluster.abcd.mongodb.net

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> srv _mongodb._tcp.mycluster.abcd.mongodb.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13683
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_mongodb._tcp.mycluster.abcd.mongodb.net. IN SRV

;; ANSWER SECTION:
_mongodb._tcp.mycluster.abcd.mongodb.net. 60 IN	SRV 0 0 27017 mycluster-shard-00-01.abcd.mongodb.net.
_mongodb._tcp.mycluster.abcd.mongodb.net. 60 IN	SRV 0 0 27017 mycluster-shard-00-02.abcd.mongodb.net.
_mongodb._tcp.mycluster.abcd.mongodb.net. 60 IN	SRV 0 0 27017 mycluster-shard-00-00.abcd.mongodb.net.

;; Query time: 11 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Nov 16 13:12:10 UTC 2020
;; MSG SIZE  rcvd: 192

If I add 8.8.8.8 as first DNS server, then it works!

@johnrichardrinehart
Copy link
Author

johnrichardrinehart commented Nov 16, 2020 •
edited
Loading

This doesn't sound like a golang issue, then. It just seems like a DNS issue. Note that net.Dial reads /etc/resolve.conf.

@ismailyenigul It looks like your DNS resolution using dig worked before you prepended 8.8.8.8 to /resolve.conf. Is that true? If so, then I'm confused.

@ismailyenigul
Copy link

It seems something wrong between Ubuntu 18.04 systemd and mongodump go library version.

@johnrichardrinehart
Copy link
Author

Were you having DNS issues (traceroute/dig/ping) before you applied your DNS change to resolve.conf?

@amenzhinsky
Copy link

amenzhinsky commented Dec 17, 2020 •
edited
Loading

I'm having same issue with SRV lookups proxied from systemd-resolved to consul.

drill/dig work just fine:

drill srv private.cms.service.consul
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 30360
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; cms.service.consul.  IN      SRV

;; ANSWER SECTION:
cms.service.consul.     0       IN      SRV     1 1 7075 staging.node.dc1.consul.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 127.0.0.53
;; WHEN: Thu Dec 17 11:57:18 2020
;; MSG SIZE  rcvd: 100

upd:

This most likely relates to systemd/systemd#9828

@ismailyenigul
Copy link

Were you having DNS issues (traceroute/dig/ping) before you applied your DNS change to resolve.conf?

No, all good with that tools. Only mongodump does not work.

This was referenced Feb 2, 2021
Closed
Closed
@antoineco
Copy link

antoineco commented Mar 6, 2022 •
edited
Loading

edit: I just noticed #51127 was already fixed.

I'm currently facing that issue in a WSL2 environment using Go 1.18 beta 2.

The package github.com/Azure/go-autorest/autorest@v0.11.24 is trying to send an HTTP request to management.azure.com using a (*net/http.Client) and fails with the following error.

error(*net.DNSError) *{
                Err: "cannot unmarshal DNS message",
                Name: "management.azure.com",
                Server: "172.25.160.1:53",
                IsTimeout: false,
                IsTemporary: false,
                IsNotFound: false,},}
$ dig management.azure.com 172.25.160.1

; <<>> DiG 9.16.1-Ubuntu <<>> management.azure.com 172.25.160.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 813
;; flags: qr rd ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;management.azure.com.          IN      A

;; ANSWER SECTION:
management.azure.com.   0       IN      CNAME   management.privatelink.azure.com.
management.privatelink.azure.com. 0 IN  CNAME   arm-frontdoor-prod.trafficmanager.net.
arm-frontdoor-prod.trafficmanager.net. 0 IN CNAME germanywestcentral.management.azure.com.
germanywestcentral.management.azure.com. 0 IN CNAME arm-frontdoor-germanywestcentral.trafficmanager.net.
arm-frontdoor-germanywestcentral.trafficmanager.net. 0 IN CNAME germanywestcentral.cs.management.azure.com.
germanywestcentral.cs.management.azure.com. 0 IN CNAME rpfd-germanywestcentral.cloudapp.net.
rpfd-germanywestcentral.cloudapp.net. 0 IN A    51.116.156.32

;; Query time: 10 msec
;; SERVER: 172.25.160.1#53(172.25.160.1)
;; WHEN: Sun Mar 06 15:13:43 CET 2022
;; MSG SIZE  rcvd: 632

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25454
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;172.25.160.1.                  IN      A

;; ANSWER SECTION:
172.25.160.1.           0       IN      A       172.25.160.1

;; Query time: 0 msec
;; SERVER: 172.25.160.1#53(172.25.160.1)
;; WHEN: Sun Mar 06 15:13:43 CET 2022
;; MSG SIZE  rcvd: 58

I suspect the problem isn't specific to the aforementioned domain.

Switching the primary DNS server to 8.8.8.8 inside /etc/resolv.conf solves the issue.

@DawnBreather
Copy link

DawnBreather commented Apr 2, 2022 •
edited
Loading

For MongoDB Atlas

 serverAPIOptions := options.ServerAPI(options.ServerAPIVersion1)
  clientOptions := options.Client().
    ApplyURI("mongodb://username:password@prefix0.mongodb.net:27017,prefix1.mongodb.net:27017,prefix2.mongodb.net:27017/?retryWrites=true&w=majority&replicaSet=atlas-zhqegh-shard-0&tls=true").
    SetServerAPIOptions(serverAPIOptions)
  ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
  defer cancel()
  client, err := mongo.Connect(ctx, clientOptions)
  if err != nil {
    log.Fatal(err)
  }

To clarify the MongoDB Atlas replicaSet and hosts you can for instance utilize MongoDB Compass: just connect to the cluster and you will see all that data.

@halturin
Copy link

halturin commented Jun 26, 2022 •
edited
Loading

just got the same problem after updating my golang to go version go1.17.11 linux/amd64

	_, srv, err := net.LookupSRV("cloud", "dist", "ergo.services")
	if err != nil {
		fmt.Println("SRVVVV", srv)
		return nil, err
	}

gives me

lookup ergo.services on 192.168.88.1:53: cannot unmarshal DNS message

at the same time if i checkout SRV records using dig it shows correct result

❯❯❯❯ dig srv _cloud._dist.ergo.services                                           
                                                                                  
; <<>> DiG 9.18.3 <<>> srv _cloud._dist.ergo.services                             
;; global options: +cmd                                                           
;; Got answer:                                                                    
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51027                         
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0              
                                                                                  
;; QUESTION SECTION:                                                              
;_cloud._dist.ergo.services.    IN      SRV                                       
                                                                                  
;; ANSWER SECTION:                                                                
_cloud._dist.ergo.services. 1600 IN     SRV     10 10 4411 cloud01.ergo.services. 
_cloud._dist.ergo.services. 1600 IN     SRV     10 10 4411 cloud02.ergo.services. 
_cloud._dist.ergo.services. 1600 IN     SRV     10 10 4411 cloud03.ergo.services. 

;; Query time: 2 msec
;; SERVER: 192.168.88.1#53(192.168.88.1) (UDP)
;; WHEN: Sun Jun 26 16:36:18 CEST 2022
;; MSG SIZE  rcvd: 133

Upd: just noticed the date of this issue. looks too old. I'm going to create the new one

@isrealbm
Copy link

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.

@DawnBreather
Copy link

DawnBreather commented Jan 9, 2023 •
edited
Loading

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.

Thank you @jmsmss, your suggestion has saved my day.

Providing some additional interesting details (just in case).
cc: @toothrot

This Python code works with "any" DNS:

import srvlookup #pip install srvlookup
import sys 
import dns.resolver #pip install dnspython

host = None

if len(sys.argv) > 1 :
   host = sys.argv[1]

if host :
   services = srvlookup.lookup("mongodb", domain=host)
   for i in services:
       print("%s:%i" % (i.hostname, i.port))
   for txtrecord in dns.resolver.query(host, 'TXT'):
       print("%s: %s" % ( host, txtrecord))
else:
   print("No host specified")

Here is the Golang code created based on that Python code (which seems to be pickier about the DNS server):

package main

import (
	"fmt"
	"net"
	"os"
)

func main() {
	// Get the hostname from the command line argument
	host := os.Args[1]

	// Look up the SRV records for the hostname
	_, addrs, err := net.LookupSRV("mongodb", "tcp", host)
	if err != nil {
		fmt.Println(err)
		return
	}

	// Print the SRV records
	for _, addr := range addrs {
		fmt.Printf("%s:%d\n", addr.Target, addr.Port)
	}

	// Look up the TXT records for the hostname
	txts, err := net.LookupTXT(host)
	if err != nil {
		fmt.Println(err)
		return
	}

	// Print the TXT records
	for _, txt := range txts {
		fmt.Printf("%s: %s\n", host, txt)
	}
}

The Python code was taken from this article.

I was testing both codes (Golang and Python) from the same virtual machine: Manjaro Linux 22.0.0.
This virtual machine was utilizing my internal DNS server, which is my Mikrotik router (192.168.88.1):

  • RouterOS v7.3.1
  • RouterBoard v7.3.1

Conclusion

  • Python code is working consistently well both with 192.168.88.1 and 1.1.1.1 as DNS servers
  • Golang code is working well with 1.1.1.1, but error appears when using 192.168.88.1:
cannot unmarshal dns message

The error happens at ~/.go/sdk/go1.19.4/src/vendor/golang.org/x/net/dns/dnsmessage/message.go (line 2025) (marked in this message bellow as well):

func (n *Name) unpackCompressed(msg []byte, off int, allowCompression bool) (int, error) {
	// currOff is the current working offset.
	currOff := off

	// newOff is the offset where the next record will start. Pointers lead
	// to data that belongs to other names and thus doesn't count towards to
	// the usage of this name.
	newOff := off

	// ptr is the number of pointers followed.
	var ptr int

	// Name is a slice representation of the name data.
	name := n.Data[:0]

Loop:
	for {
		if currOff >= len(msg) {
			return off, errBaseLen
		}
		c := int(msg[currOff])
		currOff++
		switch c & 0xC0 {
		case 0x00: // String segment
			if c == 0x00 {
				// A zero length signals the end of the name.
				break Loop
			}
			endOff := currOff + c
			if endOff > len(msg) {
				return off, errCalcLen
			}
			name = append(name, msg[currOff:endOff]...)
			name = append(name, '.')
			currOff = endOff
		case 0xC0: // Pointer
			if !allowCompression {
// ===========> THE ERROR IS HAPPENING HERE
				return off, errCompressedSRV
			}
			if currOff >= len(msg) {
				return off, errInvalidPtr
			}
			c1 := msg[currOff]
			currOff++
			if ptr == 0 {
				newOff = currOff
			}
			// Don't follow too many pointers, maybe there's a loop.
			if ptr++; ptr > 10 {
				return off, errTooManyPtr
			}
			currOff = (c^0xC0)<<8 | int(c1)
		default:
			// Prefixes 0x80 and 0x40 are reserved.
			return off, errReserved
		}
	}
	if len(name) == 0 {
		name = append(name, '.')
	}
	if len(name) > len(n.Data) {
		return off, errCalcLen
	}
	n.Length = uint8(len(name))
	if ptr == 0 {
		newOff = currOff
	}
	return newOff, nil
}

Wireshark

Providing below DNS responses from different DNS servers (1.1.1.1 and 192.168.88.1).

1.1.1.1 (DNS response)

Summary:

----
# Packet 1 from /var/folders/02/prfbfy6n5mg4mvt5kd5yjq_w0000gn/T/wireshark_Wi-FiUZI4X1.pcapng
- 131
- 1.932045
- 1.1.1.1
- 192.168.88.242
- DNS
- 305
- Standard query response 0xbe07 SRV _mongodb._tcp.<REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net OPT

HEX dump:

0000   50 ed 3c 52 86 f1 cc 2d e0 1d 25 cd 08 00 45 00
0010   01 23 f2 fa 40 00 3a 11 31 33 01 01 01 01 c0 a8
0020   58 f2 00 35 f4 f4 01 0f 53 50 be 07 81 80 00 01
0030   00 03 00 00 00 01 08 5f 6d 6f 6e 67 6f 64 62 04
0040   5f 74 63 70 0d 63 77 2d 70 72 6f 64 75 63 74 69
0050   6f 6e 05 6b 76 39 65 6d 07 6d 6f 6e 67 6f 64 62
0060   03 6e 65 74 00 00 21 00 01 c0 0c 00 21 00 01 00
0070   00 00 3c 00 33 00 00 00 00 69 89 19 63 77 2d 70
0080   72 6f 64 75 63 74 69 6f 6e 2d 73 68 61 72 64 2d
0090   30 30 2d 30 30 05 6b 76 39 65 6d 07 6d 6f 6e 67
00a0   6f 64 62 03 6e 65 74 00 c0 0c 00 21 00 01 00 00
00b0   00 3c 00 33 00 00 00 00 69 89 19 63 77 2d 70 72
00c0   6f 64 75 63 74 69 6f 6e 2d 73 68 61 72 64 2d 30
00d0   30 2d 30 31 05 6b 76 39 65 6d 07 6d 6f 6e 67 6f
00e0   64 62 03 6e 65 74 00 c0 0c 00 21 00 01 00 00 00
00f0   3c 00 33 00 00 00 00 69 89 19 63 77 2d 70 72 6f
0100   64 75 63 74 69 6f 6e 2d 73 68 61 72 64 2d 30 30
0110   2d 30 32 05 6b 76 39 65 6d 07 6d 6f 6e 67 6f 64
0120   62 03 6e 65 74 00 00 00 29 04 d0 00 00 00 00 00
0130   00

192.168.88.1 (DNS response)

Summary:

----
# Packet 17 from /var/folders/02/prfbfy6n5mg4mvt5kd5yjq_w0000gn/T/wireshark_Wi-FiZ2EBY1.pcapng
- 1121
- 5.778839
- 192.168.88.1
- 192.168.88.242
- DNS
- 249
- Standard query response 0x2ad6 SRV _mongodb._tcp.<REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net SRV 0 0 27017 <REPLACED>.<REPLACED>.mongodb.net

HEX dump:

0000   50 ed 3c 52 86 f1 cc 2d e0 1d 25 cd 08 00 45 00
0010   00 eb 94 53 00 00 40 11 b3 6a c0 a8 58 01 c0 a8
0020   58 f2 00 35 dd 2f 00 d7 bd b5 2a d6 81 80 00 01
0030   00 03 00 00 00 00 08 5f 6d 6f 6e 67 6f 64 62 04
0040   5f 74 63 70 0d 63 77 2d 70 72 6f 64 75 63 74 69
0050   6f 6e 05 6b 76 39 65 6d 07 6d 6f 6e 67 6f 64 62
0060   03 6e 65 74 00 00 21 00 01 c0 0c 00 21 00 01 00
0070   00 00 3c 00 28 00 00 00 00 69 89 19 63 77 2d 70
0080   72 6f 64 75 63 74 69 6f 6e 2d 73 68 61 72 64 2d
0090   30 30 2d 30 30 05 6b 76 39 65 6d c0 2e c0 0c 00
00a0   21 00 01 00 00 00 3c 00 22 00 00 00 00 69 89 19
00b0   63 77 2d 70 72 6f 64 75 63 74 69 6f 6e 2d 73 68
00c0   61 72 64 2d 30 30 2d 30 31 c0 6b c0 0c 00 21 00
00d0   01 00 00 00 3c 00 22 00 00 00 00 69 89 19 63 77
00e0   2d 70 72 6f 64 75 63 74 69 6f 6e 2d 73 68 61 72
00f0   64 2d 30 30 2d 30 32 c0 6b

@vkedwardli
Copy link 

r := &net.Resolver{
    PreferGo: true,
    Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
        d := net.Dialer{
            Timeout: time.Millisecond * time.Duration(10000),
        }
        return d.DialContext(ctx, network, "8.8.8.8:53")
    },
}
_, srvs, err := r.LookupSRV(context.Background(), service, "tcp", host)

I have to point to Google DNS manually when using tethered hotspot sharing from iPhone (but Wi-Fi hotspot sharing works)

@mateusz834 mateusz834 mentioned this issue Nov 7, 2023
Closed
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/540375 mentions this issue: dns/dnsmessage: allow name compression for SRV resource parsing

gopherbot pushed a commit to golang/net that referenced this issue Feb 3, 2024
@mateusz834 @gopherbot
dns/dnsmessage: allow name compression for SRV resource parsing
73e4b50 
As per RFC 3597:

Receiving servers MUST decompress domain names in RRs of well-known
   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
   NXT, NAPTR, and SRV (although the current specification of the SRV RR
   in RFC2782 prohibits compression, RFC2052 mandated it, and some
   servers following that earlier specification are still in use).

This change allows SRV resource decompression.

Updates golang/go#36718
Updates golang/go#37362

Change-Id: I473c0d3803758e5b12886f378d2ed54bd5392144
GitHub-Last-Rev: 88d2e06
GitHub-Pull-Request: #199
Reviewed-on: https://go-review.googlesource.com/c/net/+/540375
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
@mateusz834
Copy link
Member

As of https://go.dev/cl/570156 this is now fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests