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: DNS default resolver vs custom resolver behaviors. #29621

Closed
andymacau853 opened this issue Jan 9, 2019 · 6 comments
Closed

net: DNS default resolver vs custom resolver behaviors. #29621

andymacau853 opened this issue Jan 9, 2019 · 6 comments

Comments

@andymacau853
Copy link

@andymacau853 andymacau853 commented Jan 9, 2019

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

$ go version
go version go1.11.4 windows/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
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Project\Go\maas
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=
0 -fdebug-prefix-map=C:\Users\Administrator\AppData\Local\Temp\go-build757481154=/tmp/go-
build -gno-record-gcc-switches

What did you do?

My current PC is not set any DNS server, because I need to test Go's custom resolver, now the code seems not work, the DNS server: 8.8.4.4 is not to use, why?

r := &net.Resolver{
	PreferGo: true,
	Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
		d := net.Dialer{
			Timeout: time.Millisecond * time.Duration(10000),
		}
		return d.DialContext(ctx, "udp", "8.8.4.4:53")
	},
}
ip, err := r.LookupIPAddr(context.Background(), host)

What did you expect to see?

The DNS query should use my custom resolver to get IP address, but it seems not work above code.

What did you see instead?

the error message is "lookup www.xxxxxx.com: no such host"

@julieqiu julieqiu changed the title DNS default resolver vs custom resolver behaviors. net: DNS default resolver vs custom resolver behaviors. Jan 10, 2019
@julieqiu

This comment has been minimized.

Copy link

@julieqiu julieqiu commented Jan 10, 2019

@julieqiu julieqiu added this to the Go1.12 milestone Jan 10, 2019
@mikioh mikioh added the OS-Windows label Jan 11, 2019
@mikioh

This comment has been minimized.

Copy link
Contributor

@mikioh mikioh commented Jan 11, 2019

The docs on the net packages say:

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

See https://godoc.org/net. I think it's fine to change this issue to a proposal for enabling the built-in DNS stub resolver even on Windows, although, I'm not a Windows user and have no Windows stuff.

@andymacau853

This comment has been minimized.

Copy link
Author

@andymacau853 andymacau853 commented Jan 11, 2019

The docs on the net packages says:

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

See https://godoc.org/net. I think it's fine to change this issue to a proposal for enabling the built-in DNS stub resolver even on Windows, although, I'm not a Windows user and have no Windows stuff.

So do u mean, when i deploy to Linux platform, Is above code work?

@mikioh

This comment has been minimized.

Copy link
Contributor

@mikioh mikioh commented Jan 11, 2019

above code work?

I don't say "yup" instantly because I don't know any detail on your circumstances; please be informed that DNS is a system requiring three role nodes, a stub resolver, a recursive server (aka full resolver) and an authoritative server on IP-based transport networks. If you can ensure that your circumstances are pretty clear (nowadays, it's pretty hard to find out such "clear/ideal circumstances", though), your approach may succeed.

@mikioh

This comment has been minimized.

Copy link
Contributor

@mikioh mikioh commented Jan 15, 2019

@andymacau853,

Please re-title this issue like "proposal: net: enable built-in DNS stub resolver on Windows" if you really want the functionality.

@mikioh mikioh modified the milestones: Go1.12, Unplanned Jan 15, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Feb 15, 2019

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Feb 15, 2019
jsha added a commit to letsencrypt/pebble that referenced this issue Jul 29, 2019
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:

```go
// test.go
package main

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

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

	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 `4.3.2.1:404`.

On Linux, you will get the following error:

```bash
Error is: lookup stupid.entry.net on 127.0.0.53:53: dial udp 4.3.2.1:404: 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:
```bash
Error is: lookup stupid.entry.net: 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, https://godoc.org/net, in particular this line in the module
introduction:

```
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 https://github.com/miekg/dns, a highly used and
supported DNS library.

With these modifications, integrations tests on Certbot are running
correctly both on Linux and Windows.
@golang golang locked and limited conversation to collaborators Feb 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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