Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net: LookupAddr changed result form in Go 1.5 #12189
Reported via email: LookupAddr("220.127.116.11") returned "google-public-dns-a.google.com." (with trailing dot) in all Go releases to date. In Go 1.5 candidate it returns "google-public-dns.a.google.com" (no trailing dot).
This was an intentional change, in CL 3420, but I believe it was a mistake. The argument made there was that the result was inconsistent depending on whether the C library resolver or the pure Go DNS resolver was being used. But Go 1.4 and earlier never used the C library resolver for this query. So the inconsistency indicated was only introduced after Go 1.4 and does not justify deviating from the Go 1.4 behavior.
I am still investigating and will post more details when I'm done, but right now it looks like we should put the dot back for consistency with all previous Go releases.
I checked all the Lookup functions. Here is a program to do that (comment out the NS code in Go 1):
Here are some Go versions running on Linux:
Compiled with plain make.bash (so cgo is enabled):
Compiled with CGO_ENABLED=0 make.bash:
It may be different on non-Linux systems, but it seems like literally every release of Go to date has had the trailing dot, while the current 1.5 tree has dropped it.
Furthermore, the dropping of the trailing dot in LookupAddr appears to be inconsistent with all the other functions, even in Go 1.5. (LookupTXT doesn't count, since it returns uninterpreted text, but I wanted to run all the Lookups.)
For both these reasons I think we should put the final dot back in.
I will prepare a CL.
This is even worse than I thought. There is no code that takes the dot out from the Go lookups. The problem is that by default, and even when you set GODEBUG=netdns=go, the code tries the new C library wrappers before trying pure Go.
So not only did the result change, but now each blocked LookupAddr takes a full thread instead of a goroutine. That behavior definitely has to be rolled back.
Same test ran on