March 8, 2019 By Richard Theis 2 min read

CoreDNS is replacing KubeDNS as the default cluster DNS provider

Kubernetes recently announced that CoreDNS has become the default cluster DNS provider starting in version 1.13. To align with this announcement, CoreDNS is also the default cluster DNS provider for new IBM Cloud Kubernetes Service version 1.13 clusters. As detailed in the Kubernetes announcement, there are several reasons for this change.

CoreDNS is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. CoreDNS has fewer moving parts than the previous DNS server, since it’s a single executable and a single process, and supports flexible use cases by creating custom DNS entries. It’s also written in Go making it memory-safe.

Since the Kubernetes announcement, CoreDNS has become a graduated Cloud Native Computing Foundation (CNCF) project!

Prepare DNS transition in versions 1.12 and 1.13

IBM Cloud Kubernetes Service clusters running version 1.12 and earlier continue to use KubeDNS as the default cluster DNS provider. Also, when you update a cluster from an earlier version to 1.13, the cluster DNS provider is not automatically changed to CoreDNS. New clusters in version 1.13 and later have CoreDNS by default. Furthermore, in versions 1.12 and 1.13, your cluster administrator can toggle the cluster DNS provider to either CoreDNS or KubeDNS. This gives clusters administrators the opportunity to test CoreDNS.

Most cluster administrators and apps won’t notice any difference when transitioning to CoreDNS since it is a backward-compatible integration with Kubernetes. However, there are a couple exceptions:

  1. Customizing CoreDNS is different than customizing KubeDNS.

  2. CoreDNS does not allow IP addresses for external names per Kubernetes cluster DNS specification.

For Exception 1, you must transfer your KubeDNS customizations in the kube-dns or kube-dns-autoscalerconfigmaps in the kube-system namespace to the coredns and coredns-autoscaler configmaps. The customization syntax for the kube-dns-autoscaler and coredns-autoscaler configmaps is the same so a simple copy will suffice. However, the customization syntax for the kube-dns and coredns configmaps is different. For an example, see the Kubernetes documentation.

Unfortunately, for Exception 2, apps that rely on IP addresses for an external name must change to adhere to the Kubernetes cluster DNS specification.

DNS transition completed in version 1.14

IBM Cloud Kubernetes Service will complete the transition to CoreDNS in version 1.14. As a result, upgrading your cluster to version 1.14 or later will automatically migrate KubeDNS to CoreDNS. The migration will include any KubeDNS customizations. To mitigate risk for the switch to CoreDNS, test your apps today by toggling the cluster DNS provider to CoreDNS. Don’t wait until you are forced to make the change.

Cluster DNS customization options

You may be surprised to learn that you can customize your Kubernetes cluster DNS provider. Both KubeDNS and CoreDNS support this. For example, if your apps make heavy usage of cluster DNS, you can customize the cluster DNS autoscaler to ensure there are a minimum number of DNS pods to support your apps. In addition, if your apps require customized DNS resolution, you can customize the cluster DNS provider.


For general questions, engage our team via Slack by registering here, and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.

More from Announcements

IBM Hybrid Cloud Mesh and Red Hat Service Interconnect: A new era of app-centric connectivity 

2 min read - To meet customer demands, applications are expected to be performing at their best at all times. Simultaneously, applications need to be flexible and cost effective, and therefore supported by an underlying infrastructure that is equally reliant, performant and secure as the applications themselves.   Easier said than done. According to EMA's 2024 Network Management Megatrends report only 42% of responding IT professionals would rate their network operations as successful.   In this era of hyper-distributed infrastructure where our users, apps, and data…

IBM named a Leader in Gartner Magic Quadrant for SIEM, for the 14th consecutive time

3 min read - Security operations is getting more complex and inefficient with too many tools, too much data and simply too much to do. According to a study done by IBM, SOC team members are only able to handle half of the alerts that they should be reviewing in a typical workday. This potentially leads to missing the important alerts that are critical to an organization's security. Thus, choosing the right SIEM solution can be transformative for security teams, helping them manage alerts…

IBM and MuleSoft expand global relationship to accelerate modernization on IBM Power 

2 min read - As companies undergo digital transformation, they rely on APIs as the backbone for providing new services and customer experiences. While APIs can simplify application development and deliver integrated solutions, IT shops must have a robust solution to effectively manage and govern them to ensure that response times and costs are kept low for all applications. Many customers use Salesforce’s MuleSoft, named a leader by Gartner® in full lifecycle API management for seven consecutive times, to manage and secure APIs across…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters