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

proposal: net: Enable built-in DNS stub resolver on Windows #33097

moloch-- opened this issue Jul 13, 2019 · 1 comment


Copy link

commented Jul 13, 2019


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.


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



@gopherbot gopherbot added this to the Proposal milestone Jul 13, 2019

@gopherbot gopherbot added the Proposal label Jul 13, 2019


This comment has been minimized.

Copy link

commented Jul 16, 2019

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.

jsha added a commit to letsencrypt/pebble that referenced this issue Jul 29, 2019

Fix custom resolver implementation for Windows (#255)
Pebble accepts a `--dnsserver` flag, that allows to select a custom
DNS resolver to use when validating the ACME challenges. This option
is critical to make the certbot integration tests work in particular.

Current implementation is to set the `net.DefaultResolver` on a new
`net.Resolver` instance with a custom `Dial` property to consume the
value from `--dnsserver`. This allows to transparently resolve any
host using this custom DNS resolver from a pure-Go implementation of
the DNS resolution API.

Sadly this approach does not work on Windows, and the `--dnsserver`
has no effect on how resolution is done, and it is always the OS
mechanism that is used.

One can reveal this behavior by running the following piece of code on
Linux and on Windows:

// test.go
package main

import (

func main() {
	resolver := &net.Resolver{
		PreferGo: true,
		Dial: func(ctx context.Context, _, _ string) (net.Conn, error) {
			d := net.Dialer{}
			return d.DialContext(ctx, "udp", "")
	net.DefaultResolver = resolver
	ctx, cancelfunc := context.WithTimeout(context.Background(), 30)
	defer cancelfunc()
	_, err := resolver.LookupTXT(ctx, "")

	fmt.Printf("Error is: %s\n", err)

This piece of code tries to resolve a non-existent domain on a
non-existent DNS server as IP ``.

On Linux, you will get the following error:

Error is: lookup on dial udp i/o timeout

That indicates that the system tried to reach the non-existent DNS server,
and get back a timeout exception on it.

However on Windows you will get:
Error is: lookup dnsquery: DNS name does not exist.

This indicates that the system ignored the dummy DNS server address,
contacted the OS DNS resolver, that responded that the DNS name does
not exist.

One can see also the reason for this behavior on Windows on the `net`
godoc,, in particular this line in the module

On Windows, the resolver always uses C library functions, such as GetAddrInfo and DnsQuery.

In fact, the pure Go DNS resolver is not applicable on Windows, the OS
DNS resolver will be used, ignoring any customization.

Several relevant discussions, in particular a proposal (not developed yet)
to make the pure Go DNS resolver available on Windows:

* golang/go#29621
* golang/go#33097
* golang/go#33086

To fix this, this PR makes Pebble switch to a different logic:
* if `-dnsserver` is not set, use the default API to resolve the names
* if `-dnsserver` is set, use a dedicated DNS client, to avoid to use
the OS one both on Linux and Windows

The DNS client is, a highly used and
supported DNS library.

With these modifications, integrations tests on Certbot are running
correctly both on Linux and Windows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.