net: pure Go resolver(netdns) can not resolve hostname.local

[atlas-comstock]

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

go version go1.13.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/yonghao.hu/Library/Caches/go-build"
GOENV="/Users/yonghao.hu/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/yonghao.hu/mycode/go_dir_path"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/yonghao.hu/mycode/go_dir_path/src/test/go.mod"
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/wf/nw471wh91nj2j_dsrfrk4htnjtqhhw/T/go-build666420423=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

import (
	"fmt"
	"net"
)

func main() {
	dialer := &net.Dialer{
		LocalAddr: nil,
	}

	_, err := dialer.Dial("tcp", "yonghaohu-mac.local:4150")
	if err != nil {
		fmt.Println("resolve yonghaohu-mac.local failed: ", err)
	} else {
		fmt.Println("resolve myaliashost success")
	}
	_, err = dialer.Dial("tcp", "myaliashost:4150")
	if err != nil {
		fmt.Println("resolve myaliashost failed: ", err)
	}
	fmt.Println("resolve myaliashost success")
}

Just run GODEBUG=netdns=go+4 go run test.go

What did you expect to see?

Resolve to 127.0.0.1

What did you see instead?

resolve yonghaohu-mac.local failed: dial tcp: lookup yonghaohu-mac.local on 10.22.12.45:53: no such host

[bradfitz]

Yes, that's known, as the docs at https://golang.org/pkg/net/#hdr-Name_Resolution imply, and we're unlikely to implement it.

If you need to resolve those names, use a different resolver.

[atlas-comstock]

@bradfitz Hi, thanks for your reply . I know sth about this before writing the issue. Could u plz tell me why not to implement it ? What is the consideration?

[bradfitz]

It's a lot of code for very few users and the system DNS resolver is usually fine. The advantage of using the pure Go resolver is usually to avoid cgo and expensive threads being tied up during resolution, but that only matters when you have, say, tens of thousands of outstanding lookups. (e.g. you're a web crawler binary) But if you have tens of thousands of mDNS lookups outstanding, you probably have bigger problems on your LAN.

[alex-leonhardt]

Hope you don't mind me hijacking this for quick question...

@bradfitz - what is the default behaviour in the absence of nsswitch.conf and a system resolver meant to be? I've had to "force" it to be used with -tags netgo, though I would have expected it to become the default since, well, there's no resolver or config that could try to use features that aren't supported?

[ianlancetaylor]

@alex-leonhardt The default behavior is system dependent. Which system are you asking about?

In general questions are better asked on a forum; see https://golang.org/wiki/Questions.

[alex-leonhardt]

Thanks @ianlancetaylor - i'll ask in slack or the forums. My apologies.

[jdmarshall]

The problem with not solving this is that a Go app will fail to load a URL while curl and ping succeed.

This makes for some pretty odd troubleshooting, especially for someone using a Go app rather than writing one.

It very much will affect anyone using an Airport Extreme access point (or anything that behaves similarly - ie, not registering DNS entries automatically for all DHCP clients). And while that admittedly will be a ridiculous target audience to support sooner rather than later, I don't think we are quite there until the next WiFi standard is ubiquitous. People with Macbook Pros should absolutely be a target audience though, and they're in this Venn Diagram of obscure error messages.

[davecheney]

@jdmarshall this only affects Go binaries using the built in dns resolver which is not the default. That is, you have to opt into this reduced functionality.

[jdmarshall]

@davecheney

So I should file an issue with the package experiencing this problem?

[davecheney]

Yes please