search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.2k stars 17.57k forks source link

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

Closed krhubert closed 7 years ago

krhubert commented 8 years ago

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 commented 8 years ago

Yes, that's surprising.

/cc @mikioh

mikioh commented 8 years ago

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 commented 8 years ago

Also ResolveIPAddr has the same issue.

krhubert commented 8 years ago

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

deankarn commented 8 years ago

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

rsc commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

gopherbot commented 7 years ago

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