The CNCF’s Technical Oversight Committee (TOC) recently voted CoreDNS into the CNCF portfolio of projects. CoreDNS, a fast, flexible and modern DNS server, joins a growing number of projects integral to the adoption of cloud native computing. CoreDNS was voted in as an inception project – see explanation of maturity levels and graduation criteria here.
“Kubernetes and other technology projects use DNS for service discovery, so we are a key component to the implementation of cloud native architectures. Additionally, CoreDNS’ design allows easy extension of DNS functionality to various container stacks,” said John Belamaric, CoreDNS core maintainer and distinguished architect at Infoblox. “As a CNCF project, we are looking forward to the Foundation helping to fuel developer contributions and user growth. Increased integration with other CNCF projects and cloud native technologies and priority usage of its Community Cluster are also important to us.”
“A focused, lightweight DNS server with a microservice philosophy guiding its internal design, CoreDNS is a critical component to the cloud native architecture and an important project for CNCF,” said Jonathan Boulle, CNCF TOC representative and head of containers and Berlin site lead at CoreOS. “The TOC has made it easier to find, submit and follow the progress of project proposals. By making the process more streamlined, we have been able to add several new projects over the past several months to speed the development of open source software stacks that enable cloud native deployments.”
Here’s more about the young, but growing distributed systems-friendly DNS project started by Miek Gieben, a Google Site Reliability Engineer.
CoreDNS
Founded in March 2016, CoreDNS is the successor to the popular SkyDNS server. It is built as a server plugin for the widely-used Caddy webserver and uses the same model: it chains middleware.
The SkyDNS architecture did not lend itself to the flexible world of cloud deployments (organic grown code base, monitoring, caching, etc.). Additionally, other DNS servers (BIND9, NSD, Knot) may be good for serving DNS, but are not flexible and do not support etcd as a backend, for instance.
The CoreDNS creators built on the concept of SkyDNS and took into account its limitation and the limitations of other DNS servers to create a generic DNS server that can talk to multiple backends (etcd, Consul, Kubernetes, etc.). CoreDNS aims to be a fast and flexible DNS server, allowing users to access and use their DNS data however they please.
CoreDNS has been extended to operate directly with Kubernetes to access the service data. This “middleware” implementation for CoreDNS provides the same client-facing behavior as KubeDNS. The pipeline-based design of CoreDNS allows easy extension to use any container orchestrator as a DNS data source.
“In creating CoreDNS, our goal is to become the cloud DNS server allowing others like Docker, Hashicorp, and Weaveworks to use this technology as a library,” said Gieben. “Additionally, CoreDNS is useful outside cloud environments as well, so whether you use a private, public, on-premises or multi-cloud environment, you can use CoreDNS.” With the future addition of a pluggable policy engine, CoreDNS will extend its capabilities to sophisticated security and load balancing use cases.
Architecture
- Chains DNS middleware, each “feature” is contained in a middleware, for instance:
- monitoring (Prometheus),
- logging,
- file based DNS,
- etcd and k8s backends.
- Only load the middleware(s) you need
- Each middleware is self-contained – easy to add new behavior
Figure 1: CoreDNS Architecture
Currently CoreDNS is able to:
- Serve zone data from a file; both DNSSEC (NSEC only) and DNS are supported (middleware/file).
- Retrieve zone data from primaries, i.e., act as a secondary server (AXFR only) (middleware/secondary).
- Sign zone data on-the-fly (middleware/dnssec).
- Load balancing of responses (middleware/loadbalance).
- Allow for zone transfers, i.e., act as a primary server (middleware/file).
- Caching (middleware/cache).
- Health checking (middleware/health).
- Use etcd as a backend, i.e., a replacement for SkyDNS (middleware/etcd).
- Use k8s (kubernetes) as a backend (middleware/kubernetes).
- Serve as a proxy to forward queries to some other (recursive) nameserver, using a variety of protocols like DNS, HTTPS/JSON and gRPC (middleware/proxy).
- Rewrite queries (qtype, qclass and qname) (middleware/rewrite).
- Provide metrics (by using Prometheus) (middleware/metrics).
- Provide Logging (middleware/log).
- Support the CH class: version.bind and friends (middleware/chaos).
- Profiling support (middleware/pprof)
- Integrate with OpenTracing-based distributed tracing solutions (middleware/trace)
For more on CoreDNS, check out the CNCF project proposal here and follow @corednsio to stay in touch.
“CoreDNS provides essential naming services efficiently and integrates effectively with many other cloud native (CNCF) projects,” said Chris Aniszczyk, COO, CNCF. “Furthermore, with a highly modular and extensible framework, CoreDNS is a compelling option for Kubernetes service discovery.”
As a CNCF inception project, every 12 months, CoreDNS will come to a vote with the TOC. A supermajority vote is required to renew a project at inception stage for another 12 months or move it to incubating or graduated stage. If there is not a supermajority for any of these options,, the project is not renewed.
To learn more, check out these in-depth blogs on adding middleware to CoreDNS and using CoreDNS for Kubernetes service discovery.
Discuss this post on Hacker News!