Aws-app-mesh-roadmap: Intercept and respond to DNS queries for Virtual Services using Envoy's DNS filter

[bcelenza]

Tell us about your request

As the owner of a service in App Mesh, I would like to use simple hostnames to call my dependencies.

For example, if I have a dependent service registered by the name database.foo.mesh.local in my Route 53 private hosted zone, I'd like to define that service using the following App Mesh resources.

First, I create the VirtualNode which uses the fully-qualified domain name (FQDN) for it's service discovery setting.

$ aws appmesh create-virtual-node --mesh-name foo \
    --virtual-node-name database-node \
    --spec '{ "serviceDiscovery": { "dns": { "hostname": "database.foo.mesh.local" }}}'

Then, I create a VirtualService named after the simpler hostname, and use the previously defined VirtualNode as the provider for that VirtualService.

$ aws appmesh create-virtual-service --mesh-name foo \
    --virtual-service-name database \
    --spec '{ "provider": { "virtualNode": { "virtualNodeName": "database-node" }}'

For dependent services who specify this VirtualService as a backend, they should be able to make a request to http://database successfully.

Which integration(s) is this request for?
This could be Fargate, ECS, EKS, EC2, Kubernetes, something else.

All

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

Allowing services to be called by simple hostnames instead of the registered FQDN allows service owners to reduce complexity in naming for their applications, particularly as their application spans multiple stages, AWS accounts, etc. where the private hosted zone namespace may change, but the hostnames are the same.

The reason this does not work today is that the hostname by itself does not automatically resolve to an IP address in DNS. While you can successfully resolve database.foo.mesh.local due to the DNS A records in the Route 53 private hosted zone, database is not resolvable by default.

This same issue would exist for any fully qualified domain name (FQDN) which is not resolvable by DNS, as indicated in #71.

Are you currently working around this issue?

One way to work around this issue to to bundle a fake DNS entry in the /etc/hosts file for the ECS container, EC2 instance, etc. For example, in /etc/hosts you may define an entry for the above example like:

10.10.10.10 database

The IP address added to /etc/hosts does not matter so long as it's not a local loopback address. The entry in /etc/hosts will allow the calling application to resolve to an IP address and attempt to send an HTTP request to that IP address, which will be intercepted by Envoy Proxy where the Host header will be matched and the request forwarded to the endpoints that resolve for the VirtualNode service discovery settings.

If you're using a FQDN, you can setup a Route53 private hosted zone for your VPC with an A record pointing to a standard non-loopback IP address (e.g. 10.10.10.10).

Additional context

Envoy Proxy does not currently handle UDP based traffic, and cannot intercept DNS queries. This issue is currently marked as blocked on:

1. UDP proxying support in Envoy
2. DNS filtering support in Envoy

[rizblie]

@bcelenza Can you please clarify that the intent of this feature request is that the name of the virtual service should not need to be resolvable in DNS? IMHO the title and description do not make this clear. Thanks.

If you can confirm this, then we can reject+close #330 .

[bcelenza]

Hey @rizblie , the original intent for this issue was to use Envoy's DNS responder capabilities to intercept and respond to DNS queries for Virtual Services in App Mesh. You're right that the title and description aren't super clear in that regard. I'm no longer part of this project at AWS, so I'll leave it up to others on the team to potentially rename the issue.

[herrhound]

I updated the name of the issue to match to the original intent, and also assigned it to the roadmap project as we are actively researching it.