gloo-proxy source does not support aggregateListener, silently produces zero endpoints

[davyp1987]

What happened:

The gloo-proxy source (source/gloo_proxy.go) only reads domains from Proxy.spec.listeners[].httpListener.virtualHosts[].domains. When a Gloo Edge Gateway is configured with isolateVirtualHostsBySslConfig: true (observed since Gloo Edge 1.22.0), Gloo translates the Proxy CR to use aggregateListener instead of httpListener for that listener. Since the proxySpecListener struct has no AggregateListener field, Go's JSON unmarshalling silently drops that part of the object, listener.HTTPListener.VirtualHosts ends up empty, and generateEndpointsFromProxy produces zero endpoints for that listener — with no error or warning logged.

DNS records silently stop being created/updated for any VirtualService domain served by an aggregateListener-backed listener, even though the Proxy CR is valid and Envoy is serving the domain correctly.

What you expected to happen:

gloo-proxy source should also parse aggregateListener.httpResources.virtualHosts (a map[string]VirtualHost, referenced via httpFilterChains[].virtualHostRefs), in addition to the classic httpListener.virtualHosts[], so domains aren't silently dropped when a Gateway uses isolateVirtualHostsBySslConfig: true.

How to reproduce it (as minimally and precisely as possible):

1. Deploy Gloo Edge (1.22.0+) with a Gateway that has isolateVirtualHostsBySslConfig: true (this causes Gloo to use aggregateListener for SNI-based filter chain splitting).
2. Confirm the generated Proxy CR uses spec.listeners[].aggregateListener.httpResources.virtualHosts instead of spec.listeners[].httpListener.virtualHosts.
3. Run external-dns with --source=gloo-proxy.
4. Observe that no DNS records are created for domains on that listener, with no error/warning in the debug logs.

Trimmed/anonymized Proxy CR for the same VirtualService/domain, before and after enabling isolateVirtualHostsBySslConfig on the Gateway. Only the listener-shape fields relevant to this bug are kept.

Before (isolateVirtualHostsBySslConfig: false) — parsed correctly today:

apiVersion: gloo.solo.io/v1
kind: Proxy
metadata:
  name: example-gateway-proxy
  namespace: gloo-system
spec:
  listeners:
  - bindAddress: '::'
    bindPort: 8443
    httpListener:
      virtualHosts:
      - domains:
        - app.example.com
        metadataStatic:
          sources:
          - resourceKind: '*v1.VirtualService'
            resourceRef:
              name: example-vs
              namespace: example-ns
        name: example-ns.example-vs

After (isolateVirtualHostsBySslConfig: true) — silently produces zero endpoints:

apiVersion: gloo.solo.io/v1
kind: Proxy
metadata:
  name: example-gateway-proxy
  namespace: gloo-system
spec:
  listeners:
  - bindAddress: '::'
    bindPort: 8443
    aggregateListener:
      httpFilterChains:
      - httpOptionsRef: "1234567890"
        virtualHostRefs:
        - example-ns.example-vs
      httpResources:
        virtualHosts:
          example-ns.example-vs:
            domains:
            - app.example.com
            metadataStatic:
              sources:
              - resourceKind: '*v1.VirtualService'
                resourceRef:
                  name: example-vs
                  namespace: example-ns
            name: example-ns.example-vs

Same domain, same source VirtualService — but the domain now lives under spec.listeners[].aggregateListener.httpResources.virtualHosts (a map keyed by virtual host name, referenced indirectly via httpFilterChains[].virtualHostRefs) instead of spec.listeners[].httpListener.virtualHosts[].

Full status block from the live Proxy object (identical shape in both the httpListener and aggregateListener cases):

status:
  statuses:
    gloo-system:
      reportedBy: gloo
      state: 1

state: 1 indicates the Proxy was accepted/processed successfully by Gloo — i.e. this isn't a case of Gloo itself rejecting or failing to translate the config; the Proxy CR is valid and healthy, only external-dns's parser fails to read the aggregateListener shape.

Anything else we need to know?:

Confirmed via direct source inspection of source/gloo_proxy.go on both the v0.15.1 release tag and current master — proxySpecListener struct only defines HTTPListener, no AggregateListener field, and the endpoint-generation loop in generateEndpointsFromProxy only walks listener.HTTPListener.VirtualHosts. So this is not version-specific — the gap exists on master as well as the release we're running.

Debug logs confirm the proxy is found and a target is resolved, but zero endpoints are generated — with no error or warning anywhere in between:

time="2026-08-13T09:25:33Z" level=debug msg="Gloo: Find external-gateway-proxy proxy"
time="2026-08-13T09:25:33Z" level=debug msg="Gloo[external-gateway-proxy]: Find 1 target(s) (ext-gateway-proxy-xxxxxxxxxxxxxxxx.elb.eu-west-1.amazonaws.com)"
time="2026-08-13T09:25:33Z" level=debug msg="Gloo[external-gateway-proxy]: Generate 0 endpoint(s)"
time="2026-08-13T09:25:33Z" level=debug msg="Gloo: Find internal-gateway-proxy proxy"
time="2026-08-13T09:25:33Z" level=debug msg="Gloo[internal-gateway-proxy]: Find 1 target(s) (int-gateway-proxy-xxxxxxxxxxxxxxxx.elb.eu-west-1.amazonaws.com)"
time="2026-08-13T09:25:33Z" level=debug msg="Gloo[internal-gateway-proxy]: Generate 0 endpoint(s)"

This matches the code path exactly: the Proxy object and its LoadBalancer target are both found successfully, but since the listener is aggregateListener-shaped, listener.HTTPListener.VirtualHosts is empty and the domain loop never executes — hence "Generate 0 endpoint(s)" with no error.

Environment:

• External-DNS version (use external-dns --version): v0.15.1 — not the latest release; gap confirmed present via source inspection on master as well (see below), but not reproduced against a live newer/staging build
• DNS provider: aws
• Others: Gloo Edge 1.22.0, --source=gloo-proxy

Checklist

• I have searched existing issues and tried to find a fix myself
• I am using the latest release, or have checked the [staging image](https://kubernetes-sigs.github.io/external-dns/latest/release/#staging-release-cycle) to confirm the bug is still reproducible — running v0.15.1; verified the same code gap exists on master by reading source/gloo_proxy.go directly, but have not run a newer/staging build against the cluster to confirm live
• I have provided the actual process flags (not Helm values)
• I have provided kubectl get <resource> -o yaml output including status
• I have provided full external-dns debug logs
• I have described what DNS records exist and what I expected