plugin/kubernetes: Wildcard SRV records for endpoints peculiarity

[chrisohaver]

When myservice is a non-headless service, the following SRV query to all it's endpoints works:

dig -t SRV *.myservice.default.svc.cluster.local.

It returns a list of SRV records for all endpoints in the service. e.g.

;; ANSWER SECTION:
*.myservice.default.cluster.local.     5 IN SRV	0 50 443 172-17-0-253.myservice.default.cluster.local.
*.myservice.default.svc.cluster.local. 5 IN SRV	0 50 80  172-17-0-253.myservice.default.cluster.local.

;; ADDITIONAL SECTION:
172-17-0-253.myservice.default.cluster.local 5 IN A 172.17.0.253

But all the following return NXDOMAIN:

dig -t SRV *.*.*.myservice.default.svc.cluster.local.
(which you'd expect the same result as above)

dig -t SRV _http._tcp.*.myservice.default.svc.cluster.local.
(specifying the port and protocol fields)

dig -t SRV _http._tcp.172-17-0-253.myservice.default.svc.cluster.local.
(with no wildcards used)

Wild card queries are not part of the k8s dns spec, and neither are SRV queries for endpoints (only headless and non-headless services are defined). So hard to say if this is a bug or not. But the current behavior is certainly inconsistent with itself.

[chrisohaver]

IMO, we should allow the 3 NXDOMAIN examples above to work.
The first returning the two results for http and https, the other two returning just a single record for http.

[miekg]

[ Quoting <notifications@github.com> in "[coredns/coredns] plugin/kubernetes..." ]

When `myservice` is a non-headless service, the following SRV query to all it's endpoints works: `dig -t SRV *.myservice.default.svc.cluster.local.` It returns a list of SRV records for all endpoints in the service. e.g. ``` ;; ANSWER SECTION: *.myservice.default.cluster.local. 5 IN SRV 0 50 443 172-17-0-253.myservice.default.cluster.local. *.myservice.default.svc.cluster.local. 5 IN SRV 0 50 80 172-17-0-253.myservice.default.cluster.local. ;; ADDITIONAL SECTION: 172-17-0-253.myservice.default.cluster.local 5 IN A 172.17.0.253 ``` But all the following return `NXDOMAIN`: `dig -t SRV *.*.*.myservice.default.svc.cluster.local.` (which you'd expect the same result as above)

Why? this has more labels than k8s supports.

`dig -t SRV _http._tcp.*.myservice.default.svc.cluster.local.` (specifying the port and protocol fields) `dig -t SRV _http._tcp.172-17-0-253.myservice.default.svc.cluster.local.` (with no wildcards used) Wild card queries are not part of the k8s dns spec, and neither are SRV queries for endpoints (only headless and non-headless services are defined). So hard to say if this is a bug or not. But the behavior is certainly inconsistent.

What is the inconsistency?

[chrisohaver]

Why? this has more labels than k8s supports.

K8s actually does support this many labels. It's an SRV record, so the first two are service and protocol (e.g. "_http" and "_tcp"). And its an SRV record for an endpoint, so the next label is an endpoint name, then the service, namespace, type, and cluster domain.

What is the inconsistency?

The inconsistency is that we allow SRV requests of endpoint in one form, but not others.

[junoteam]

hello,

regarding to SRV query record like that:
dig -t SRV _http._tcp.nginx.default.svc.cluster.local.

coredns doesn't create this kind of SRV record [in some reason], but Haproxy and nginx build SRV query exactly like this. Example: https://www.haproxy.com/blog/dns-service-discovery-haproxy

In docs of coredns I see that it should create this type of SRV, but it simply doesn't.
Proof: https://coredns.io/plugins/kubernetes

Instead of this coredns create SRV records like this:
_80-80._tcp.nginx.default.svc.cluster.local

So I'm unable to use Haproxy or Nginx for dns load balancing.
Do you know how to fix it?

[johnbelamaric]

You need to name the port in your service spec:

  ports:
  - port: 80
    name: http