CoreDNS: Cloud-Native DNS for Kubernetes



CoreDNS offers a unique approach to providing DNS service for a Kubernetes cluster. By having requests handled along a chain which allows plugins to provide the functionality, CoreDNS can provide all the flexibility Kubernetes requires to support the service discovery needs of any organization leveraging it.


With CoreDNS now an official project for the Cloud Native Computing Foundation (CNCF), it is being positioned as the primary tool to provide basic service discovery both within a Kubernetes cluster and for clients trying to access services the cluster is hosting.

As we know, DNS is a fundamental building block of working with applications that need to interact with other services over the Internet, and even large private networks. Within the Kubernetes environment, DNS is used as the primary service discovery functionality. The running services and location of their pods are accessed by reading from etcd. Services support the LoadBalancer or NodePort as a service type to allow access outside of a single cluster. This is key to resolving across federated clusters or to any client outside the Kubernetes environment.


CoreDNS has been built using a model that has requests follow a chain in which plugins, called middleware, connect to and provide the functionality that is used to process the request so that each Kubernetes cluster can have the DNS service functionality that best suits it.


All configuration of CoreDNS is in a single file named Corefile. Corefile is organized by domain, where each domain has the plugins listed that are used to process requests for that domain.

The default configuration when no Corefile is found is:

 . {

The whoami plugin simply responds to every A (IPv4) or AAAA (IPv6) request with the client’s IP. This isn’t really useful for anything other than proving it is running.

The configuration in the Corefile supports reverse DNS with two different formats: the traditional Bind syntax and a human-readable syntax that works with CIDR. {
} {

Having CoreDNS listen on specific ports for specific domains is easy enough. {
} {

An example of a more robust Corefile configuration that might be seen in the real world: {
    file net.example {
        transfer to *
. {
    proxy .

This example does a few things for the zone:

  1. It is authoritative.
  2. It is loaded from a file named “net.example.”
  3. It allows AXFR transfers to anyone.
  4. It offers Prometheus plugin-enabled metrics.
  5. The errors plugin shows errors.
  6. The log creates an access log.
  7. For the root zone, it’s acting as a forwarder, sending all other requests to Google’s public DNS and logging access requests.

    More Information

    For further information, you can review the Intro to CoreDNS slides from CNCF and visit the < a href=>CoreDNS site for documentation, downloads, and installation instructions.


    CoreDNS has been positioned as the tool that will be used as part of the CNCF suite of products to provide DNS-based service discovery in a single service. CoreDNS will be a solid alternative to the existing SkyDNS and Kube-DNS going forward. While the project is still in the incubation phase, it has proven itself to be able to handle the requirements of providing these services in the Kubernetes ecosystem, and is well-positioned to grow and expand as more organizations go cloud-native.

Vince Power is an Enterprise Architect with a focus on digital transformation built with cloud enabled technologies. He has extensive experience working with Agile development organizations delivering their applications and services using DevOps principles including security controls, identity management, and test automation. You can find @vincepower on Twitter. Vince is a regular contributor at Fixate IO.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Skip to toolbar