Closed johnrichardrinehart closed 7 months ago
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 https://github.com/golang/go/issues/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?
Also #36718 is related.
@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.
@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?
Was facing the same issue with mongo-driver
using Go1.14. Using a loong mongo connection string(without srv) is a temporary fix.
@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.
@johnrichardrinehart Thanks for the update. Any ideas why adding the CA certs fixed the DNS issue?
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.
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.
@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.
@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.
go1.14.2
(I tested with a few versions... the results are insensitive to go1.13
vs. go1.14
).go
and mongo-driver
versions on scratch
(without TLS certificates).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,
Note: Credentials have been redacted for security reasons. However, credentials were supplied for each test in the same way.
CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' -a -o dnstest .
(statically linked to imitate the Dockerized tests, later)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
docker build -t dnstest:latest .
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
docker build -t dnstest_tls:latest -f ./Dockerfile_withTLS .
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
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!
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.
It seems something wrong between Ubuntu 18.04 systemd and mongodump go library version.
Were you having DNS issues (traceroute
/dig
/ping
) before you applied your DNS change to resolve.conf
?
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 https://github.com/systemd/systemd/pull/9828
Were you having DNS issues (
traceroute
/dig
/ping
) before you applied your DNS change toresolve.conf
?
No, all good with that tools. Only mongodump does not work.
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.
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.
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
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.
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):
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:
```yaml
----
# 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
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
----
# 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
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
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)
Change https://go.dev/cl/540375 mentions this issue: dns/dnsmessage: allow name compression for SRV resource parsing
As of https://go.dev/cl/570156 this is now fixed.
Does this issue reproduce with the latest release?
Yep.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat 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.Compiled on my MacBook Pro using different
go
versions, all the way togotip
versionCompiled using
GOOS=linux GOARCH=amd64 go build .
since I'm building for an Ubuntu 18.04 EC2 instance.I then
scp
ed 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
ssh
ing to the remote box I executed./mongoConnectTest -uri=mongodb+srv://$USER:$PASSWORD@$HOST/$TESTDB
and received the following error.
Notes
I'm using a DNS seedlist provided by an
SRV
record to access a cluster of machines exposing amongo
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 relevantDNS
records below.SRV record
TXT record