Please see https://github.com/golang/go/wiki/Questions. Closing.

@mdlayher isn't it a bug? I haven't seen this in any other languages using a simple Http request...

Hundreds of thousands of people are able to use Go to make TCP connections successfully. If you really think this is a bug in Go, and not in your local DNS server, then show us a complete, self-contained Go program that demonstrates the problem. The error message you show above is not coming from the code you show above, so there is nothing here for us to investigate.

But I recommend you sart with a forum, as @mdlayher suggested.

hi @ianlancetaylor I already showed all the code that I used. I know it's hard to reproduce because even on my side it just happens 1 out of 100 probably, but at lease please just search in the code using the error message that I provided, if go don't want to do real opensourcing then please just make it private.

I'm not a person who would like to waste time creating junk issue for go, I used go for openwrt devices, it worked quite well. I made this issue because this error happened during my important demo with a super good internet. It then happened again on production server.

That's why I think there must be a bug

@ianlancetaylor @mdlayher I made a simple gif to demonstrate go's http get's problem, I've got really too much timeout error.

You can see nodejs's axios performs much better than go http get, it doesn't have any timeout error at the beginning, at last it does get timeout errors but I think that's maybe caused by limited resources or other reason.

test.go

// Package main provides ...
package main

import (
	"errors"
	"fmt"
	"net/http"
	"strings"
	"time"
)

func DiscoverVersions(baseUrl string) ([]string, error) {
	if !strings.HasSuffix(baseUrl, "/") {
		baseUrl = fmt.Sprintf("%s/", baseUrl)
	}

	res, err := http.Get(baseUrl)
	if err != nil {
		return nil, err
	}
	defer res.Body.Close()
	if res.StatusCode != 200 {
		errMsg := fmt.Sprintf("status code error: %s", res.Status)
		return nil, errors.New(errMsg)
	}

	return []string{}, nil
}

func main() {
	for {
		_, err := DiscoverVersions("https://fr-cloud.ubudu.com")
		if err != nil {
			fmt.Printf("error %v\n", err)
		}
		time.Sleep(1 * time.Second)
	}
}

test.js

const axios = require("axios");

setInterval(() => {
    axios.get("https://fr-cloud.ubudu.com/").catch(console.log);
}, 1000);

However, I cannot reproduce the DNS lookup no such host error, I'll try to make it reproducible once got time. I'm sure there is a bug because with other languages I never ran into that much DNS lookup issues

See the discussion of "Name Resolution" at https://golang.org/pkg/net. See if setting the environment variable GODEBUG=netdns=cgo helps.

Hello, I have some information to add to this. Please check if it should be reopened if it appears to actually be a bug and/or if I should open a new issue.

I narrowed it down to this issue occurring when accessing a "private" domain (I don't know the correct terminology) on our corporate network reachable over VPN, when using a binary on macOS which was compiled on Linux (or rather, in the golang:1.15 Docker container in my specific case).

I observed the following (all when running the binary on macOS):

The full error message in my case is:

Get "https://private-domain...": dial tcp: lookup private-domain... on 192.168.1.1:53: no such host

This is quite a problem for us, because we have some internal tools that we run on our Macbooks, but compile in Docker containers.

Please let me know if there are any additional steps I can take to provide even more information, especially to determine if this is actually a bug in Go, or a corrupt DNS setup.

have you verified that it actually uses your selected resolver of go/cgo? GODEBUG=netdns=cgo+1

have you verified that it actually uses your selected resolver of go/cgo? GODEBUG=netdns=cgo+1

I hadn't, but doing this provided some more insight indeed. With the Mac built binary, it says using cgo DNS resolver and GODEBUG setting forcing use of Go's resolver (same results as above, works with cgo, doesn't work with go). With the Linux (Docker) built binary, in either case it just says built with netgo build tag; using Go's DNS resolver. Note that I didn't specify that explicitly, I literally only did GOOS=darwin GOARCH=amd64 go build main.go.

Though I guess it makes sense that when it's built on Linux, it can't use cgo when running on Mac? When I add -tags netcgo to the build, it says /usr/local/go/src/net/cgo_bsd.go:15:72: could not determine kind of name for C.AI_MASK. But perhaps now it's yet becoming more of a discussion rather than a bug report.

Let me know if I can provide any additional information for this issue.