As described in our previous post, CoreDNS can be used in place of Kube-DNS for service discovery in Kubernetes clusters. Because of the flexible architecture of CoreDNS, this can enable some interesting use cases. In this blog, we’ll show how to solve a common problem - creating custom DNS entries for your services.

There are a couple of different possiblities here:

• Making an alias for an external name
• Dynamically adding services to another domain, without running another server
• Adding an arbitrary entry inside the cluster domain

CoreDNS can solve all of these use cases. Let’s start with the first one, which is pretty common. In this situation, you want to be able to use the same name for a given service, whether you are accessing it inside or outside the cluster. This is helpful, for example, when using TLS certificates that are bound to that name.

Suppose we have a service, foo.default.svc.cluster.local that is available to outside clients as foo.example.com. That is, when looked up outside the cluster, foo.example.com will resolve to the load balancer VIP - the external IP address for the service. Inside the cluster, it will resolve to the same thing, and so using this name internally will cause traffic to hairpin - travel out of the cluster and then back in via the external IP. Instead, we want it to resolve to the internal ClusterIP, avoiding the hairpin.

To do this in CoreDNS, we make use of the rewrite plugin. This plugin can modify a query before it is sent down the chain to whatever backend is going to answer it. Recall the Corefile (CoreDNS configuration file) we used in the last blog:

.:53 {
    errors
    log
    health
    kubernetes cluster.local 10.0.0.0/24
    forward . /etc/resolv.conf
    cache 30
}

To get the behavior we want, we just need to add a rewrite rule mapping foo.example.com to foo.default.svc.cluster.local:

.:53 {
    errors
    log
    health
    rewrite name foo.example.com foo.default.svc.cluster.local
    kubernetes cluster.local 10.0.0.0/24
    forward . /etc/resolv.conf
    cache 30
}

Once we add that to the ConfigMap via kubectl edit or kubectl apply, we have to let CoreDNS know that the Corefile has changed. You can send it a SIGUSR1 to tell it to reload graceful - that is, without loss of service:

$ kubectl exec -n kube-system coredns-980047985-g2748 -- kill -SIGUSR1 1

Running our test pod, we can see this works:

$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools
If you don't see a command prompt, try pressing enter.
/ # host foo
foo.default.svc.cluster.local has address 10.0.0.72
/ # host foo.example.com
foo.example.com has address 10.0.0.72
/ # host bar.example.com
Host bar.example.com not found: 3(NXDOMAIN)
/ #

That’s all there is to solving the first problem.

The second problem is just as easy. Here, we just want to be able to serve DNS entries out of a different zone than the cluster domain. Since CoreDNS is a general-purpose DNS server, there are many other ways to serve up zones than just the kubernetes plugin. For simplicity, we’ll use the file plugin along with another ConfigMap entry to satisfy this use case. However, you could use the etcd plugin to store services directly within an etcd instance, or the auto plugin to manage a set of zones (very nice when used along with git-sync).

To create the new zone, we need to modify the coredns.yaml we have been using to create an additional file in the pod. To do this we have to edit the ConfigMap by adding a file line to the Corefile, and also by adding another key, example.db, for the zone file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        log
        health
        rewrite name foo.example.com foo.default.svc.cluster.local
        kubernetes cluster.local 10.0.0.0/24
        file /etc/coredns/example.db example.org
        forward . /etc/resolv.conf
        cache 30
    }    
  example.db: |
    ; example.org test file
    example.org.            IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2015082541 7200 3600 1209600 3600
    example.org.            IN      NS      b.iana-servers.net.
    example.org.            IN      NS      a.iana-servers.net.
    example.org.            IN      A       127.0.0.1
    a.b.c.w.example.org.    IN      TXT     "Not a wildcard"
    cname.example.org.      IN      CNAME   www.example.net.

    service.example.org.    IN      SRV     8080 10 10 example.org.    

and we also need to edit the volumes section of the Pod template spec:

      volumes:
        - name: config-volume
          configMap:
            name: coredns
            items:
            - key: Corefile
              path: Corefile
            - key: example.db
              path: example.db

Once we apply this using kubectl apply -f, a new CoreDNS pod will be built, because of the new file in the volume. Later changes to the file won’t require a new pod, just a graceful restart like we did before. Let’s take a look:

$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools
If you don't see a command prompt, try pressing enter.
/ # host foo
foo.default.svc.cluster.local has address 10.0.0.72
/ # host foo.example.com
foo.example.com has address 10.0.0.72
/ # host example.org
example.org has address 127.0.0.1
/ #

Perfect! We can now edit that ConfigMap and send SIGUSR1 any time we want to add entries to example.org. Of course, as mentioned earlier, we could also use the etcd backend and avoid the hassle of modifying the ConfigMap and sending the signal.

This brings us to the last problem. That one can be solved using the new support for fallthrough in the kubernetes plugin. This functionality has been added in the recently released version 007 of CoreDNS - we’ll come back with another blog soon show how to use it.