This is a followup to issues #31597 and #37031.

It is my current understanding that no valid host can contain the null byte ('\x00'), so any such string input is not valid.

net.LookupHost currently operates differently when given an input that contains a null byte. For example, for net.LookupHost("foo\x00bar"):

• in Go 1.13, on Windows, it caused a panic (net: call net.ResolveIPAddr with nul char causes a panic in the goroutine on Windows build #31597)
• in Go 1.14, on Windows, it returns an error (see here)
• on macOS with cgo DNS resolver, it does the equivalent of net.LookupHost("foo")
• on macOS with pure Go DNS resolver, it does something different

It seems that the getaddrinfo C API used on many platforms accepts a null-terminated C-style string and cannot be given a string containing null bytes.

As @ianlancetaylor points out, in the syscall package we reject strings with embedded null bytes, since they won't work with system calls that expect C strings, see syscall.ByteSliceFromString.

Perhaps this is an opportunity to make Go operate more consistently on such inputs on all platforms by reporting an error when the name string contains a null byte. There may be more functions in net that could benefit from this input validation, but to be able to make this change, we need to be confident that this change won't break correct Go programs.

/cc @FiloSottile @ianlancetaylor @mikioh @bradfitz