[Proposal] Add Resolv class to standard library

[watzon]

I know this could be done as a shard, but seeing as this is a Rubyesque language and it would make the transition from Ruby to Crystal just that much easier I feel as though Crystal could use a Resolv class similar to that of Ruby. Ruby's Resolv class is a thread-aware DNS resolver with a syntax that looks like this

p Resolv.getaddress "www.ruby-lang.org"
p Resolv.getname "210.251.121.214"

Resolv::DNS.open do |dns|
  ress = dns.getresources "www.ruby-lang.org", Resolv::DNS::Resource::IN::A
  p ress.map(&:address)
  ress = dns.getresources "ruby-lang.org", Resolv::DNS::Resource::IN::MX
  p ress.map { |r| [r.exchange.to_s, r.preference] }
end

I'm not great at proposals, so just give your questions and opinions :)

[RX14]

We have a Socket::Addrinfo class which can be used for basic hostname lookups. However, my main concern is that the naming is awfully platform-specific and the interface is limited. I'd like that interface to be redesigned before launch.

[jhass]

Let's have a good interface to the respective system resolver, yeah. However let's not have a full DNS resolver in the standard library and instead encourage use of a proper DNS resolver implementation that handles all the known quirks and DNSSEC, in other words let's encourage shards that bind libunbound or ldns.

[RX14]

@jhass I wasn't proposing anything too complex, just enough to look up the values of arbitrary record types at arbitrary addresses. Something under the namespace DNS, unless anyone has a better idea.

[jhass]

Sure, more replying to the OP than you :)

[ysbaddaden]

naming is awfully platform-specific

Well, Windows uses getaddrinfo too:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx

Additionaly, using another naming like Resolv or DNS could lead to confusion and false expectations
—I'd expect a Socket::DNS to resolve MX and any other arbitrary entries.

the interface is limited

getaddrinfo is limited by design, and merely returns A and AAAA records; we can't do much better.

Any improvement would require to use a full-featured DNS resolver. I think a binding to libunbound would make a great dns shard, too.

[akzhan]

Node used c-ares previously but now depends on libuv.

libevent has libevnet that uses c-ares but want to replace it with its own code.

[ysbaddaden]

We don't use libevent because it doesn't use the system resolver, and thus is incapable to resolve lots of domains we'd expect it to (e.g. .local or docker).

[RX14]

@ysbaddaden I'd expect crystal's DNS to resolve MX and any other arbitrary entries. That's not a full-featured DNS client, that's basic functionality.

I'd expect crystal's stdlib to be able to:

• resolve the values of arbitrary record types at arbitrary domains
• use the system resolver so that resolv.conf and /etc/hosts are correctly read.

That's it.

[rdp]

See also #4236 . Having pluggable DNS options would also allow those with "slow DNS" to still operate instead of block the world, so +1 from me #8376