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: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14 #37657

Open
lz-dc opened this issue Mar 4, 2020 · 11 comments
Open

net: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14 #37657

lz-dc opened this issue Mar 4, 2020 · 11 comments

Comments

@lz-dc
Copy link

@lz-dc lz-dc commented Mar 4, 2020

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

$ go version
go version go1.14 windows/amd64

Does this issue reproduce with the latest release?

Yes, and differs in behaviour with go version go1.13.8 windows/amd64

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\build\AppData\Local\go-build
set GOENV=C:\Users\build\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\build\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
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 -fmessag
e-length=0 -fdebug-prefix-map=C:\Users\build\AppData\Local\Temp\go-build564695
626=/tmp/go-build -gno-record-gcc-switches

What did you do?

https://play.golang.org/p/oroonTx_Px2

What did you expect to see?

No reverse lookup possible

What did you see instead?

Host: WIN-DESKTOP

@lz-dc lz-dc changed the title Issue with LookupAddr for host "0.0.0.0" on Windows Issue with LookupAddr for address "0.0.0.0" on Windows Mar 4, 2020
@lz-dc lz-dc changed the title Issue with LookupAddr for address "0.0.0.0" on Windows net: Issue with LookupAddr for "0.0.0.0" on Windows in 1.14 Mar 4, 2020
@toothrot toothrot added this to the Backlog milestone Mar 9, 2020
@toothrot
Copy link
Contributor

@toothrot toothrot commented Mar 9, 2020

/cc @mikioh

@networkimprov
Copy link

@networkimprov networkimprov commented Mar 9, 2020

cc @ianlancetaylor @alexbrainman

Note, mikioh has not responded to cc's for about a year, last I checked.

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Mar 21, 2020

@prashantthakre I just built your program with go1.14, and run it on my Windows 10 computer. And it prints

C:\Users\Alex>u:\test
2020/03/21 17:39:57 Host: issue37657

C:\Users\Alex>

What am I doing wrong?

Thank you.

Alex

@lz-dc
Copy link
Author

@lz-dc lz-dc commented Mar 21, 2020

@prashantthakre I just built your program with go1.14, and run it on my Windows 10 computer. And it prints

C:\Users\Alex>u:\test
2020/03/21 17:39:57 Host: issue37657

C:\Users\Alex>

What am I doing wrong?

Thank you.

Alex

It shouldn't be printing that, if condition should never be satisfied. Please try the same with go1.13.x.
You could also try this on macOS/*nix with go1.14 to see the difference.

go version
go version go1.14 darwin/amd64
go prashant.thakre$ go run zero0zero0.go
2020/03/21 13:39:27 No reverse lookup possible

Seems to be a regression compared to go1.13.x

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Mar 22, 2020

It shouldn't be printing that, if condition should never be satisfied. Please try the same with go1.13.x.
You could also try this on macOS/*nix with go1.14 to see the difference.

Yes, I misread your original issue. I bisected this issue to cb325fe

But why do you think 0.0.0.0 should not resolve. For example, try running

Resolve-DnsName -Name 0.0.0.0 -Type PTR | FL

in Powershell. It prints

Name     : 0.0.0.0.in-addr.arpa.
Type     : PTR
TTL      : 1200
Section  : Question
NameHost : issue37657

here.

I reviewed

https://go-review.googlesource.com/c/go/+/178701

But, I am not network expert, maybe I am wrong?

Thank you.

/cc @tdabasinskas

Alex

@lz-dc
Copy link
Author

@lz-dc lz-dc commented Mar 22, 2020

It shouldn't be printing that, if condition should never be satisfied. Please try the same with go1.13.x.
You could also try this on macOS/*nix with go1.14 to see the difference.

Yes, I misread your original issue. I bisected this issue to cb325fe

But why do you think 0.0.0.0 should not resolve. For example, try running

Not saying that it should not resolve, far from being an expert on networking standards.
The main issue being difference across various OS. If the intended behaviour is to return hostname for 0.0.0.0 it should be consistent.

Resolve-DnsName -Name 0.0.0.0 -Type PTR | FL

in Powershell. It prints

Name     : 0.0.0.0.in-addr.arpa.
Type     : PTR
TTL      : 1200
Section  : Question
NameHost : issue37657

Not available on Windows 7, instead tried
C:> nslookup 0.0.0.0
Server: UnKnown
Address: a.b.c.d
***** UnKnown can't find 0.0.0.0: Non-existent domain**

here.

I reviewed

https://go-review.googlesource.com/c/go/+/178701

But, I am not network expert, maybe I am wrong?

Thank you.

#29600 (comment) mentions use of nslookup for verifying 192. ip series, not sure if we should do the same for 0.0.0.0
Also, net package do not seem to have test cases for 0.0.0.0

/cc @tdabasinskas

Alex

Thanks,
Prashant

@lz-dc
Copy link
Author

@lz-dc lz-dc commented Mar 22, 2020

nameinfo.txt
Please find attached sample C/C++ code (a merge of examples from man pages and MSDN).
We do indeed get different results from getnameinfo() for Windows and macOS.
Compiled using Visual Studio C++ compiler and clang++.
macOS> ./a.out 0.0.0.0
addr is a numeric string
getnameinfo returned hostname = 0.0.0.0

macOS> ./a.out 8.8.8.8
addr is FQDN
getnameinfo returned hostname = dns.google

Windows:
C:\workspace\cxx> zero0zero0.exe 0.0.0.0
addr is FQDN
getnameinfo returned hostname = WIN-DESKTOP

C:\workspace\cxx>zero0zero0.exe 8.8.8.8
addr is FQDN
getnameinfo returned hostname = dns.google

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Mar 25, 2020

The main issue being difference across various OS. If the intended behaviour is to return hostname for 0.0.0.0 it should be consistent.

Fair enough. Leaving for others to decide what to do here.

Alex

@iWdGo
Copy link
Contributor

@iWdGo iWdGo commented Mar 28, 2020

net package documentation is mentioning 0.0.0.0 for Dial.
The relevant RFC 5735 is also mentioning 0.0.0.0.
It seems that Windows behavior is appropriate.

@networkimprov
Copy link

@networkimprov networkimprov commented Mar 28, 2020

@prashantthakre is there a different way to do what you need, since MacOS and Windows differ on the meaning of 0.0.0.0?

@lz-dc
Copy link
Author

@lz-dc lz-dc commented Mar 30, 2020

@prashantthakre is there a different way to do what you need, since MacOS and Windows differ on the meaning of 0.0.0.0?

I have already added a check for IsUnspecified() and bypassing LookupAddr().

Regards,
Prashant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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