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
Labels
FrozenDueToAge OS-Windows WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@andymacau853
Copy link

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 julieqiu added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 10, 2019
@julieqiu
Copy link
Member

/cc @mikioh @bradfitz

@julieqiu julieqiu added this to the Go1.12 milestone Jan 10, 2019
@mikioh
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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 added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jan 15, 2019
@mikioh mikioh modified the milestones: Go1.12, Unplanned Jan 15, 2019
@gopherbot
Copy link

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.)

jsha pushed 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.
Labels
FrozenDueToAge OS-Windows WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants