Go: net: make Resolver.PreferGo and GODEBUG=netdns=go use Go code on Windows

[moloch--]

Problem

Currently DNS resolution on Windows always calls the C functions, which means DNS resolution cannot be configured using a custom dialer. This has two primary downsides:

1. You cannot specify an alternate DNS server, only the system resolver is ever used.
2. Edges cases fail, for example if a server is configured to use DNS-over-TCP on Windows DNS resolution in Go will always fail and the behavior cannot be corrected. This is not true for other languages such as Java, and built-in utilties such as nslookup.

Proposal

Enable the use of the built-in DNS stub resolver on Windows so that custom dialers can be used to control the behavoir of Go's resolution when needed.

See Also

https://github.com/golang/go/issues/33086

https://github.com/golang/go/issues/29621

[rsc]

Does Windows stop us from making direct DNS UDP requests? (This is the reason we don't do it on macOS.)

Otherwise I don't see why we currently go out of our way to bypass the plain Go code, which was written first. There must be a reason. What is it? Windows-specific name resolution mechanisms like NetBIOS?

We could also use the plain UDP DNS if we can detect that there's nothing special about the rest or the host system, which I think we try to do on macOS.

More information is needed here.

[rsc]

The previous comment (from Jul 16) asked some questions that still need to be answered. We can't move forward with this proposal without answers.

[networkimprov]

Appears this was missed by triage...

cc @alexbrainman @zx2c4 @mattn @jordanrh1 @bradfitz
@gopherbot add OS-Windows

[alexbrainman]

Does Windows stop us from making direct DNS UDP requests? (This is the reason we don't do it on macOS.)

I don't know. But Windows could certainly restrict DNS UDP. Even external firewall can restrict us.

Otherwise I don't see why we currently go out of our way to bypass the plain Go code, which was written first. There must be a reason. What is it?

Maybe I mis-remember. Windows has built in network name resolver. The resolver uses not just DNS to do its work. Go net code just calls into that resolver. This makes Go name resolution consistent with other Windows programs.

There is only one external lookup API for net package. And that is why Windows users cannot access our pure Go DNS resolver code. I am pretty sure I complained about this to you, but you decided it was not important at the time.

Windows-specific name resolution mechanisms like NetBIOS?

Quite possible. But I am not Windows network expert - do not take my word for it.

Alex

[zx2c4]

The Windows resolver is weird and particular, and I doubt we're going to be able to copy that internally from Go. Setting aside the issue of whether we can reliably get out those UDP packets, the Windows resolver has specific behavior with handling several name servers on several interfaces, and it has specific behavior when dealing with things like Active Directory. Think of nsswitch.conf but on steroids. So I'd recommend keeping things as-is and not using the Go built-in resolver.

[bradfitz]

@zx2c4, I agree that the Windows resolver should remain the default, but I think this bug is about permitting the opt-in use of the Go resolver, either at a whole-program (build tag) level or in code by e.g. https://golang.org/pkg/net/#Resolver.PreferGo

[zx2c4]

Gotcha. That's fine with me. Is there still a question then of whether udp 53 sockets are possible? If so I can experiment a bit.

[rsc]

Retitled to "proposal: net: make Resolver.PreferGo and GODEBUG=netdns=go use Go code on Windows" based on @bradfitz's comment above. I originally thought this issue was about using the Go code by default in certain cases. I don't think we know when that would be appropriate, nor how to detect it. But if this is only about making it possible for programs to explicitly say "use the Go resolver" and have that actually take effect (as it does on other operating systems), then this seems very easy to accept - it's not much more than a bug fix.

Based on the narrower scope implied by the retitling, this seems like a likely accept.

Leaving open for a week for final comments.

[alexbrainman]

this seems very easy to accept - it's not much more than a bug fix.

I agree. We should treat this as a bug fix.

Alex

[rsc]

No final comments. Accepted