I found one library in the past that supports pure Java async lookups, but that's another dependency and risk: http://www.xbill.org/dnsjava/

Can't we use the same techniques and just reimpl it? Is it a lot of work?

It is a pure Java based DNS client implementation. Not an easy task considering all the DNS extensions existing out there... I am not a DNS expert though, it might be that a subset is sufficient. It would be great addition to our IO library though.

Looking at the code, we are mostly interested in "A" records and friends, so I think it is possible to have a pure Scala+Akka implementation.

FTR:
netty has already invested quite a bit of time/work into a proper solution,
check out these two PRs:

- https://github.com/netty/netty/pull/1354 which was later superceded by
- https://github.com/netty/netty/pull/1622

@normanmaurer merged the latter one into [this branch](https://github.com/netty/netty/tree/dns) just three days ago.

I haven't looked at the code at all so far, but seeing the amount of discussion and review that the PRs have received I trust there is something interesting there.

Pointers to related tickets:
- https://github.com/spray/spray/issues/73
- https://github.com/playframework/playframework/issues/1997

Unfortunately (? I might be too old-school) this covers only one particular way of name resolution which happens to lend itself well to asynchronous treatment. We would basically have to say that traditional mechanisms (/etc/nsswitch.conf) are not supported by Akka, because reimplementing that is not even possible since the interface is the shared object ABI (aka native libraries outside our control). This might be the most reasonable response, but it requires proper thought.

In the meantime: thanks @sirthias for the links! What is your take on what web services or clients expect in terms of flexibility in configuring name resolution?

On the server-side DNS is usually not a problem and on the client side it depends very much on how important name lookup is for the application. Most applications will only need to communicate with a very limited number of servers, so name lookup is (if at all) only slow at startup and can be dealt with.
The applications that suffer most from DNS-related performance problems are the ones that need to do a lot of lookups over long periods of their operations, like robots, spiders, scrapers or general network analysis tools.

We are talking about different things: doing name resolution using the JDK APIs means that a broken LDAP server might hang your program for minutes (which is something we have seen in our own tests). Solving DNS lookup is nice, but then we don’t support all the other means for name resolution any longer. The question was: is that a problem?