net: LookupHost shows different results between GODEBUG=netdns=cgo and go

[ramspoluri]

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]

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]

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]

Linux probably does the same when using the cgo resolver.

[mikioh]

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