-
Notifications
You must be signed in to change notification settings - Fork 18k
net: cgoLookupAddrPTR returns single PTR regardless of number of PTR records #17093
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
Comments
/cc @ianlancetaylor |
I'm not sure what to do about this. The cgo code does a |
Just to add some more thoughts here - as an end-user, the frustrating part for me wasn't really the ability to get multiple records. What frustrated me was the fact that the documentation states that I should receive multiple records for this call, and the default behavior will only return one.
The other really fun part of this is that (at least) BIND9 will return record results for a query in a random order. This means that if |
At minimum we could document the situation I suppose. |
@bradfitz, it looks to me like we should document LookupAddr with something like
but that requires actually making (*Resolver).LookupAddr respect PreferGo, which it does not today. I filed #17532 for that. |
CL https://golang.org/cl/31720 mentions this issue. |
I've looked around at this and I'm pretty sure this is a bug with how the Cgo implementation gets PTR records using
getnameinfo
versus the native Go implementation.What version of Go are you using (
go version
)?go version go1.7.1 darwin/amd64
What operating system and processor architecture are you using (
go env
)?What did you do?
net.LookupAddr("138.12.4.174")
or any other IP that has multiple PTR recordsWhat did you expect to see?
Multiple hostnames returned
What did you see instead?
Only one hostname returned when using Cgo. By setting
CGO_ENABLED=0
, the native Go implementation is used instead, and multiple PTR records are returned as expected.The text was updated successfully, but these errors were encountered: