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

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

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

lz-dc opened this issue Mar 4, 2020 · 12 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@lz-dc
Copy link

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 OS-Windows NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 9, 2020
@toothrot toothrot added this to the Backlog milestone Mar 9, 2020
@toothrot
Copy link
Contributor

toothrot commented Mar 9, 2020

/cc @mikioh

@networkimprov
Copy link

cc @ianlancetaylor @alexbrainman

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

@alexbrainman
Copy link
Member

@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 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

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

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

@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 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

@seankhliao
Copy link
Member

This appears to be working as intended

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Jan 28, 2023
@golang golang locked and limited conversation to collaborators Jan 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Development

No branches or pull requests

7 participants