RemoteMultiaddr should be fully resolved

[Stebalien]

The addr returned by RemoteMultiaddr should be fully resolved, even if the user dials with a /dns address.

[marten-seemann]

What is a /dns address? How do we resolve it?

[Stebalien]

DNS Address: /dns/some.domain/udp/127/quic

The QUIC transport already calls ResolveUDPAddr and gets a udp address when it dials the target. It just needs to take that resolved udp address and turn it back into a QUIC multiaddr.

[marten-seemann]

I'm not sure if resolving addresses works at all.

Creating a new /dns-QUIC-Multiaddr works:

ma.NewMultiaddr("/dns/google.com/udp/443/quic")

However, using that to dial a connection fails: invalid network: must be either udp4 or udp6.

Resolving a udp4-multiaddr fails:

ma.NewMultiaddr("/dns/google.com/udp4/443/quic")

errors withfailed to parse multiaddr "/dns/localhost/udp4/443/quic": unknown protocol udp4.

[Stebalien]

udp4 is not a valid multiaddr component. /dns/google.com/udp/443/quic would resolve to /ip4/..../udp/443/quic. You need to take the result of calling ResolveUDPAddr in transport.Dial and call toQuicMultiaddr on it.

[marten-seemann]

/dns/google.com/udp/443/quic would resolve to /ip4/..../udp/443/quic.

Not really, manet.DialArgs gives me udp and google.com:443. I can then pass this into ResolveUDPAddr to resolve that to a net.UDPAddr. This still doesn't tell us if this a udp4 or udp6.
We could us the IP address to determine if this is likely an IPv4 or IPv6 address, but this will likely be incorrect in some corner cases, see https://stackoverflow.com/questions/22751035/golang-distinguish-ipv4-ipv6.

I'm wondering, why is this each transport's responsibility to resolve the DNS address? It seems like every transport has to implement a very similar code path to do that. Wouldn't it make more sense to resolve the address before passing it to Dial?

[Stebalien]

It's not generally each transport's job to resolve the address, the swarm usually handles that internally. That's the other half of the bug.

However, the quic transport should either reject these addresses (probably the better solution) or resolve them.

[raulk]

IMO:

• Transports should be responsible for translating the addressing schemes they support. Either implicitly during the outbound dial, or by exposing a ResolveAddr(multiaddr) method that the network/swarm can invoke.
  • Reasoning here: Address filtering is semi-broken go-libp2p#841 (comment).
• RemoteMultiaddr() should return the actual addr we're connected to. The remote endpoint could be DNS load-balanced; returning a non-resolved address is insufficient. If we're recording an instrumentation trace to analyse after the fact, knowing the actual IP address is more useful than the hostname.

I would recommend for go-libp2p-quic-transport to pipe all outbound dials through https://github.com/multiformats/go-multiaddr-dns to perform resolution. You can then dial the resulting multiaddr as you're doing now: https://godoc.org/github.com/multiformats/go-multiaddr-dns#Resolve (and record that in the state of the connection to return when RemoteMultiaddr() is called).

[marten-seemann]

@Stebalien Was this issue resolved by #131?

[Stebalien]

Yep! Thanks!