Support DNS resolution settings

[guydc]

Description: Currently, Envoy Gateway overrides the envoy default values for certain DNS resolution: https://github.com/envoyproxy/gateway/blob/8abf1efef4176092fe4db5ad9239e6d433ca57f2/internal/xds/translator/cluster.go#L145-L146

These settings are typically configurable in similar projects (see links below):

• Istio: dns_refresh_rate
• Ambassador: respect_dns_ttl
• Gloo Edge: dns_refresh_rate, respect_dns_ttl

Envoy Gateway can support these settings in BackendTrafficPolicy.

Relevant Links:

• Ambassador: https://www.getambassador.io/docs/edge-stack/latest/topics/using/mappings#dns-configuration-for-mappings
• Gloo Edge: https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/upstream.proto.sk/
• Istio: https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/

[arkodg]

should these live in Backend instead ?

[guydc]

Minutes from today's community meeting:

• Where: tweaking these settings makes sense mostly for FQDN endpoints. So, implementing this in the Backend API makes sense.
• What: dns_refresh_rate, respect_dns_ttl are the knobs that make most sense to expose. Other options like dns type (LOGICAL, STRICT) should be auto-computed by EG.
• Defaults: current defaults don't have a significant impact, since EG mostly resolves IPs from slices and does not rely on DNS often. When relying on DNS, lookup is less frequent, to reduce load on DNS servers.

[alexwo]

Hi @guydc / @arkodg ,

Since dns_refresh_rate and respect_dns_ttl are propertie apply to all resolutions within a cluster, and a cluster can have multiple backend destinations, does it still make sense for backends within the same cluster to have different dns settings?

Perhaps using BackendTrafficPolicy would be a better choice, as the settings there can apply directly on the cluster level on a 1:1 basis. So thats more clear, even if multiple backends are configured for this cluster, what apply.

WDYT?

[guydc]

Hi @alexwo !

Yes, that's a very good point. I tend to agree that it makes more sense to use BTP here. Only envoy endpoint-level config makes sense in the backend API.

[guydc]

This was discussed in the last community meeting. Since we do support "service routing" for services (which relies on envoy to perform DNS resolution against kube-dns), there is value in supporting these settings in BTP, so that they can also apply to Service and not only Backend resources.