when using service-upstream: true use FQDN

[lahabana]

Is there an existing issue for this?

• I have searched the existing issues

Does this enhancement require public documentation?

• I have added an Acceptance Criteria item for adding and/or adjusting public documentation (if applicable)

Problem Statement

Currently using this feature we use {service}.{namespace}.svc.
Underneath this means we can do multiple DNS lookups to get the service.

Would it make sense to use {service}.{namespace}.svc.cluster.local to avoid some of the lookups?

Proposed Solution

• Use FQDN instead of partial domain when using service-upstream

Additional information

No response

Acceptance Criteria

• Check if cluster.local is configurable. If it is, reconsider this improvement
• Once done check the DNS lookup go down when using service-upstream: true

[lahabana]

It seems that cluster base DNS is configurable.
We have the options:

1. do the change and make it configurable (maybe as another annotation?)
2. do not do this
3. look at DP DNSConfig to maybe improve this some other way.

[lahabana]

Let's make it a configuration but have the default set as: .svc.cluster.local so it works for most.

Can we make it a KIC global configuration?

[pmalek]

After making some tests with coredns log plugin enabled I've verified that this indeed would decrease the number of DNS queries made periodically, from :

# 2024-11-20T13:30:16.321988054+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.svc.cluster.local. SRV 23065
# 2024-11-20T13:30:16.322108554+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.kong.svc.cluster.local. A 36177
# 2024-11-20T13:30:16.322140471+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.kong.svc.cluster.local. SRV 42231
# 2024-11-20T13:30:16.322311096+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. SRV 5591
# 2024-11-20T13:30:16.322697388+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.svc.cluster.local. SRV 22470
# 2024-11-20T13:30:16.322973181+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.svc.cluster.local. A 30963
# 2024-11-20T13:30:16.323037681+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.kong.svc.cluster.local. SRV 3028
# 2024-11-20T13:30:16.323112431+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. A 26723
# 2024-11-20T13:30:16.323118973+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. A 44180
# 2024-11-20T13:30:16.323122181+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. SRV 51510
# 2024-11-20T13:30:16.323162431+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.kong.svc.cluster.local. A 24715
# 2024-11-20T13:30:16.323261931+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.svc.cluster.local. A 10374
# 2024-11-20T13:30:16.336072458+01:00 [INFO] udp Request: httpbin-deployment.kong.svc. SRV 5107
# 2024-11-20T13:30:16.336275333+01:00 [INFO] udp Request: httpbin-deployment.kong.svc. SRV 17820

to

# 2024-11-20T13:32:20.447688423+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.cluster.local. A 12120
# 2024-11-20T13:32:20.447771840+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.kong.svc.cluster.local. A 42749
# 2024-11-20T13:32:20.447777590+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.svc.cluster.local. A 24739
# 2024-11-20T13:32:20.447911923+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. A 13713
# 2024-11-20T13:32:20.457980238+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.svc.cluster.local. A 31128
# 2024-11-20T13:32:20.458014780+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local. A 56589
# 2024-11-20T13:32:20.458019196+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.cluster.local. A 25465
# 2024-11-20T13:32:20.458021196+01:00 [INFO] udp Request: httpbin-deployment.kong.svc.cluster.local.kong.svc.cluster.local. A 43958

Albeit there's still some of those that are interesting.

[pmalek]

Regarding DP's DNS config: I've looked at https://docs.konghq.com/gateway/latest/production/networking/dns-considerations/ and https://docs.konghq.com/gateway/3.8.x/migrate-to-new-dns-client/ but I couldn't find anything relevant to this (perhaps there's more that I couldn't find).

---

Regarding making this configurable: I believe a flag/env in KIC would do the trick. We could possibly make this a parameter through:

• IngressClassParameters field
  • That would only be relevant to Ingress related resources
  • We do not have a similar configuration option for Gateway API resources
• Another Service annotation: ingress.kubernetes.io/service-domain which could be set to a domain that should be appended to this Service dns name so service-name.service-ns.svc.<annotation-value>

Having said that I'm not sure this level of granularity would be required for KIC (at least today). I'm happy to hear feedback on this one though.

#6697 adds the flag and uses it (requires fixing tests etc.).

---

On top of adding a flag/env configuration we could extend this to auto-detect. A simple in-cluster lookup

// getClusterDomain returns Kubernetes cluster domain, defaults to "cluster.local".
func getClusterDomain(ctx context.Background) string {
	apiSvc := "kubernetes.default.svc"

	resolver := net.Resolver{
		PreferGo: true,
	}
	cname, err := resolver.LookupCNAME(ctx, apiSvc)
	if err != nil {
		return DefaultClusterDomain
	}

	clusterDomain := strings.TrimPrefix(cname, apiSvc)
	clusterDomain = strings.TrimSuffix(clusterDomain, ".")

	return clusterDomain
}

could make this automatic. This IMHO should be a separate issue.