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: LookupHost shows different results between GODEBUG=netdns=cgo and go #22902

Open
ramspoluri opened this issue Nov 28, 2017 · 4 comments
Open
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@ramspoluri
Copy link

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

go version go1.9.2 darwin/amd64

What did you do?

package main

import (
	"net"
	"fmt"
)

func main() {
	fmt.Println(net.LookupHost("10.256"))
	fmt.Println(net.LookupHost("10.256.1"))
	fmt.Println(net.LookupHost("10.10.256"))
	fmt.Println(net.LookupHost("10.10.256.1"))
	fmt.Println(net.LookupHost("10.10.10.256"))
}

What did you expect to see?

This program works fine on both Linux & Windows and does show below output, but not on Mac

[] lookup 10.256: no such host
[] lookup 10.256.1: no such host
[] lookup 10.10.256: no such host
[] lookup 10.10.256.1: no such host
[] lookup 10.10.10.256: no such host

What did you see instead?

[10.0.1.0] <nil>
[] lookup 10.256.1: no such host
[10.10.1.0] <nil>
[] lookup 10.10.256.1: no such host
[] lookup 10.10.10.256: no such host
@gregory-m
Copy link
Contributor

gregory-m commented Nov 28, 2017

This is correct behaviour and it same for both linux and mac.

Plase see inet_aton(3) man page for more details:

The address supplied in cp can have one of the following forms:
....

a.b.c

Parts a and b specify the first two bytes of the binary address. Part c is interpreted 
as a 16-bit value that defines the rightmost two bytes of the binary address. 
This notation is suitable for specifying (outmoded) Class B network addresses.

a.b

Part a specifies the first byte of the binary address. Part b is interpreted as a 24-bit 
value that defines the rightmost three bytes of the binary address. This notation is 
suitable for specifying (outmoded) Class C network addresses.

Thank you.

@ramspoluri
Copy link
Author

Thanks Gregory.

I still confused with difference in output between Linux & Mac. Looks like Mac is showing correct output and it should be like that, not Linux.

@slrz
Copy link

slrz commented Nov 28, 2017

Linux probably does the same when using the cgo resolver.

@mikioh
Copy link
Contributor

mikioh commented Nov 29, 2017

When GODEBUG=netdns=cgo, general name resolution depends on external functionality provided by userspace stuff such as libc (the behavior is different between implementations, for example, libc on BSD variants vs. libc on macOS/iOS vs. glibc vs. Windows API vs. Plan 9), and when GODEBUG=netdns=go, DNS name resolution uses only package internal helpers.

I think it's fine to align IP literal handling with the existing GODEUG=netdns=go behavior basically (because no one never uses classful IPv4 routing), though I'm still wondering whether we should deal with IP address synthesis as described in RFC 7050. Without application context, it's very hard to determine what's correct and what's not.

A friend: #20790

@mikioh mikioh changed the title net: LookupHost show incorrect results on Mac (darwin) net: LookupHost shows different results between GODEBUG=netdns=cgo and go Nov 29, 2017
@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Mar 29, 2018
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Mar 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants