CoreDNS answers DNS queries: it translates names that applications use into the addresses they need to connect. In many Kubernetes clusters it provides service discovery, allowing one application to reach another by its service name rather than tracking changing Pod addresses. It can also forward queries for names outside the cluster. Because so many connections depend on it, first determine whether your Kubernetes provider already manages the existing CoreDNS deployment.
Deployment and operating notes
The CoreDNS project publishes a Helm chart for cluster DNS and other DNS-server use cases. The first decision is ownership: many Kubernetes distributions already manage CoreDNS as a critical add-on. Installing another release into kube-system can create competing Services or configurations rather than safely upgrading the existing resolver.
Inventory the cluster DNS Service address, Corefile, plugin build, upstream resolvers, stub domains and network policies. Use the distribution’s supported update path for its managed add-on; use the project chart when you deliberately own a separate deployment. Test service discovery, external lookup, negative responses, large responses and TCP fallback from representative namespaces before changing traffic. Watch request errors and latency during node disruption. Keep the previous Corefile and a documented method to restore the DNS Service path without depending on working cluster DNS. Old chart examples involving federation or external etcd should be assessed independently rather than enabled because they appear in the historical feature list.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-09T15:55:29+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
CoreDNS is a DNS server. It is written in Go. It can be used in a multitude of environments because of its flexibility. CoreDNS is licensed under the Apache License Version 2, and completely open source.
Development takes place on Github. Most devs hang out on Slack on the #coredns channel. This chart bootstraps a CoreDNS deployment on a Kubernetes cluster using the Helm package manager. This chart will provide DNS Services and can be deployed in multiple configurations to support various scenarios listed below:
- CoreDNS as a cluster dns service and a drop-in replacement for Kube/SkyDNS. This is the default mode and CoreDNS is deployed as cluster-service in kube-system namespace. This mode is chosen by setting isClusterService to true.
- CoreDNS as an external dns service. In this mode CoreDNS is deployed as any kubernetes app in user specified namespace. The CoreDNS service can be exposed outside the cluster by using using either the NodePort or LoadBalancer type of service. This mode is chosen by setting isClusterService to false.
- CoreDNS as an external dns provider for kubernetes federation. This is a sub case of ‘external dns service’ which uses etcd plugin for CoreDNS backend. This deployment mode as a dependency on etcd-operator chart, which needs to be pre-installed.
Plugins
CoreDNS chains plugins. Each plugin performs a DNS function, such as Kubernetes service discovery, Prometheus metrics or rewriting queries. And many more.
CoreDNS can listen for DNS request coming in over UDP/TCP (go’old DNS), TLS (RFC 7858) and gRPC (not a standard).
Currently CoreDNS is able to:
- Serve zone data from a file; both DNSSEC (NSEC only) and DNS are supported (file).
- Retrieve zone data from primaries, i.e., act as a secondary server (AXFR only) (secondary).
- Sign zone data on-the-fly (dnssec).
- Load balancing of responses (loadbalance).
- Allow for zone transfers, i.e., act as a primary server (file).
- Automatically load zone files from disk (auto).
- Caching (cache).
- Use etcd as a backend (replace SkyDNS) (etcd).
- Use k8s (kubernetes) as a backend (kubernetes).
- Serve as a proxy to forward queries to some other (recursive) nameserver (proxy, and forward).
- Provide metrics (by using Prometheus) (metrics).
- Provide query (log) and error (errors) logging.
- Support the CH class: version.bind and friends (chaos).
- Support the RFC 5001 DNS name server identifier (NSID) option (nsid).
- Profiling support (pprof).
- Rewrite queries (qtype, qclass and qname) (rewrite and template).
- And more. Each of the plugins is documented. See coredns.io/plugins for all in-tree plugins, and coredns.io/explugins for all out-of-tree plugins.
Security
If you find a security vulnerability or any security-related issues, please DO NOT file a public issue, instead send your report privately to [email protected]. Security reports are greatly appreciated and we will publicly thank you for it.
The chart will automatically determine which protocols to listen on based on the protocols you define in your zones. This means that you could potentially use both “TCP” and “UDP” on a single port. Some cloud environments like “GCE” or “Azure container service” cannot create external load balancers with both “TCP” and “UDP” protocols. So When deploying CoreDNS with serviceType=”LoadBalancer” on such cloud environments, make sure you do not attempt to use both protocols at the same time.
The post CoreDNS appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →