This was something I pined for w/Convox 4-5 years ago when I used it on a project – I had to use the Weave AMI to be able to do instance discovery via DNS, because I recall direct access from one ECS container to another wasn’t a happy path.
Now Convox uses Kubernetes, but I still don’t see a way to get the effect of eg. clusterIP: None. That lets you nslookup a service, and get IPs of all of the pods backing it.
I like that feature of k8s – it makes it easy to connect things with just port 53. As opposed to requiring folks to run some kind of service discovery (etcd, blah), or calling the k8s or convox apis; cluster-wide IP-per-service-instance (k8s Pod/convox Instance) being so widely accepted as table stakes for container orchestration make it a non-risky bet too.
It’d be amazing to be able to support getting the IPs of pods that way!
I wonder – some grepping around suggests that this is the place that one would slot that in, an optional key in a convox.yml service definition, maybe like ‘headless: true’, could be used as the basis for conditionally slotting in clusterIP: None there? I’m not familiar with all of how that works, but I think I see the templating there is using values that might come from a convox.yml (don’t know offhand if there’d be anything else that’d need to change, like some kind of schema validation against the convox.yml file).
I’d be willing to help w/that this weekend or next; I contributed a trivial PR to Convox way back when – though (a) I don’t know how I’d go about testing the PR myself necessarily, hopefully it’d be straightforward, (b) there’s no slack channel any more I see, so hard to get pointed in right direction © there’s no Issues tab in convox/convox on Github, for obvious reasons maybe, so maybe I could open a crappy Draft PR then, which we could use for discussion? (d) this forum helpfully mentions that it takes an average of 2 weeks to get a reply, though I imagine that it’ll get busier for the same reasons that I’m here now: y’all made something people want 
FYI, my use case – the reason I was interested in this (today as 4 years ago, actually), is so that Convox can work with dns-based cluster formation in BEAM VM langs. But it’s applicable anywhere you want to connect things; there, you start up your release with a templated-from-env-var node name, telling it "when you run, your name will be service_name@$MY_POD_IP", and then you can tell it to connect to other node names with that format, finding the IP addrs from DNS occasionally, and if it gets connection attempts it’ll respond to that name.
A k8s headless services make that easy peasy, and BEAM langs make it even more useful since nodes help each other get strongly connected (example discussion).