Should work. If you use the fully qualified name with CoreDNS (as you did with kube-dns), do you get an answer?

What does the definition of the external name service look like?

kubectl -n letmetry get service mysql -o yaml

• kube dns works without FQDN

/ # nslookup mysql.letmetry
Server:    100.64.0.10
Address 1: 100.64.0.10 kube-dns.kube-system.svc.cluster.local

Name:      mysql.letmetry
Address 1: 172.31.21.116 ip-172-31-21-116.ap-south-1.compute.internal

• Output of kubectl -n letmetry get service mysql -o yaml

$ kubectl -n letmetry get service mysql -o yaml
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2018-11-19T16:42:39Z
  name: mysql
  namespace: letmetry
  resourceVersion: "105997025"
  selfLink: /api/v1/namespaces/letmetry/services/mysql
  uid: 205f30f2-ec1a-11e8-8bba-02ebb8238b60
spec:
  externalName: 172.31.21.116
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
  sessionAffinity: None
  type: ExternalName
status:
  loadBalancer: {}

• Core dns does not work with FQDN also

OK, the issue is, I believe, that the external name field is supposed to hold a DNS name, not an IP. For example, per the Cluster DNS spec, this field is expected to be a DNS name because it must be used to construct a CNAME record (which can only contain a DNS name target).

If you want to point a cluster service to an external IP, you can do so with a headless service and static endpoint.

Another explanation here, with an example of a headless service and static endpoint.

thanks @chrisohaver let me try that and get back !
Also, if it works for kube-dns then it should work for core-dns as well to maintain the backward compatibility.

Also, if it works for kube-dns then it should work for core-dns as well to maintain the backward compatibility.

Perhaps. Although strictly speaking, kube-dns is violating the Cluster DNS Spec in behaving that way.

IMO, it's not intended that the ExternalName field should be able to contain an IP address. All documentation I can find assumes it will be a name, not an IP. The API should probably not allow IPs in that field.

Diving into the k8s API validation code, it looks like the Service validation is letting IPv4s slip through because it thinks they are domain names (after all, an IPV4 address is a series of valid dns labels delimited by dots). For example, looking at the code, an IPv6 address would fail validation because they contain colons. In other words, the API appears to be accepting an IPv4 address as a domain name, not as an IP. This is the regex the API uses ... [a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)* (used in IsDNS1123Subdomain() which is used when validating the externalName field for ExternalName services).

We should release note this in K8s (@rajansandeep ?) as a change in behavior, but CoreDNS is working according to the spec. It's actually a bug in kube-dns - an accident of the skydns code and the missing validations.

Got into this "issue" from the ingress-nginx controller perspective - version 0.18.0 or later outputs the following line:

2018/11/19 15:53:42 [error] 110379#110379: *24398057 [lua] dns.lua:61: resolve(): server returned error code: 3: name error, context: ngx.timer

This happens when any externalName is an IP, and it tries to query the nameserver with the IP as an A record.

Both CoreDNS and ingress-nginx are working according to spec, and this detail should be in the official Kubernetes docs for clarity.

Got into this "issue" from the ingress-nginx controller perspective - version 0.18.0 or later outputs the following line:

2018/11/19 15:53:42 [error] 110379#110379: *24398057 [lua] dns.lua:61: resolve(): server returned error code: 3: name error, context: ngx.timer

This happens when any externalName is an IP, and it tries to query the nameserver with the IP as an A record.

Both CoreDNS and ingress-nginx are working according to spec, and this detail should be in the official Kubernetes docs for clarity.

@nikopen - We are facing the same issue. We created the k8s cluster with Kubeadm and deployed nginx-ingress through helm chart. Can you please let me know how you fixed this issue?

@nvenky this happens when you have some Services with externalName as an IP instead of a hostname, as mentioned above.

Turn the IPs into hostnames to fix this.

I too am using externalname services with internal IP addresses.

The fact that coredns is not able as kubernetes to resolve them is causing me problems.

I too am using externalname services with internal IP addresses.

In Kubernetes, IP addresses are not supposed to be allowed in the in ExternalName services. Kubernetes only permits FQDNs, as such an IP would be interpreted as a FQDN not an IP, resulting in unexpected behavior. IMO Kubernetes field validation could be improved here, by screening out numeric TLDs.

I understand but this is something kube-dns users who were not aware of the spec and who build something on top of externalname resolving an IP will appreciate.

@sylr This is the Kubernetes spec and CoreDNS follows it as intended. Docs have been equally updated to make this detail visible.

If you want to push for this change, a good place for that would be SIG-Network in Kubernetes. If accepted and implemented there, only then I assume CoreDNS would propagate the change.

This is the Kubernetes spec and CoreDNS follows it as intended.

Not respecting the spec and going beyond it are not the same thing. You'll only make the transition smoother for kube-dns users like myself who unwillingly got into this situation.