Support DNS resolution settings

[guydc]

Description:
Currently, Envoy Gateway overrides the envoy default values for certain DNS resolution:

gateway/internal/xds/translator/cluster.go

Lines 145 to 146 in 8abf1ef

	cluster.DnsRefreshRate = durationpb.New(30 * time.Second)
	cluster.RespectDnsTtl = true

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.