Expected behaviour
When a service is started with --endpoint-mode dnsrr, a dns lookup of the service name should return only tasks belonging to the same service.
Actual behavior
nslookup returns, in addition to the desired service tasks, other, seemingly random tasks that happen to be in the same network.
Additional Information
After starting a container with a constraint so that it runs on the same manager node I’m currently connected to, I can do this:
$ docker exec -it 742 nslookup consul_server
nslookup: can't resolve '(null)': Name does not resolve
Name: consul_server
Address 1: 10.0.0.25 consul_server.3.2qxrhipbcc572ibk1z5f9yuuk.infra
Address 2: 10.0.0.24 consul_server.2.bd7b0oqjpajo1ke7skrkb2rjj.infra
Address 3: 10.0.0.11 consul_server.1.8equc44lp4cav1svgc42ecf9y.infra
Address 4: 10.0.0.13 kibana.1.6phyldn6a91qod65a8ydbqytt.infra
Address 5: 10.0.0.39 dockerbeat.0.carldng9i5phi0lc0yd7g2xuu.infra
Kibana and dockerbeat definitely should not be there! That makes all sorts of things break…
Steps to reproduce the behaviour
Unfortunately I have not been able to reproduce this reliably. It’s usually, start some services, tinker around doing updates etc, eventually things will start breaking in mysterious ways like this. I’m using Docker for AWS beta5. If anyone could give me some guidelines on how to debug those issues I’d be really grateful.