net: Resolve{TCP,UDP,IP}Addr doesn't return error when net and address are in different family

[krhubert]

https://play.golang.org/p/1lf51v8MII

I think resolver should return error it this case, Someone is expecting to get ipv4:port when resolving tcp4 address.

ResolveUDPAddr has the same issue

[bradfitz]

Yes, that's surprising.

/cc @mikioh

[mikioh]

Yup, I reserved this issue for people who want to figure out what's the best way to grab literal IPv4, IPv6 and Ipv6 translator addresses. ;) Please consider all possibilities. For example,

"tcp" [prefix:192.0.2.33]:80 -- IPv4 or IPv6?
"tcp" [prefix:c000:0221]:80 -- IPv4 or IPv6?
"tcp4" [prefix:192.0.2.33]:80 -- Should we return 192.168.0.2.33?
"tcp6" [prefix:192.0.2.33]:80

prefix -- IPv4-embedded IPv6 address prefix

[mikioh]

Also ResolveIPAddr has the same issue.

[krhubert]

Also ResolveIPAddr has the same issue. => that's true.
Also ResolveUnixAddr return nil error when address is empty string.

[deankarn]

I think that ResolveUnixAddr is ok parsing blank as it's equivalent to 0.0.0.0 from what I understand

[rsc]

The resolver code already has a filter it applies to the addresses it gets back from DNS. The literal IP path was bypassing that filter. The simplest and therefore most compelling fix is to apply the filter to the literal IPs too. That is, the code has already made a decision for the question @mikioh asked. Empirically, it is:

tcp  127.0.0.1:http            ok
tcp  [::ffff:127.0.0.1]:http   ok
tcp  [2001:db8::1]:http        ok

tcp4 127.0.0.1:http            ok
tcp4 [::ffff:127.0.0.1]:http   ok
tcp4 [2001:db8::1]:http        FAIL - no suitable address

tcp6 127.0.0.1:http            FAIL - no suitable address
tcp6 [::ffff:127.0.0.1]:http   FAIL - no suitable address
tcp6 [2001:db8::1]:http        ok

The failure of tcp6 for [::ffff:127.0.0.1]:http is maybe a little surprising, but it keeps the tcp4 and tcp6 successes disjoint, which seems correct. Since ::ffff:127.0.0.1 is just a funny way to spell an IPv4 address, semantically this seems right. It is at least in keeping with the rest of the package: remember, I didn't do anything except call the existing filtering routine.

Will send a CL.

[mikioh]

@rsc,

The failure on tcp6 for [::ffff:127.0.0.1]:http is fine and intentional because it's an IPv4-mapped IPv6 address that is used in protocol stack internally for convenience and should never appear on the wire. What I feel a difficulty is an IPv4-embedded IPv6 address for IP translators defined in https://tools.ietf.org/html/rfc6052.

[gopherbot]

CL https://golang.org/cl/32100 mentions this issue.