feat(gateway): add --resolve-gateway-load-balancer-hostname flag

[Apoorva64]

What does this PR do?

Adds a new --resolve-gateway-load-balancer-hostname boolean flag (default: false) to all Gateway API route sources (HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute).

When enabled, any status.addresses entry on a Gateway with type: Hostname is resolved via DNS (net.LookupIP) and the resulting IP addresses are used as endpoint targets instead of the hostname. This produces A/AAAA records rather than CNAME records.

If DNS resolution fails for a hostname, zero targets are added for that address (same behavior as --resolve-service-load-balancer-hostname).

Motivation

Feature parity with --resolve-service-load-balancer-hostname, which provides the same behavior for Service resources of type LoadBalancer. Some DNS providers or configurations do not support CNAME records (e.g., internal Dns), requiring IP-based records.

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

Welcome @Apoorva64!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @Apoorva64. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

My main concern is that we're slowly accumulating per-source flags. We already have --resolve-service-load-balancer-hostname, and adding --resolve-gateway-load-balancer-hostname starts a pattern that's hard to stop -> next comes --resolve-ingress-, --resolve-istio-, and so on. Once those flags are out in the wild we're stuck with them.

I think we can do better here. Two other options we could/should consider:

• Generalize --resolve-service-load-balancer-hostname into a single flag that just works for all sources - cleaner for users too.
• And|Or go the annotation route (external-dns.alpha.kubernetes.io/resolve-target: "true") for per-resource opt-in, which is more flexible and avoids the all-or-nothing problem of global flags.

Either way, the underlying feature make sense to land in external-dns.

[Apoorva64]

I think that option A would be better as when we are using external DNS, the --resolve-service-load-balancer-hostname type flags are used for handling a specific DNS provider.

From what i see this feature is thus tied to a single deployment and should be enabled with a global flag.

[ivankatliarchuk]

I've deleted my initial review comment. It was too big so I simplified, but without options A-B now.

Option A — Generalize the existing --resolve-service-load-balancer-hostname into a single --resolve-load-balancer-hostname flag that applies uniformly across all sources producing hostname-type targets.

Option B — Introduce a per-resource annotation (e.g. external-dns.alpha.kubernetes.io/resolve-target: "true") as a source-agnostic opt-in, and open a design discussion first.

[ivankatliarchuk]

This will create endpoint without addresses? It will fail the DNS apply

[Apoorva64]

I fixed the docs. In the case of DNS failure for an Endpoint, External Dns will log the error and skip the endpoint

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from ivankatliarchuk. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Apoorva64]

@ivankatliarchuk

• i extracted the resolving to a util
• i renamed the flag to --resolve-load-balancer-hostname.
• The flag now also activates the hostname resolving in the service.
• --resolve-service-load-balancer-hostname is now an alias of --resolve-load-balancer-hostname

We should probably add this for other sources but i think it would be another PR?

[ivankatliarchuk]

Maybe annotation is worth to implement first, as it's provides a better opt-in functionality? Worth to check contribution docs https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/source-wrappers.md for some design ideas.

This may take a while, as pros/cons not yet clear of each approach.

[Apoorva64]

Maybe annotation is worth to implement first, as it's provides a better opt-in functionality? Worth to check contribution docs https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/source-wrappers.md for some design ideas.

This may take a while, as pros/cons not yet clear of each approach.

i've drafted another approch using the wrappers you mentioned here #6289 it still uses a global var to activate and desactivate the feature.
I am still figuring out how annotations works in the codebase xD

[ivankatliarchuk]

Try to configure locall cluster, this should simplify things

• minikube https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/dev-guide.md
• kind - coredns https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/coredns-etcd.md

On top of that - wort to ask Chatgpt, Claude and DeepWiki https://deepwiki.com/kubernetes-sigs/external-dns

[k8s-ci-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

Maybe annotation is worth to implement first, as it's provides a better opt-in functionality? Worth to check contribution docs https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/source-wrappers.md for some design ideas.
This may take a while, as pros/cons not yet clear of each approach.

i've drafted another approch using the wrappers you mentioned here #6289 it still uses a global var to activate and desactivate the feature. I am still figuring out how annotations works in the codebase xD

/close

[k8s-ci-robot]

@ivankatliarchuk: Closed this PR.

Details

In response to this:

Maybe annotation is worth to implement first, as it's provides a better opt-in functionality? Worth to check contribution docs https://github.com/kubernetes-sigs/external-dns/blob/master/docs/contributing/source-wrappers.md for some design ideas.
This may take a while, as pros/cons not yet clear of each approach.

i've drafted another approch using the wrappers you mentioned here #6289 it still uses a global var to activate and desactivate the feature. I am still figuring out how annotations works in the codebase xD

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

#6329