Tracking issue for DNS in std::net

[alexcrichton]

This is a tracking issue for the lookup_addr and lookup_host unstable features in the standard library. These are currently the only exposed support for DNS as a public interface. Functions like TcpStream::connect already expose the ability to resolve names via passing a string, but this cannot be done programmatically currently.

There are a number of thorny issues to deal with here:

• Is calling getaddrinfo and getnameinfo here appropriate?
• What should the arguments be? Should this use a builder?
• In the getaddrinfo case, should IP addresses or socket addresses be returned?
• In the getnameinfo case, should IP addresses or socket addresses be taken?
• What should the return values look like? Iterators? Structs exposing accessors? (like DirEntry)

[SimonSapin]

I’d like to impl ToSocketAddrs for Url in rust-url. The URL parser already differentiates DNS names from IP addresses: https://url.spec.whatwg.org/#host-parsing. (And the algorithm is slightly different from Ipv{4,6}Addr::parse in some edge cases.) So I’d like some way to look up a DNS name. ToSocketAddrs for str does this, but it also attempts to parse an IP address, which is redundant.

I think a guiding principle in some other parts of std has been to (also) expose what the platform (~ OS + libc) provides without mandatory additional behavior on top, and stabilizing lookup_host fits in that principle. (It turns out that getaddrinfo in some libc’s also attempts to parse IP addresses, but that’s another story…)

---

I think the return value of lookup_host should be (an iterator of) IP addresses, not SocketAddr with an arbitrary port number. This could be a reason to bring back IpAddr #27801

[aturon]

@SimonSapin proposes stabilization for this cycle.

[alexcrichton]

The libs team discussed this during triage yesterday and the conclusion was to not move this into FCP just yet. I personally have a number of concerns about the API exposed here in that I think it's insufficient for exporting all the functionality we want and it's also insufficient for giving back all the information that we get.

I would be interested in seeing this developed externally on crates.io and then perhaps move it into the standard library. For now the libstd support won't be deprecated until a replacement externally exists, but I may work on such a replacement in the near future if no one else gets around to it!

[canndrew]

+1 to everything @SimonSapin said. DNS is a mapping of names to IP addresses, not IP addresses+ports, so SocketAddr is the wrong type here. It's shame that IpAddr was removed for "not pulling it's weight" despite people speaking up and saying they were using it. How much can something like that weigh?

[SimonSapin]

Should lookup_addr have been un-deprecated along with IpAddr? (#31438)

[photino]

What is the decision on lookup_addr?

[aturon]

Whoops, missed @SimonSapin's comment. cc @rust-lang/libs -- the question is, given that we have stabilized IpAddr, what should happen to lookup_addr?