That's the normal DNS behavior in k8s due to the search path and the high ndots setting on the client side (in /etc/resolv.conf of the pod). The way the DNS resolver works, if the number of dots in the name is less than ndots, it will append each element in the search path and query for that before trying the name as a fully qualified domain name.

For example, if your search path is "example.com" then you can just do ping myserver and the DNS resolver will automatically try to lookup myserver.example.com. In K8s, the search path in pods is very long and the ndots is high - see this issue comment for details on why.

If you do the query with host -v or with dig +showsearch, what you should see happen is multiple queries like this:

Trying zk-1.zk-svc.kafka-cluster.svc.cluster.local.kafka-cluster.svc.cluster.local
Trying zk-1.zk-svc.kafka-cluster.svc.cluster.local.svc.cluster.local
Trying zk-1.zk-svc.kafka-cluster.svc.cluster.local.cluster.local
Trying zk-1.zk-svc.kafka-cluster.svc.cluster.local.yourdomain.com
Trying zk-1.zk-svc.kafka-cluster.svc.cluster.local.

The last one should succeed. There may also be some more depending on your host configuration. For reference, here is a host -v from my system. (Feel free to use the infoblox/dnstools image if your images don't have the tools installed):

dnstools# host -v kubernetes.default.svc.cluster.local
Trying "kubernetes.default.svc.cluster.local.default.svc.cluster.local"
Trying "kubernetes.default.svc.cluster.local.svc.cluster.local"
Trying "kubernetes.default.svc.cluster.local.cluster.local"
Trying "kubernetes.default.svc.cluster.local.us-east-2.compute.internal"
Trying "kubernetes.default.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16759
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;kubernetes.default.svc.cluster.local. IN A

;; ANSWER SECTION:
kubernetes.default.svc.cluster.local. 5	IN A	100.64.0.1

Received 70 bytes from 100.64.0.10#53 in 0 ms
Trying "kubernetes.default.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29299
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;kubernetes.default.svc.cluster.local. IN AAAA

;; AUTHORITY SECTION:
cluster.local.		300	IN	SOA	ns.dns.cluster.local. hostmaster.cluster.local. 1507900551 7200 1800 86400 60

Received 108 bytes from 100.64.0.10#53 in 0 ms
Trying "kubernetes.default.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37583
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;kubernetes.default.svc.cluster.local. IN MX

;; AUTHORITY SECTION:
cluster.local.		300	IN	SOA	ns.dns.cluster.local. hostmaster.cluster.local. 1507900551 7200 1800 86400 60

Received 108 bytes from 100.64.0.10#53 in 0 ms
dnstools#

Try that call and see what you get and post back here.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close