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.

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

net: cannot resolve SRV records from Samba's DNS server #36718

Open
PaulForgey opened this issue Jan 24, 2020 · 11 comments
Open

net: cannot resolve SRV records from Samba's DNS server #36718

PaulForgey opened this issue Jan 24, 2020 · 11 comments
Labels
Milestone

Comments

@PaulForgey
Copy link

@PaulForgey PaulForgey commented Jan 24, 2020

What version of Go are you using (go version)?

$ go version
go version go1.13.3 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ubuntu/.cache/go-build"
GOENV="/home/ubuntu/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ubuntu/mesa/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/src/go1.13.3/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/src/go1.13.3/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build085179277=/tmp/go-build -gno-record-gcc-switches"

What did you do?

package main

import (
	"context"
	"fmt"
	"net"
)

func main() {
	cname, addrs, err := net.DefaultResolver.LookupSRV(context.Background(), "kerberos", "udp", "mydc.example.com")
	if err != nil {
		panic(err)
	}
	fmt.Printf("cname=%s\n", cname)
	for _, a := range addrs {
		fmt.Printf("target=%s:\n", a.Target)
	}
}

Samba (at least 4.3.11-Ubuntu), compresses the Target fields of the SRV records. While this is against clarifying RFCs and there is much discussion of this in the patch enforcing this, it breaks resolver behavior at least against Samba and possibly other embedded servers.

IMO, this makes the resolver less robust. If the rationale is to defend against ignorant DNS proxies, I would argue the client is not the layer to make this decision.

What did you expect to see?

successful resolution

What did you see instead?

error "cannot unmarshal DNS message"

@toothrot toothrot changed the title cannot resolve SRV records from Samba's DNS server net: cannot resolve SRV records from Samba's DNS server Jan 24, 2020
@toothrot toothrot added this to the Backlog milestone Jan 24, 2020
@toothrot
Copy link
Contributor

@toothrot toothrot commented Jan 24, 2020

That's pretty unfortunate that Samba doesn't follow the RFCs. Considering that oddity, I am not sure if this belongs in the core library or its own package. The owners should have a better idea. /cc @mikioh @bradfitz @ianlancetaylor

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 24, 2020

/cc @mdempsky

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 24, 2020

RFC 2782 clearly states "name compression is not to be used for [SRV's Target] field."

RFC 3597 though states we "SHOULD" support decompressing names in SRV RRs (as opposed to "MUST" for the RRs where we already support decompression).

I'd review a patch to enable decompression (but not compression) of SRV targets if someone wants to work on one. I think Samba should fix their behavior though.

@PaulForgey
Copy link
Author

@PaulForgey PaulForgey commented Jan 24, 2020

I agree Samba should fix this, but it is but one example of an embedded server in the wild, and there is no good reason for a client to fail.

Commit 24dd3780ca4f75fed9f321890729414a4b5d3f13 explicitly did this, which IMO, should be reverted.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 24, 2020

Commit 24dd3780ca4f75fed9f321890729414a4b5d3f13 explicitly did this

I don't see that commit in Go's git history?

@PaulForgey
Copy link
Author

@PaulForgey PaulForgey commented Jan 24, 2020

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Jan 24, 2020

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 24, 2020

Ah, thanks. That looks safe to revert.

I'd appreciate some confirmation that other major DNS clients are today accepting SRV RRs. (I assume they are, otherwise I'd expect more pushback against Samba doing this.)

@PaulForgey
Copy link
Author

@PaulForgey PaulForgey commented Jan 24, 2020

ISC's BIND at the very least does, as dig has no problem resolving these records. This is a common reference implementation.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 24, 2020

Okay, reverting that CL seems fine to me then once the trees open up again for development. Thanks.

@divjotarora
Copy link

@divjotarora divjotarora commented Apr 11, 2020

We have a number of users hitting this issue when using SRV records with the go.mongodb.org/mongo-driver library and the only good responses we have for them so far are to use non-SRV URIs (for resilience purposes, this requires specifying a very long URI that's hard to read) or using a different DNS server, which many applications can't always control. Given that neither of these solutions are particularly good, can anyone give a timeline for when the change linked above might be reverted or provide another solution that we can forward to our users?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.