Don't use a thread pool for DNS resolution

[tomaka]

Right now, we use a thread pool dedicated to resolving domain names by calling to_socket_addrs. Theoretically, there's no reason for it not to be asynchronous.

In practice, as far as I know, there's no way to do at at the moment. However I'm opening this issue anyway in order to not forget about that in the long term.

[mxinden]

Do I understand correctly that tokio-dns-unofficial uses the host OS's resolver via a thread pool?

In that case I find the name of the issue a bit misleading. How about "Don't use synchronous host OS's dns resolver via thread pool"?

Async in process dns resolution

In case an in-process DNS async resolver adhering to /etc/resolv.conf is an option, how about trust dns resolver?

Async OS dns resolution

Or in case we mostly target Linux and fall back to synchronous DNS resolution, something like getaddrinfo_a could be an option.

What do you think @tomaka?

[tomaka]

I think that we shouldn't waste any energy on that issue, at least not before async/await.

[tomaka]

For what it's worth, async-std decided to use background tasks: async-rs/async-std#74

[DemiMarie]

I think we could use either trust-dns or libasr. The latter is a C library, but it comes from OpenBSD and is used in OpenSMTPD among other projects, so I am quite confident in its security.