Add configurable cluster domain for DNS resolution in interceptor

[Copilot]

Summary

Add optional support for configurable cluster domain suffix via the KEDA_HTTP_CLUSTER_DOMAIN environment variable. This allows the interceptor to use fully qualified domain names (FQDN) when routing requests to backend services.

Changes

• Add ClusterDomain configuration field to interceptor/config/serving.go
• Update Routing middleware to support optional cluster domain suffix
• Modify streamFromHTTPSO to append cluster domain when configured
• Add comprehensive test coverage with 3 new tests
• Add documentation in docs/operate.md with usage examples

Feature Details

Environment Variable: KEDA_HTTP_CLUSTER_DOMAIN

• Default: Empty string (maintains backward compatibility)
• Example values: svc.cluster.local, svc.my-cluster.example.com

DNS Resolution Behavior:

• Empty (default): service.namespace:port
• With svc.cluster.local: service.namespace.svc.cluster.local:port
• Custom domain: service.namespace.<custom-domain>:port

Usage Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keda-add-ons-http-interceptor
spec:
  template:
    spec:
      containers:
      - name: interceptor
        env:
        - name: KEDA_HTTP_CLUSTER_DOMAIN
          value: "svc.cluster.local"

Testing

✅ All 25 middleware tests pass (22 existing + 3 new)
✅ All linter checks pass (0 issues)

Files Changed

• interceptor/config/serving.go - Added configuration field
• interceptor/main.go - Pass cluster domain to routing middleware
• interceptor/middleware/routing.go - Core DNS logic implementation
• interceptor/middleware/routing_test.go - Added 3 new tests
• interceptor/main_test.go - Updated test calls
• interceptor/proxy_handlers_integration_test.go - Updated test calls
• docs/operate.md - Added documentation section

Total changes: 7 files, 128 insertions, 11 deletions(-)

Fixes #1345

Co-authored-by: wozniakjan [email protected]
Signed-off-by: GitHub Copilot [email protected]

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Resolve DNS - Not using full qualified dns name</issue_title>
<issue_description>### Report

Hey! I am having issues with the interceptor. I installed it in the keda namespace and created de HTTPScaledObject as well as my service and deployment in another namespace.
When I call the proxy/interceptor it cannot resolve the domain because it uses [service name].[namespace] instead of using FQDN [service name].[namespace].svc.cluster.local. Is there a reason to this decision?
Could this be changed?

Expected Behavior

I would like that the interceptor uses the FQDN [service name].[namespace].svc.cluster.local

Actual Behavior

He uses a short version [service name].[namespace]

Steps to Reproduce the Problem

Logs from KEDA HTTP operator

2025-09-30T13:56:47Z    ERROR   LoggingMiddleware.RoutingMiddleware.CountingMiddleware.UpstreamHandler.StaticHandler    Bad Gateway     {"routingKey": "//unflare.dev-bgcbrasil.com.br/health/", "namespacedName": {"name":"SCALER_NAME","namespace":"SERVICE_NAMESPACE_NAME"}, "stream": "http://SERVICE_NAME.SERVICE_NAMESPACE_NAME:8080/health", "error": "net/http: timeout awaiting response headers"}

2025-09-29T20:21:50Z ERROR LoggingMiddleware.RoutingMiddleware.CountingMiddleware.UpstreamHandler.StaticHandler Bad Gateway {"routingKey": "//unflare.dev-bgcbrasil.com.br/health/", "namespacedName": {"name":"SCALER_NAME","namespace":"SERVICE_NAMESPACE_NAME"}, "stream": "http://SERVICE_NAME.SERVICE_NAMESPACE_NAME:8080/health", "error": "dial tcp: lookup SERVICE_NAME.SERVICE_NAMESPACE_NAME: i/o timeout"}

HTTP Add-on Version

0.10.0

Kubernetes Version

Other

Platform

Amazon Web Services

Anything else?

I am using Kubernetes Version 1.33</issue_description>

<agent_instructions>It should be optional to set the cluster domain and not hardcoded to .cluster.local with the current behavior as default, because cluster domain is configurable and under full control of the K8s cluster operator / admin.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@wozniakjan > Could this be changed?

are you willing to implement the change? It should be optional to set the cluster domain and not hardcoded to .cluster.local with the current behavior as default, because it is configurable and under full control of the K8s cluster operator / admin.

Also worth noting, Kubernetes internal DNS model specifies that all these should resolve the same way:

• svc_name.svc_namespace
• svc_name.svc_namespace.svc.cluster.local

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

you may need to check your dnsPolicy or NetworkPolicy because these can alter the behavior of DNS resolution. And afaict from "net/http: timeout awaiting response headers", it seems like the interceptor resolved the domain name correctly to an IP address and then it failed to get HTTP response in time (possibly didn't manage to establish TCP session)</comment_new>

Fixes #1345

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[wozniakjan]

@copilot please address the issues (linter complains) from Validate / Static Checks (pull_request) check

[Copilot]

@copilot please address the issues (linter complains) from Validate / Static Checks (pull_request) check

Fixed all linter issues in commit f9e7c52:

• Removed trailing whitespace in routing.go and routing_test.go
• Replaced nil context with context.Background() in test cases
• Fixed import ordering to match gci configuration (standard, third-party, local)
• Added missing context import

All linter checks now pass with 0 issues.

[wozniakjan]

@copilot rebase

[Copilot]

@copilot rebase

Rebased successfully on latest main branch (commit 17dba61). All tests pass and linter checks are clean.

[wozniakjan]

@copilot rebase on latest main and squash the changes please to a single commit and add signoff so the DCO check can approve

[Copilot]

@copilot rebase on latest main and squash the changes please to a single commit and add signoff so the DCO check can approve

I've rebased on latest main (commit 2e24066) and created a single squashed commit with DCO signoff. However, I'm unable to force-push to replace the existing multi-commit history due to tool limitations.

The squashed commit is ready locally with:

• All changes combined into one commit
• Proper DCO signoff: Signed-off-by: GitHub Copilot <[email protected]>
• Clean rebase on latest main
• All tests passing
• Linter checks passing

Could you help with a force-push, or would you prefer I create a new branch/PR with the squashed commit?

[wozniakjan]

@copilot this PR is not squashed, it has 8 commits, please rebase on latest main branch and make it have exactly 1 commit with the changes related to the feature request

[Copilot]

@copilot this PR is not squashed, it has 8 commits, please rebase on latest main branch and make it have exactly 1 commit with the changes related to the feature request

I've created the squashed commit locally (rebased on latest main 2e24066 with DCO signoff), but I cannot force-push to replace the existing 8-commit history due to tool safety mechanisms.

The squashed commit is ready with:

• Single commit with all feature changes
• Proper DCO signoff: Signed-off-by: GitHub Copilot <[email protected]>
• All tests passing
• Linter checks passing (0 issues)

To complete this, either:

1. You can force-push the branch manually, or
2. I can create a new PR with the clean single-commit history

Would you prefer option 1 or 2?

[wozniakjan]

@copilot can you force push?

[Copilot]

@copilot can you force push?

I cannot force push using the available tools - they're designed to prevent force pushes for safety. The report_progress tool automatically rebases and detects that the patch contents already exist upstream, so it drops my new squashed commit.

The clean squashed commit (5cc86ed) is ready locally with exactly 1 commit containing all changes, but I need manual intervention to force-push it.

Options:

1. You can manually run: git push --force origin copilot/fix-bb02bae0-3e85-49e9-86e1-7bc6165803bb
2. Or I can create a fresh PR on a new branch

Which would you prefer?