Support for ExternalName Service

[ajjoshi-tibco]

As a user of NGF
I want to route traffic outside of my cluster with my routes
So that in circumstances where my applications are not hosted in the cluster, I can route to them.

Acceptance

• Any Route object in NGF supports routing to an ExternalName service.
• User can supply their DNS resolver for at least ExternalName services per Gateway.

Questions for investigation

• Dynamic DNS Resolution moved to OSS for NGINX. Can we now ExternalName services with OSS?
  • https://blog.nginx.org/blog/dynamic-dns-resolution-open-sourced-in-nginx

Links

• NIC PR

--- ORIGINAL ISSUE ---

Is your feature request related to a problem? Please describe.
While using ExternalName Service as a backend in HTTPRoute, 502 Bad Gateway is returned by nginx

Describe the solution you'd like
The request should be forwarded to the CNAME specified in the service

Describe alternatives you've considered
Happy to try out any other alternatives to invoke an external service with the Gateway API

[pleshakov]

Gateway API spec states the following:

	// ExternalName services can refer to CNAME DNS records that may live
	// outside of the cluster and as such are difficult to reason about in
	// terms of conformance. They also may not be safe to forward to (see
	// CVE-2021-25740 for more information). Implementations SHOULD NOT
	// support ExternalName Services.

https://github.com/kubernetes-sigs/gateway-api/blob/1c4ae619312754c52e1ff130439caed87132dc54/apis/v1beta1/object_reference_types.go#L107-L111

[brianehlert]

That is sad. And I don't agree with insisting that implementations should not support external name.
That is already a strong use case.
I would rather make a suggestion to update the specification to strike the last sentence. I think the wording too opinionated in this case.
I am happy to lead that change.

[brianehlert]

I reached out and the Gateway API spec does not block this feature request.
The statement specifically pertains to potential risks that are inherent in using ExternalName and that this is "not recommended" rather than forbidden or has negative implications for Conformance with the project.

[kirill-abblix]

We at our company are currently integrating NGINX Gateway Fabric (NGF) to manage traffic routing within Kubernetes cluster. The ability to route traffic to various external services, which we define using ExternalName Services in Kubernetes, is critical for us. However, we've also faced an issue where configuring an HTTPRoute with an ExternalName Service backend is currently unsupported by NGF.

This limitation prevents seamless integration with essential external services such as third-party APIs and cloud-based components. To work around it, we are considering deploying a separate NGINX instance within the cluster to handle routing to these external services. However, this approach introduces unnecessary complexity and redundancy, requiring multiple NGINX deployments for a task that should ideally be managed by NGF itself.

Implementing support for ExternalName Services in NGF would allow us to maintain an efficient and scalable routing strategy, ensuring reliable communication between our internal applications and external dependencies—without the need for additional proxies.

We would like to join in supporting the request to implement this feature, as it is crucial for our project and would also benefit other users with similar requirements. Given that the Gateway API specification does not explicitly prohibit this functionality but rather highlights potential risks, we believe it should be reconsidered for inclusion in NGINX Gateway Fabric.

[mpstefan]

Thanks for the feedback, @kirill-abblix! Dusting this one off from the backlog to get it on the roadmap, but will need to sync with the maintainers to see how far we can pull it forward.

I absolutely agree this is a real use case and I think we can just replicate the same warning in our documentation when the feature is released.

[cybercoder]

Would make it brilliant.