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.
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?
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.
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
What did you do?
GODEBUG=netdns=go+4 go run test.go
What did you expect to see?
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
The text was updated successfully, but these errors were encountered: