fix(websocket): don't dial `/dnsaddr` addresses

[hmzdot]

Description

Returns Error::InvalidMultiaddr when parse_ws_dial_addr is called with /dnsaddr.

As per its specification, /dnsaddr domains are not meant to be directly dialed, instead it should be appended with _dnsaddr. and used for DNS lookups afterwards

Related: #5529 Fixes: #5601

Notes & open questions

• Is it okay to return an error, or should I perform a DNS lookup and resolve that DNS afterwards if address has /dnsaddr?
• If so, how should I handle that case where DNS lookup returns multiple multiaddrs?

Change checklist

• [x] I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] A changelog entry has been made in the appropriate crates

[oblique]

websocket-websys needs this change too.

[hmzdot]

bsys needs this change too.

I see, will update there as well

[DougAnderson444]

Hello

I just opened https://github.com/libp2p/rust-libp2p/issues/5619 because I want to dial /dnsaddr from webrtc-websys. Then I noticed this issue.

Would it make sense to simply support DNS multiaddr resolution in the browser?

[DougAnderson444]

Also https://github.com/libp2p/rust-libp2p/issues/5531 could enable this?

[oblique]

@DougAnderson444 As described in #5601, this PR removes an incorrect handling of /dnsaddr. #5531 is the only way forward which needs to implement resolution of only /dnsaddr multiaddresses through a new Transport that targets only browsers.

[hmzdot]

Updated websocket-websys (bf23e92b6ccd60ebe65d08d2436dee62d80946ba) so that it returns None when a /dnsaddr is extracted. This should be enough to fix incorrect handling of /dnsaddr and to resolve them correctly we can continue from #5531

cc: @dariusc93

[hmzdot]

Previous CI runs failed because I didn't update top-level versions, my bad. Can you restart the workflow? @oblique

[oblique]

cc @jxs