Personally, I like how Kubernetes handles this with an independent service that's built upon flannel (Kube-DNS). I'd rather Docker stick to running containers, and that's it.
I tried Weave but ultimately had to abandon it, as there were too many issues in resolving DNS directly to containers. Kubernetes resolves DNS to a virtual IP that in turns maps to the container IPs, which I found to be a much better approach.
My initial work with it was pre-docker networking. Admittedly, I need to spend more time with Kubernetes, but the rapid evolution and multiple solutions to service discoverability, load balancing, and networking in the Docker eco-system is a bit of a challenge to keep on top of and figure out what's best/right for the situation. I suspect, near term, the solution is "what works for me now, I'll figure out something else as I have time/down the road."
You also have to account for how your individual programming language handles DNS lookups - i.e. does it do its own caching? Round robin can quickly breaks down when using DNS.
My intention was to send the same message. That's why I put Docker DNS as "potentially useful but still in its infancy".
This is the reason why kubernetes uses proxying rather than DNS for load balancing. The number of pitfalls with using DNS for loadbalancing are just too large.