Containers-roadmap: [ECS] [request]: Valid SRV qname for service discovery

Created on 27 Aug 2019 · 4Comments · Source: aws/containers-roadmap

Tell us about your request
Add option to use the RFC 2782-compliant _service._proto.namespace SRV record qname format for ECS / Cloud Map. Currently the SRV qname format is identical to the A record format: service.namespace.

Which service(s) is this request for?
ECS, Cloud Map (aka Service Discovery)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I'm trying to use HAProxy with ECS tasks as backends, but HAProxy will only try SRV resolution if the qname starts with an underscore. Therefore, the SRV records produced by ECS / Cloud Map cannot be used with HAProxy (or other services that rely on the spec format).

Are you currently working around this issue?
The current work-around is to rely solely on A records, and to be very vigilant with DNS caching, re-lookups, etc.

Docs ECS Proposed

Source

sveniu

Most helpful comment

Is there a reason why just naming your service in Cloud Map according to the RFC 2782 format won't work? There is no requirement that the service name in Cloud Map be the same as the name of the ECS service. So for example if your Cloud Map zone is .local, you can name your service _myservice._tcp and it will be DNS-resolvable as _myservice._tcp.local. This works with SRV records also. Please let me know if there is something I am misunderstanding!

coultn on 11 Sep 2019

👍3

All 4 comments

coultn on 11 Sep 2019

👍3

Is there a reason why just naming your service in Cloud Map according to the RFC 2782 format won't work?

I just spent all night chasing down the same issue, and I can confirm that this is a valid workaround.

Perhaps it would be best to surface this somewhere in the documentation? I never, ever would have thought to just put the appropriate values directly into the service name.

eedwards-sk on 12 Sep 2019

I actually spend the night as well trying to find out why HAProxy does not resolve my SRV records generated by ECS service discovery, and yepp, it's the missing underscore prefix... After prefixing my service name with an underscore, it works perfectly.